Date: Wed, 1 Nov 1995 19:31:17 +1100 (EST) From: michael butler <imb@scgt.oz.au> To: bde@zeta.org.au (Bruce Evans) Cc: current@freebsd.org Subject: Re: Time problems Message-ID: <199511010831.TAA10618@asstdc.scgt.oz.au> In-Reply-To: <199511010723.SAA20983@godzilla.zeta.org.au> from "Bruce Evans" at Nov 1, 95 06:23:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >>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.) 3/86400 = ~34ppm .. most PCs would be hard-pushed to better that. I'd be happy if that was the general scale of error :-) With some manual trimming, I have two (non-pentia) here that are 5ppm and -6ppm but the average "off-the-shelf" box isn't much better than +/-300ppm. > Perhaps because of the microtime() jitter that I reported in previous > mail - if the accuracy is low then the jitter becomes large when adjtime() > is used to improved the accuracy. However, I guess xntpd should be > able to handle large jitter. The way that the NTP documentation reads, it seems that the PLL is unhappy beyond the designed capture range of +/-128ppm and that one should adjust the kernel tick value (with "tickadj -t ...") to bring it to within those boundaries. In preference, it states that (if you're a "screwdriver programmer" :-)) you can (and should) adjust your system clock to correct the offset. Unfortunately, most PCs these days don't seem to have a trimcap to play with :-( Note especially that the "dispersion" derived by XNTPD is a measure of how much jitter it perceives between your clock and the remote reference and provides a statistical window within which measurements are considered credible enough upon which to act. If you have any significant traffic on the link between you and the reference which causes the poll latency to vary beyond this dispersion value, the local jitter becomes almost irrelevant. To quantify this, an unloaded 64k ISDN link can incur a 28mS latency. Add some news to it and, courtesy of the various order-uncertainties in propagation, that can deviate by as much as 2 seconds. Now add the uncertainties inherent on the other links that feed into the 64k and ... Bluntly, NTP over a modem-based connection is statistical guesswork which you should expect to wander all over the shop as link traffic varies. michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511010831.TAA10618>