Date: Fri, 20 Nov 2009 16:25:02 -0900 From: Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net> To: Brett Glass <brett@lariat.net> Cc: questions@freebsd.org Subject: Re: kern.polling.lost_polls Message-ID: <db2308c2d90148218fcc9209721b9920@sbmail.office-on-the.net> In-Reply-To: <200911202135.OAA18537@lariat.net> References: <200911202135.OAA18537@lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Nov 2009 14:35:22 -0700 (MST), Brett Glass <brett@lariat.net> wrote: > Everyone: >=20 > 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=3D4000 > 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 o= n any pending network IO. That's probably not enough. It is further explained b= y 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. --=20 Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?db2308c2d90148218fcc9209721b9920>