[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