[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline

David Woolley david at djwhome.demon.co.uk
Sat Sep 23 11:09:46 UTC 2006

Message-ID: <ef1lot$l5$1 at zcars129.ca.nortel.com>
From: Joe Harvell <harvell at nortel.com>

> Documentation about the "prefer" keyword states that if the prefer
* peer survives the selection algorithm, then it will always survive the
* clustering algorithm.  Additionally, if the prefer peer does survive,

That should say "intersection", not "selection"; the clustering algorithm
is part of the selection algorithm.  However it does have the effect
you are quoting.

* then the combining algorithm is not used, and the "prefer" peer's clock
* is supposed to be the only clock used when correcting the local clock.

> So if the two servers have non-intersecting error bounds, then I would
* expect both peers (including the "prefer" peer) to not survive the
* selection algorithm, and the local clock should free run.

Looking at the 4.2.0 code, I would agree.  However, just after a step
event, one server will become eligible before the other, so there will
be a time when you only have one server to choose from.

Also, 800 seconds in 22 days is close to 500ppm, which may mean that
one of your servers is on its frequency correction end stop, in which
case there is a 50% chance that you will be unable to track it purely
by slewing.

Generally, it would be much easier to work out exactly what was happening
if we had the syslog entries and ntpq peer command results at frequent
intervals.  Doing ntpq rv on the client and the server associations might
help even more.

Some issues from other threads:

The reason that 512ms is an overflow is that the kernel uses scaled
integers, accepting measured offsets with a basic resolution of 1
microsecond, but needs an additional 12 bits of precision to perform
the filter calculations.  One suspects that the microsecond resolution
might have been compromised if this had not been possible.

More information about the questions mailing list