From owner-freebsd-current  Sun Apr 27 12:09:05 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA23833
          for current-outgoing; Sun, 27 Apr 1997 12:09:05 -0700 (PDT)
Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA23825
          for <current@freebsd.org>; Sun, 27 Apr 1997 12:08:56 -0700 (PDT)
Received: (from imb@localhost)
          by asstdc.scgt.oz.au (8.8.5/BSD4.4) id FAA21987
          Mon, 28 Apr 1997 05:07:20 +1000 (EST)
From: michael butler <imb@scgt.oz.au>
Message-Id: <199704271907.FAA21987@asstdc.scgt.oz.au>
Subject: Re: cvs commit: src/etc rc rc.network
In-Reply-To: <199704271444.KAA08965@khavrinen.lcs.mit.edu> from Garrett Wollman at "Apr 27, 97 10:44:53 am"
To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman)
Date: Mon, 28 Apr 1997 05:07:20 +1000 (EST)
Cc: peter@spinner.dialix.com, current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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