Device polling performance
TM4525 at aol.com
TM4525 at aol.com
Sat Sep 25 12:38:27 PDT 2004
In a message dated 9/25/04 1:06:40 PM Eastern Daylight Time, cswiger at mac.com
> It seems beyond unreasonable that, with interrupts enabled, 55% of the
> is used, and with polling, ~ zero.
"Erm...I do not think that word means what you think it means."
It's probably easier to claim device polling works by black magic, then to
explain just how much useless overhead is added when the CPU has to service
tens of thousands of interrupts per second at very high packet rates. If you
only need to bridge packets from one NIC to another, modern NICs will do
almost all of the work (busmastering DMA, checksum offloading, etc) without
needing any CPU time at all.
If you've got good hardware, device polling means that the system is usually
constrained by PCI bus throughput and the actual network transmission speed
the NICs themselves, not by CPU overhead.
If you attempt to use crappy hardware (try digging up some 10Mbs ISA NICs),
then the CPU will have to do a lot more work, and device polling will take up
more than nearly zero CPU time. If you do routing, have firewall rules
(particularly using dynamic stateful rules), or NAT (particularly running
userland natd), you'll probably see significant CPU being used there.
The EVIDENCE is to the contrary, since it seems that a 2.4Ghz system will be
saturated when bridging ~250Kpps with device-polling enabled, based on polling
stats and userland benchmarking, even though the system claims to be 100%
idle. Interestingly, its about the same with interrupt enabled.
The POINT is that since there is no way to measure the performance, you've
got a bunch of guys who think they've figured something out touting
device-polling without having a clue what the performance advantages (or consequences)
are, so it might as well be black magic, or snake oil, since you are as blind as
a bat in your assessments.
More information about the freebsd-questions