kern.polling.lost_polls

[Mel Flynn]

On Fri, 20 Nov 2009 14:35:22 -0700 (MST), Brett Glass <brett at lariat.net>
wrote:
> Everyone:
> 
> I've been experimenting with using device polling on a router with six
> Ethernet
> interfaces that handles lots of traffic. I turned polling on, and set
> HZ=4000
> to minimize latency and ensure that enough time was allocated to handle
all
> of
> the incoming packets. But the sysctl variable kernel.polling.lost_polls
> keeps
> incrementing! The documentation of this variable isn't very good, so I am
> not
> sure what this means. Does it mean that I should set kern.hz lower
(perhaps
> to 2000) and kern.polling.burst_max higher? Or that running the
interfaces
> in interrupt-driven mode would be more effective?

You likely have the HZ too high. First, see this description:
http://www.pubbs.net/freebsd/200909/107087/

So that means that you give the kernel .25 microseconds to poll and act on
any
pending network IO. That's probably not enough. It is further explained by
the
comment in sys/kern/kern_poll.c:
/*
 * Hook from hardclock. Tries to schedule a netisr, but keeps track
 * of lost ticks due to the previous handler taking too long.
 * Normally, this should not happen, because polling handler should
 * run for a short time. However, in some cases (e.g. when there are
 * changes in link status etc.) the drivers take a very long time
 * (even in the order of milliseconds) to reset and reconfigure the
 * device, causing apparent lost polls.
 *
 * The first part of the code is just for debugging purposes, and tries
 * to count how often hardclock ticks are shorter than they should,
 * meaning either stray interrupts or delayed events.
 */

I would start with the FreeBSD provided default of 1000HZ. If there are
lost
polls then, see if you can correlate it with link state changes. If not,
then there may be issues with the driver and I would follow up to
freebsd-net.
If there are no lost polls, see if you can increase the frequency until
they return. You also want to get some form of realworld measurement for
these higher values: do they in effect increase network throughput.

-- 
Mel