From owner-freebsd-hardware@FreeBSD.ORG Thu Jun 4 09:35:02 2009 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A51B61065675 for ; Thu, 4 Jun 2009 09:35:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 43E718FC0A for ; Thu, 4 Jun 2009 09:34:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n547p6Fg009639 for ; Thu, 4 Jun 2009 17:51:06 +1000 Received: from c122-106-151-9.carlnfd1.nsw.optusnet.com.au (c122-106-151-9.carlnfd1.nsw.optusnet.com.au [122.106.151.9]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n547orWQ023819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 17:50:56 +1000 Date: Thu, 4 Jun 2009 17:50:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Barney Wolff In-Reply-To: <20090603220632.GA79172@pit.databus.com> Message-ID: <20090604172829.D14759@delplex.bde.org> References: <20090603220632.GA79172@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hardware@freebsd.org Subject: Re: slow tick when idle X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 09:35:02 -0000 On Wed, 3 Jun 2009, Barney Wolff wrote: > I have an odd problem with wait timing. When the system is quite busy, > for example doing multiple port builds, waits in select() or sleep() > work fine. But when the system is otherwise mostly idle, waits run > at least 2.5% slow. This happens on both a 6-stable from 12/08 and > 7-stable from 5/28/09, and whether I use ACPI-fast or HPET. Time of > day is not affected, only waits. Timeouts are implemented using hardclock() interrupts, so they would take longer than expected if some of these interrupts are missed. nanosleep() shouldn't notice the effect of small errors in the hardclock() interrupt frequency (which will become large absolute errors for long waits), but it is misimplemented. (The worst-case error with a working i386 i8254 timer and HZ = 1000 is about 0.1% or 3.6 seconds per hour.) nansleep() should wake up about 0.1% early to handle the case where the clock runs slow. (If the clock runs fast then it already wakes up early. It already knows to go back to sleep then, so it only needs a small change to avoid late wakeups.) To handle your clock, it would have to wake up 2.5% early. > My machine is a Dell XPS410 with Intel Core2 2.13GHz, 2 cores. The > problem does not occur on an older single-cpu Athlon XP with 7.2-rel. > > Perhaps some artifact of cpu state under light load? Your hardclock timer is probably the lapic. This has more delicate interactions with sleep states than the i8254 (I think that since the i8254 is old and often used for timeouts, hardware designers know not to stop it for low sleep states.) Normally when there is this problem, the lapic timer stops completely and waits would be infinite, except other interrupt activity (like dancing on the keyboard) wakes up the system enough for some lapic interrupts to get through, and timeouts are only delayed for several thousand percent. I don't know of any bugs that result in only 2.5% of lapic interrupts not getting through. Bruce