[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Reliable Ethernet controllers and laptops for USR

From: Rickard Radio
Subject: Re: [Discuss-gnuradio] Reliable Ethernet controllers and laptops for USRP N210 ?
Date: Wed, 12 Dec 2012 20:00:27 +0100

OK, I see.  However strange is that I can get UDP traffic to work up to about 925 Mbit/s without any dropped packets when testing with "iperf" and Ethernet cable directly between the two Acer laptops. That with tuning UDP buffer size to 600 kB and datagram packet size to 3000 bytes (using "-l" and "-w" iperf parameter options). But trying to use the same tuned values, with UHD (I assume corresponding) parameters "recv_buff_size"  and "recv_frame_size" does not work. But maybe I misunderstand or mix up something, chasing lost packets in the dark.
On Dec 12, 2012, at 7:00 PM, address@hidden wrote:



By "silently ignore", I mean that they'll apparently take the higher MTU setting, but will actually drop any frames that exceed the default (1500) MTU.  Which is a particularly insidious failure mode for these drivers...


On 12 Dec 2012 12:46, Rickard Radio wrote:

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.

On Dec 12, 2012, at 6:38 PM, address@hidden 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:


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=, 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.  
On Dec 11, 2012, at 9:53 PM, Balint Seeber <address@hidden> 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,

On Tue, Dec 11, 2012 at 8:26 AM, Rickard Radio <address@hidden> 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).
On Dec 11, 2012, at 12:51 PM, Rickard Radio <address@hidden> 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"

On Dec 7, 2012, at 3:32 PM, Rickard <address@hidden> 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 mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]