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 <tkdgur7...@gmail.com > <mailto:tkdgur7...@gmail.com>>: > > 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 <mle...@ripnet.com > <mailto:mle...@ripnet.com>>: > > 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 <mle...@ripnet.com >> <mailto:mle...@ripnet.com>>: >> >> 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 >>> <tkdgur7...@gmail.com <mailto:tkdgur7...@gmail.com>> 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 >>> Discuss-gnuradio@gnu.org >>> <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
