[ntp:questions] prefer keyword and server failover
David L. Mills
mills at udel.edu
Tue Apr 29 15:29:08 UTC 2008
David,
See the documention on the true option of the server command. Compare
with the prefer and noselect options.
Dave
David Woolley wrote:
> Danny Mayer wrote:
>
>> It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2
>
>
> As far as I can see, the intersection algorithm hasn't changed.
>
>> of the NTPv4 draft for the current selection algorithms. Particularly:
>>
>>> If the selection
>>> algorithm cannot produce a majority clique, or if it cannot produce
>
>
> Note the "or" in the condition for rejecting everything; that's an "and"
> for not rejecting. The CMIN check is done, rather later, and only if
> the absolute majority check succeeds.
>
> As it happens, there is an undocumented option in the code of 4.2.4p4
> which allows one to force a peer to be a truechimer, even though it
> fails the intersection algorithm, but an ordinary users isn't going to
> find that option.
>
>>> at least CMIN survivors, the system process exits without
>>> disciplining the system clock. If successful, the cluster algorithm
>>> selects the statistically best candidate as the system peer and its
>>> variables are inherited as the system variables.
>>
>>
>> CMIN is currently 1. Notice that it says nothing about using more than
>> one.
>
>
> All that means is that if you only have one clock that passes sanity, it
> will be used. If you have two that pass sanity and they are
> incompatible, they will have been eliminated before it even gets to the
> CMIN test.
>
> I'll leave it to Dave Mills to volunteer the undocumented option, if he
> thinks it is safe to use in this application.
>
> (The use of orphan mode can also override the intersection algorithm.)
More information about the questions
mailing list