[ntp:questions] prefer keyword and server failover

David L. Mills mills at udel.edu
Tue Apr 29 15:29:08 UTC 2008


See the documention on the true option of the server command. Compare 
with the prefer and noselect options.


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