mel.flynn+fbsd.questions at mailing.thruhere.net
Sat Nov 21 01:25:05 UTC 2009
On Fri, 20 Nov 2009 14:35:22 -0700 (MST), Brett Glass <brett at lariat.net>
> I've been experimenting with using device polling on a router with six
> interfaces that handles lots of traffic. I turned polling on, and set
> to minimize latency and ensure that enough time was allocated to handle
> the incoming packets. But the sysctl variable kernel.polling.lost_polls
> incrementing! The documentation of this variable isn't very good, so I am
> sure what this means. Does it mean that I should set kern.hz lower
> to 2000) and kern.polling.burst_max higher? Or that running the
> in interrupt-driven mode would be more effective?
You likely have the HZ too high. First, see this description:
So that means that you give the kernel .25 microseconds to poll and act on
pending network IO. That's probably not enough. It is further explained by
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
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
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.
More information about the freebsd-questions