Subject: Re: acpi timer problems?
To: Daniel Carosone <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 06/25/2006 23:53:42
On Mon, 26 Jun 2006 13:44:45 +1000, Daniel Carosone <firstname.lastname@example.org>
> On Sun, Jun 25, 2006 at 11:30:14PM -0400, Steven M. Bellovin wrote:
> > On Mon, 26 Jun 2006 02:07:22 +0000 (UTC), email@example.com (Christos
> > Zoulas) wrote:
> > >
> > > Does it do better with i8254?
> > >
> > I haven't run it that way for nearly as long, but the answer seems to be yes,
> > it does better.
> I presume this is what you were using as a timecounter until recently,
> given TSC vs speedstep?
> What you will probably find is that the ntp drift value needs to be
> entirely different for each counter; each source has its own frequency
> error and bias. When you switch counters while using a drift value
> calculated with different counter source, I've noticed it can take up
> to several days to stabilise and re-adjust the drift accordingly
> (maybe less, I wasn't checking so often after the first hour or two),
> and in the meantime you get wider offsets because ntpd is compensating
> for the incorrect drift.
> So if you switched back to the same counter you were using previously
> soon enough that the new one hadn't altered drift much, it doesn't
> surprise me that ntpd does better quickly after restart.
> I don't know whether zapping ntp.drift (ie, starting with 0 or
> 'undefined') will help ntp close in on a correct new drift value any
> sooner than starting with a wrong value.
OK -- ntp.drift zapped; timer switched back to ACPI_PM_TMR; ntpd
restarted. The previous kernel was indeed pretimecounter.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb