From owner-freebsd-current Wed Nov 1 00:32:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA02396 for current-outgoing; Wed, 1 Nov 1995 00:32:21 -0800 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA02384 for ; Wed, 1 Nov 1995 00:32:13 -0800 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id TAA10618; Wed, 1 Nov 1995 19:31:18 +1100 From: michael butler Message-Id: <199511010831.TAA10618@asstdc.scgt.oz.au> Subject: Re: Time problems To: bde@zeta.org.au (Bruce Evans) Date: Wed, 1 Nov 1995 19:31:17 +1100 (EST) Cc: current@freebsd.org In-Reply-To: <199511010723.SAA20983@godzilla.zeta.org.au> from "Bruce Evans" at Nov 1, 95 06:23:37 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2217 Sender: owner-current@freebsd.org Precedence: bulk > >>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