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: <[EMAIL PROTECTED]>
From: Joe Harvell <[EMAIL PROTECTED]>
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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
