Polling will always increase device load in the absence of data versus 
Interrupt Requests.

Basically, the system must spend time checking each potential polled 
data source over and over again.  This creates load in the form of IO 
wait time and fills up queues with extra instructions that do not exist 
in an Interrupt driven implementation.  The term "Load" should not be 
confused with a CPU that is continually filling it's various caches and 
whatnot, as is the case with number crunching tasks like high data rate 
VPN tunnels and deep content packet rewrites.

Polling should be applied when you have at least a semi constant stream 
of traffic.  Basically, the CPU doesn't need to be told something that 
it already knows - the network card wants to spew packets onto a bus of 
the CPU's.

All CPUs can benefit from the polling approach as opposed to an 
Interrupt driven mechanism, and likewise all CPUs can be hindered by it. 
    Most benefit from my experience, but I haven't exactly gone and 
tested it on every system that I've built - I usually just enable it 
these days.

Some polling implementations utilize a hybrid approach, wherein only 
received traffic is handled via polling and transmitted traffic is 
handled via Interrupt.  It depends on the driver and the chipset of the 
NIC as to which method of polling, if any, is supported.

Of course, neither method works if you have just too much bandwidth for 
the box to handle.

As Craig says, YMMV.

- krt

Craig FALCONER wrote:
> Beg to differ - I have a nokia IP330 with a P166 CPU. 
> 
> Turning on polling increased the machine's load to a noticeable level.
> 
> So its really "YMMV" but slower CPUs may not benefit from that.
> 
> 
> -----Original Message-----
> From: Steve Thomas [mailto:sthomas at consultant dot com] 
> Sent: Friday, 9 February 2007 9:58 a.m.
> To: Lonnie Abelbeck; m0n0wall List
> Subject: Re: [m0n0wall] Hardware suggestion
> 
> 
> Good thought, I don't really know. AFAIK, turning on polling generally
> improves performanceover having it turned off. 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
>