[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


David,

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.

Dave

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 mailing list