device polling and performance

none

none

I just read about device polling, and tried it on a net6501 from soekris.

Using it, iperf shows 139Mbps:

Code: 
iperf -c 192.168.10.11 -t30
------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.10 port 56437 connected with 192.168.10.11 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec   498 MBytes   139 Mbits/sec

Not using it, far more:

Code: 
iperf -c 192.168.10.11 -t30
------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.10.10 port 30934 connected with 192.168.10.11 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  1.63 GBytes   466 Mbits/sec

The interrupt rate drops to half or little more, but I was counting on better performance and got the opposite. Is this expected ?

Thanks,

none
 
What is the difference in CPU load? Turning on polling reduces interrupts but increases the CPU load. It's possible your CPU is maxed out. See polling(4).
 
SirDice: it's not that:

Code: 
CPU:  0.2% user,  0.0% nice, 12.5% system, 27.6% interrupt, 59.6% idle

while running and polling enabled. Without:

Code: 
CPU:  0.0% user,  0.0% nice, 35.5% system, 54.1% interrupt, 10.4% idle

Thanks,

none
 
Polling is really only needed on older systems with slow CPUs that can't handle really high interrupts/second generated by fast (gigabit+) NICs.

The normal way to process network traffic is for the NIC to generate interrupt for every single packet that arrives. Slow CPUs can't keep up with this. So polling was developed. Instead of generating and processing an interrupt for every single packet, the CPU instead polls the NIC every X ms to see if there's packets in the queue that need to be processed. Thus, fewer interrupts, less work for the CPU, possibly better throughput (although latency increases).

Modern CPUs can handle the traffic (int/sec) generated by a gigabit NIC. And older (P2/P3-era) CPUs can handle the traffic (int/sec) generated by a 10/100 NIC. And old-ish (P4/Athlon-era) CPUs can handle the traffic (int/sec) of most gigabit NICs.

And newer NICs include "interrupt moderation" where they generate interrupts every X packets instead of for every packet.

Thus, polling is generally not needed anymore, and can actually slow things down (as you've noticed) on modern systems.

Not sure what NIC or CPU is in a Soekris, but you probably don't need polling enabled. I haven't used polling since the days of our P2-based firewalls running FreeBSD 4.x.
 
phoenix: its an 1.6 GHz atom based, using gigabit ethernet from Intel. I read about polling and saw people on mailing lists on using polling for high packet forwarding rate. Though its not that high packet rate, I get half the total wire speed for the NIC.

thanks,

none
 
In case your CPU is not overloaded with interrupts you don't want polling at all. However there are others important factors besides how quickly can CPU get to incoming packets, see https://calomel.org/network_performance.html and http://www.psc.edu/networking/projects/tcptune/ for some introduction.

Also you may want to try some offloading (move packet defragmention, checksums calculation etc. from CPU to network card), especially when you have better chips like Intel. Check man page for your driver (probably em(4)) for details.
 
You must log in or register to reply here.
Back
Top