--3otr1o0hesjdi1gG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > Does it do better with i8254?
> >=20
> 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.

--
Dan.

--3otr1o0hesjdi1gG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFEn1gsEAVxvV4N66cRAv0mAKCXFz8M10kezGHMp6z1a8wXOBKFJwCgtbas
dLHjjq7eiYeNkWhc5lOBQ/Q=
=nEm7
-----END PGP SIGNATURE-----

--3otr1o0hesjdi1gG--