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”