“D” packets – USRP2

Recently, while playing with the USRP2 unit and a i3 processor  here ,I met  this unpleasant issue of packets dropping , the screen comes quickly saturated by the letter “D” when recording .


From Ettus

Network-based devices: The host does not back-pressure the receive stream. When the kernel’s socket buffer becomes full, it will drop subsequent packets. UHD software detects the overflow as a discontinuity in the packet’s sequence numbers, and pushes an inline message packet into the receive stream. In this case the character “D” is printed to stdout as an indication.

Ideally, interrupts (IRQs) and user processes can be isolated from one another on different dedicated CPUs disabling irqbalance . Then  you should need to know the exact IRQ number associated with your ethernet card/driver .

root@iono:~# grep eth0 /proc/interrupts
 46: 29 13 2225814805 9 PCI-MSI-edge eth0

The first number is the IRQ number, in this case 46. Then search for the cpu_affinity in

cat /proc/irq/46/smp_affinity

You should see an f meaning IRQ can be menaged by any processor. The objective here is to dedicate to  a single CPU  the ethernet card and not being used by all the processors. The Intel i3 processor actually uses two real core, that becomes 4 using the Hyper Threading. So they becom 2+2=4 (2 real, 2 virtual). I think the problem on the i3(and others?) can start when the huge amount of UDP packet flowing from the USRP it is managed also by the virtual hyper-threding processor.  It is possible to create an  IRQ tuning in two way . 1- using a series of command :

killall -9 irqbalance
#echo  0 > /proc/irq/46/smp_affinity

where 0 (or processor number)  is a bit mask of the core # (e.g.: core 2 = 04, core 3 = 08, core 4 = 16, etc).

The other way it is to use this script after killing irqbalance, in this way :

killall -9 irqbalance
./script.sh eth0 0

where 0 it is the processor number that you need to use. Check it if it is working with

 mpstat -P ALL 1

On my mini-pc ,wich is dedicated for SDR , the overall result was good. from each single task before, the command line was full of “D” ,now just few of them are present and the overall performance it is better. Remember to check with #top if other processes are running and consuming cpu / memory.




One thought on ““D” packets – USRP2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s