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
