Date: Mon, 28 Apr 1997 05:07:20 +1000 (EST) From: michael butler <imb@scgt.oz.au> To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: peter@spinner.dialix.com, current@freebsd.org Subject: Re: cvs commit: src/etc rc rc.network Message-ID: <199704271907.FAA21987@asstdc.scgt.oz.au> In-Reply-To: <199704271444.KAA08965@khavrinen.lcs.mit.edu> from Garrett Wollman at "Apr 27, 97 10:44:53 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman writes: > <<On Sun, 27 Apr 1997 21:47:34 +0800, Peter Wemm <peter@spinner.dialix.com> said: > > Apr 27 10:39:07 pasteur xntpd[171]: time reset (step) -0.418709 s > > Apr 27 10:45:01 pasteur xntpd[171]: time reset (step) 0.561284 s > > remote local st poll reach delay offset disp > > ======================================================================= > > *tictoc.dap.CSIR 203.12.3.8 1 256 377 0.05458 -0.061465 0.03783 This is normal on overpriced and under-powered Australian links where latency from one instant to the next is highly variable :-( > You don't really give enough information here... There are two > possibilities: > 1) If that is your only server, then it's clear, you have substantial > jitter on the link to it which is causing NTP to step all over the > place. This is a flaw in xntpd, but it can't be fixed without having > either a super-stable local clock, .. You can (sort of) fudge this by telling it that the local clock is one of the references, e.g. by adding .. server 127.127.1.0 fudge 127.127.1.0 stratum 10 .. to /etc/ntp.conf. When a real (as in .ATOM.) reference clock jitters too much (as seen at your place), xntpd will notice that the deviations are beyond the dispersion window considered "sensible". Since it has a (fudged) local reference with less deviation, it "locks" to that even though it's essentially free-running (modulo the accumulated/learnt drift stats which it continues to apply). When the external link recovers enough to display a consistent error over successive samples, xntpd reacquires the desired source. Using this approach, a local machine can be configured to appear to be a "locked" reference for most of the time despite the jitter. Other machines on the same ether will get up to the expected 1024 second poll period, no troubles. However, the instances of oscillatory stepping are only reduced by this, not completely eliminated :-( A GEOS receiver of your own is probably best if it's really that critical, michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704271907.FAA21987>