On Mon, 26 Jun 2006 13:44:45 +1000, Daniel Carosone <dan@geek.com.au>
wrote:

> On Sun, Jun 25, 2006 at 11:30:14PM -0400, Steven M. Bellovin wrote:
> > On Mon, 26 Jun 2006 02:07:22 +0000 (UTC), christos@astron.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