discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Rx overflow problem related with sample rate


From: SangHyuk Kim
Subject: Re: [Discuss-gnuradio] Rx overflow problem related with sample rate
Date: Wed, 30 Mar 2016 19:21:48 +0900

Dear Marcus,

Thanks for your help.

I'm tried to understand your advices about interrupt coalescing and I changed interrupt coalescing options

My default setting like below:

Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 20
rx-frames: 5
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 72
tx-frames: 53
tx-usecs-irq: 0
tx-frames-irq: 5

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

I controlled rx-usecs(0 ~ 1000) and rx-frames(0~1000), but I can't change adaptive-rx or pkt-rate-low(high).

Rx-usecs and rx-frames doesn't help to solve overflow problem.

Did I miss something when control interrupt coalescing ?

What parameters do I have to set ?

Thanks.

2016-03-29 20:52 GMT+09:00 Marcus Müller <address@hidden>:
Hi SangHyuk,

On 29.03.2016 13:45, SangHyuk Kim wrote:
Hi,

I found two phenomenons when USRP N210 are on receiving mode (but, no received data)


i) When I capture eth0 packets using wireshark, USRP send buffer to host continuously. Maybe it is to sampling process.
Of course. How else would the samples from the USRP come to your PC, where you put them into GNU Radio??
I think that host cannot read these buffer quickly, so overflow is occurred (at high samp_rate).
Yes!
   But, I don't know why host cannot consume these packet quickly (My PC CPU : 2.7GHz x 4)
If that is too slow or fast enough depends completely on the application you're running. To be honest, 2.7GHz isn't *that* much, if your network card doesn't support reducing the number of interrupts sent. Play with "interrupt coalescing".

ii) If I use samp_rate 25M, CPU utilization is over 300% (But, Tx mode is very stable, CPU utilization is under 10% at 25 MSps)
   I'm using native Ubuntu 14.04 OS, I can't understand these...
Again, CPU usage depends on what you do with the signal, and I don't know what "TX mode" is for you.

Best regards,
Marcus



Please give me a guide

Thanks.

2016-03-29 12:50 GMT+09:00 SangHyuk Kim <address@hidden>:
Hi,

I tried to change recv_buffer_size, but I can't find where I input buffer size.

What is the default recv_buffer_size ?

And why Tx is ok at BW 25MHz but Rx is not at same bandwidth ?

Thanks

2016-03-28 10:06 GMT+09:00 Marcus D. Leech <address@hidden>:
On 03/27/2016 09:01 PM, SangHyuk Kim wrote:
Hi,

My Ethernet controller info.

Ethernet controller: Broadcom Corporation NetXtreme BCM57762 Gigabit Ethernet PCIe
Subsystem: Apple Inc. Device 00f6
Physical Slot: 9
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at acb00000 (64-bit, prefetchable) [size=64K]
Memory at acb10000 (64-bit, prefetchable) [size=64K]
Expansion ROM at a0a00000 [disabled] [size=64K]
Capabilities: <access denied>
Kernel driver in use: tg3

And I changed rmem_max and wmem_max but, it was not effect.

How can I change recv_buffer_size ??

Thanks
Just specify it in the device arguments.

recv_buffer_size=<some_value>

In your device arguments




2016-03-28 0:37 GMT+09:00 Marcus D. Leech <address@hidden>:
On 03/27/2016 05:53 AM, tom x wrote:
Hi,

>I think my PC can handle this sample rate
Have you tried other rates? What's the highest sample rate before overflow occurs?

>How can I handle this problem ?
Maybe a power squelch block? You can filter out signals that don't meet a db threshold before they reach your PC.
https://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1pwr__squelch__cc.html
That's not how Gnu Radio works.    The blocks run on your PC.

However the power squelch I believe interrupts the sample stream, so that if you're writing to disk, the average write rate to the disk
  is lowered in this case, depending on the dynamics of the amplitude of your signals, since you'll only be writing "good stuff".

If you're getting 'D', this may be your ethernet controller--what type do you have?  The 82579LM is notorious for dropping data.
  Also, make certain that your network buffering is configured correctly.  See the notes here:

http://files.ettus.com/manual/page_transport.html#transport_udp_linux




On Sun, Mar 27, 2016 at 10:56 AM, SangHyuk Kim <address@hidden> wrote:
Hi,

I'm using USRP N210 with CBX daughter board on native Ubuntu 14.04

When I open fft_uhd with sample rate about 25 MSps, it spits out of "D"(overfow)

As I know, USRP N210 support sample rate up to 25 MSps and it's possible on Tx mode.

I think my PC can handle this sample rate, but I don't know why this is happened.

How can I handle this problem ? 

Thanks.

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio







_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]