From owner-freebsd-stable@FreeBSD.ORG Fri May 11 19:18:00 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A937316A402 for ; Fri, 11 May 2007 19:18:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 560F113C44C for ; Fri, 11 May 2007 19:18:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4BJGh99091199; Fri, 11 May 2007 13:16:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 11 May 2007 13:16:47 -0600 (MDT) Message-Id: <20070511.131647.-135505895.imp@bsdimp.com> To: smithi@nimnet.asn.au From: "M. Warner Losh" In-Reply-To: References: <1178900585.1231.63.camel@zoot.mintel.co.uk> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 11 May 2007 13:16:45 -0600 (MDT) Cc: tevans.uk@googlemail.com, freebsd-stable@freebsd.org, martin.dieringer@gmx.de Subject: Re: clock problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 19:18:00 -0000 In message: Ian Smith writes: : On Fri, 11 May 2007, Tom Evans wrote: : > On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: : > > In message: <20070511110759.L700@thinkpad.dieringer.dyndns.org> : > > Martin Dieringer writes: : > > : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : > > : problem is solved by switching to ACPI instead of APM : > > : > > It is a hardware problem. APM + powerd changes the frequency of the : > > TSC. If the TSC is used as the time source, then you'll get bad : > > timekeeping. ACPI uses its own frequency source that is much more : > > stable and independent of the TSC, so switching to it fixes the : > > problem because you are switching the hardware from using a really bad : > > frequency source with ugly steps to using a good frequency source w/o : > > steps. : > > : > > Warner : : Yes, but Martin already showed it was using the i8254, not TSC; would : you expect the same effect using powerd with the i8254 clock? It seems : so, unless it's some problem with est and/or p4tcc under APM (canoworms) No. I would not have expected it at all. I would have expected the i8254 to not be able to provide time much better than a microsecond or two, but I'd expect time to be relatively stable, modulo the normal walking due to thermal variation you'd see given the relatively low quality oscillators that feed it. However, see below. : > Surely that would imply that it is a software misconfiguration issue. If : > the TSC is unreliable under fairly standard duties, and there exists an : > alternate source that is reliable, surely that indicates the : > manufacturer has identified a problem, and solved it with alternate : > hardware. : > : > The failure then to use the correct hardware is a software : > misconfiguration. : : If one considers disabling ACPI and enabling APM misconfiguration .. : which in Martin's case it turned out to be, since his ACPI works, but : est0: on cpu0 : p4tcc0: on cpu0 : apm0: on motherboard : apm0: found APM BIOS v1.2, connected at v1.2 : together with powerd appeared to heavily retard time on both laptops, : beyond ntpd's ability to cope. The i8254 time counter has a frequency of about 1.19 MHz, but it wraps about 18 times a second (or once every ~55ms). I think that if the clock speed was slow enough, there might be situations where interrupts are disabled long enough to blow past that 55ms mark, especially on a 300MHz laptop that might be running at a very slow clock rate when idle. If it misses the wrap, then you'll see time slip away. Maybe you can experiment with the lower bounds the frequency of the system can run and keep accurate time. debug.cpufreq.verbose=1 might be helpful. You can override the lowest setting of powerd by using the sysctl debug.cpufreq.lowest. Warner