[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline
harvell at nortel.com
Fri Sep 22 21:49:17 UTC 2006
Thanks for the information about fallback local reference clocks. This will help me when I talk to whomever is responsible for the NTP configuration in this lab.
> Normally, I believe, if you have just two servers and they have non-
> intersecting error bounds, they will both be rejected and the
> system will free run. However, I think that prefer confuses the issue,
> by not allowing the preferred one to be discarded. I have a feeling
> this is actually done by saying that the system stops discarding when
> it would discard that one. I suppose that the other one could still
> be in contention at that point.
I agree that the "prefer" keyword doesn't make sense in the case of an NTP client without a physical clock.
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, 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.
I wonder if whoever decided to use the "prefer" keyword thought it would serve the same purpose as putting the fallback reference clocks at different strata.
I'm not sure I can readily reproduce the scenario without the "prefer" keyword being used. But I can look into doing this if it would help.
> The expected behaviour is that this has happened because one is giving
> a false time and the other is giving UTC time. The remaining servers
> will also give UTC time, so the bad one will get voted out.
> I don't think prefer is intended to deal with broken clocks, only with
> more accurate ones.
More information about the questions