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. I think that host cannot read these buffer quickly, so overflow is occurred (at high samp_rate). But, I don't know why host cannot consume these packet quickly (My PC CPU : 2.7GHz x 4) 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... 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]>: > >> 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]>: >> >>> 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 <[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] >>>> 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
