Joe,
The intended application and behavior scenario of the prefer keyword is
are carefully explained on the "Mitigation Rules and the prefer Keyword"
page in the documentation. Your expectation goes beyond the intend
stated in that page.
Dave
Joe Harvell wrote:
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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
