[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline
David L. Mills
mills at udel.edu
Sat Sep 23 17:34:39 UTC 2006
The default behavior, different from my better judgement, is to accept
synchronization from a single survivor, which is the default "tos
minsane" behavior. As it says in the comments in ntp_proto.c, careful
operators will set that value to something higher, assuming at least
that number of servers is available. The default is set at one, as most
casual operators would scream a violation of the Principle of Least
Astonishment if the daemon did not latch on to a single server. Das Buch
contains an extensive discussion on these issues.
David Woolley wrote:
> 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