Date: Fri, 11 May 2007 13:16:47 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: smithi@nimnet.asn.au Cc: tevans.uk@googlemail.com, freebsd-stable@freebsd.org, martin.dieringer@gmx.de Subject: Re: clock problem Message-ID: <20070511.131647.-135505895.imp@bsdimp.com> In-Reply-To: <Pine.BSF.3.96.1070512033726.21240C-100000@gaia.nimnet.asn.au> References: <1178900585.1231.63.camel@zoot.mintel.co.uk> <Pine.BSF.3.96.1070512033726.21240C-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.BSF.3.96.1070512033726.21240C-100000@gaia.nimnet.asn.au>
Ian Smith <smithi@nimnet.asn.au> 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 <martin.dieringer@gmx.de> 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: <Enhanced SpeedStep Frequency Control> on cpu0
: p4tcc0: <CPU Frequency Thermal Control> on cpu0
: apm0: <APM BIOS> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511.131647.-135505895.imp>