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 <[email protected]>: > 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 <[email protected]>: > >> 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 < <[email protected]> >> [email protected]>: >> >>> 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 < <[email protected]> >>> [email protected]>: >>> >>>> 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> >>>> 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 < <[email protected]> >>>> [email protected]> 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 >>>>> <[email protected]>[email protected] >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing >>>> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >> > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
