Date: Wed, 1 Nov 1995 17:47:36 +1100 From: Bruce Evans <bde@zeta.org.au> To: gibbs@freefall.freebsd.org, wollman@lcs.mit.edu Cc: current@FreeBSD.org, wollman@FreeBSD.org Subject: Re: Time problems Message-ID: <199511010647.RAA19686@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Needless to say, on the three different motherboards we have here >(60, 100, and 120-MHz CPUs), we have never seen this problem, so it's >a bit hard to diagnose. For those machines on which the results are >reasonable, I expect timekeeping to be rather better than it was. >According to xntpd, my machine is within about 3 seconds per day, >which is about the same as it was before. (It's the precision, rather >than the accuracy, where this technique gives a benefit.) There's no reason why the Pentium clock should have higher precision than the 8254 clock. The low precision that you observed for the 8254 clock may have been due to the buggy implementation of adjtime(). It is necessary to inform microtime() about the adjustment. Currently, a count of 11932 for the 8254 clock is assumed to corresond to a time of 10000 usec. It actually corresponds to a time of (10000 + tickdelta + fine_usec_adjustment()). The result is that microtime() has an average jitter of about tickdelta/2 if adjtime() is used. If adjtime() isn't used, then microtime() has less jitter and less accuracy. I'm not sure why you didn't notice the same problem for the Pentium clock. Perhaps you just happen to have more accurate Pentium clocks. Note that increased accuracy also gives higher precision. I don't use Pentiums or adjtime(). This results in a low accuracy (700 ppm) but, as far as I can tell, a high precision. Can xntpd be run in a mode where it reports the drift but doesn't try to fix it? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511010647.RAA19686>