polling decreases throughput ~50%

Danial Thom danial_thom at yahoo.com
Sun Aug 21 12:40:00 GMT 2005

--- Victor Semionov <victor at vmpbg.com> wrote:

> > >> Why is that? I thought polling should
> decrease CPU usage by avoiding too
> > >> many context switches when a hw irq is
> generated frequently, but it
> > >> shouldn't make the transfer slower if
> there are no other jobs running.
> >
> > You have to poll often enough to keep the
> pipe full, otherwise your max
> > throughput can be limited.  Also, rl hardware
> isn't the greatest and
> > probably requires a lot more CPU than a
> device with working buffer/DMA
> > design.
> HZ is 1000, which I guess should be more than
> enough with 
> kern.polling.burst_max=150.
> Indeed, it was hardware's fault - my other NIC
> is a fxp and I got much better 
> results with it - less CPU, while throughput
> stayed the same as without 
> polling.

Great. So you've added 900 totally unnecessary
context switches, plus all of the rubbish that
gets done every clock tick, even when there is no
traffic. Brilliant.

Modern hardware doesn't interrupt every packet;
in fact with intel em controllers its easily
tunable, so you get the advantages of polling
without the disadvantages of having a system
designed by an idiot. Polling will cause you to
lose tons of packets under bursts of heavy load.
Although it is downright comical that you're
concerned about cpu cycles but you were using the
slowest, least efficient ethernet controller ever

The fxp driver has a built-in hold off of 6000
ints/sec (which is 1/6000th of a second for you
mathletes). There is no reason to use polling
with intel hardware; in fact its a big negative.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the freebsd-questions mailing list