OK, thanks. My problematic Acer with AR8151 NIC accepts MTU's up to about 6100. Trying to set higher MTU it responds with an error. After setting to a large value, such as 6000, I checked with ifconfig whether it was accepted. However, as said, it has no effect on the failing UDP communication with the N210.
Rickard On Dec 12, 2012, at 6:38 PM, mle...@ripnet.com wrote: > 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 >> ) >> >>> 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> 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 >>> >>> 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> >>> 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> 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> 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 >>> 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
