MANY NICs don't support larger frame sizes. Some of them require that you set the larger MTU using ifconfig, and some will error-out if you ask for an MTU too large. Others will accept the larger MTU request and then silently ignore it.
On 12 Dec 2012 12:22, Rickard Radio wrote: > Thanks! > > This is really valuable information. Also your new document with lots of useful info and explanations what happens behind the scenes. > > However, on my problematic Acer Aspire 8820T laptop with AR8151 NIC and "atl1c" driver (instead of the Intel "e100e" driver below) , nothing of this has an effect. For example, sudoing has no effect as well no effect of changing the frame sizes, CPU governor, receive buffer size, etc. Played with most of this before (see thread http://www.ruby-forum.com/topic/3949213 [7] ) > >> sudo /usr/local/share/uhd/examples/benchmark_rate --rx_rate 25e6 --tx_rate 25e6 --duration 30 --args="recv_frame_size=3792,send_frame_size=3792" > > For this to have an effect of frame size, I need also to specify the ip-address (otherwise the arguments seem to be ignored): > sudo /usr/local/share/uhd/examples/benchmark_rate --rx_rate 25e6 --tx_rate 25e6 --duration 30 --args="addr=192.168.10.2, recv_frame_size=3792,send_frame_size=3792" > > In any case, connection stalls/hangs with repeated "Error code 1: Unexpected error on recv, continuing…" messages with the "benchmark_rate" test. Similar thing if I run uhf_fft at the same samp rate, it just stalls, orange LED starts rapidly blinking and the "C" LED goes off, and the FFT plot just freeze since no more samples are coming from the N210. > > So I suppose something is terrible wrong with the AR8151 NIC, or internally further down the pipe at high sampling rates. I have now finally given up on those Acer machines for these high samp rates. > Now writing to "SDR Santa" to bring me more powerful Lenovo Thinkpad T430s needed for my high sample rate experiments and projects. > > Rickard > > On Dec 11, 2012, at 9:53 PM, Balint Seeber <balint.see...@ettus.com [8]> wrote: > >> Hi Richard, >> >> Thanks for reporting on your experiments! I have doing a few lately myself (specifically in regards to USRP latency). >> >> I have a Thinkpad T430s with a 82579LM. The benchmark_rate reports zero underflows/overflows for unidirectional streaming. Bi-directional results in some TX underflows with the default MTU, however increasing this results in NO underflows, e.g. >> >> sudo ifconfig eth0 mtu 9000 >> >> sudo /usr/local/share/uhd/examples/benchmark_rate --rx_rate 25e6 --tx_rate 25e6 --duration 30 --args="recv_frame_size=3792,send_frame_size=3792" >> >> Remember the 'sudo' will help by enabling 'real-time' (SCHED_FIFO) scheduling in the Linux kernel. >> >> Benchmark rate summary: >> Num received samples: 749991475 >> Num dropped samples: 0 >> Num overflows detected: 0 >> Num transmitted samples: 749969786 >> Num sequence errors: 0 >> Num underflows detected: 0 >> >> I have found a number of parameters can be tweaked to change general N-series communication behaviour with the Intel NIC (specifically interrupt moderation, MTU [above], etc): >> >> sudo modprobe -r e1000e >> sudo modprobe e1000e debug=16 InterruptThrottleRate=0 TxAbsIntDelay=0 TxIntDelay=0 RxAbsIntDelay=0 RxIntDelay=0 >> >> Changing CPU governor to 'performance' on all cores may also help in certain situations. >> >> Please take a look at this document I've been putting together for more details: http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency [5] >> >> Let us know if any of the above tips improve your results. >> >> Hope that helps, >> Balint >> >> On Tue, Dec 11, 2012 at 8:26 AM, Rickard Radio <rickardra...@gmail.com [6]> wrote: >> >>> OK, I just tried this on a colleagues brand new Thinkpad T430s and it works without any packet drops or other Ethernet problems on that laptop (at least for a minute or so). It has the Intel 82579LM Ethernet chip so that chip doesn't seem too bad after all (like the Artheros 8151 which I have problems with). >>> >>> Rickard >>> >>> On Dec 11, 2012, at 12:51 PM, Rickard Radio <rickardra...@gmail.com [2]> wrote: >>> >>>> Hi all, >>>> >>>> Can anyone please try this on a laptop, preferably a Lenovo Thinkpad, with a N210 and report what you get: >>>> "/uhd/examples/benchmark_rate --rx_rate 25e6" >>>> >>>> Thanks >>>> Rickard >>>> >>>> On Dec 7, 2012, at 3:32 PM, Rickard <rickardra...@gmail.com [1]> wrote: >>>> >>>>> I wonder which GigE controllers (manufacturer & versions) and laptop computers are working hassle free, without dropping packets etc., at the highest sampling rates with the USRP N210 which results in 800 Mbit/s raw data (or about 835 Mbit/s total UDP) ?! >>>>> >>>>> Please test your laptop with "/uhd/examples/benchmark_rate --rx_rate 25e6" or "uhd_fft -s 25e6" and report your findings! >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org [3] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [4] Links: ------ [1] mailto:rickardra...@gmail.com [2] mailto:rickardra...@gmail.com [3] mailto:Discuss-gnuradio@gnu.org [4] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [5] http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency [6] mailto:rickardra...@gmail.com [7] http://www.ruby-forum.com/topic/3949213 [8] mailto:balint.see...@ettus.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
