[ntp:questions] prefer keyword and server failover

David L. Mills mills at udel.edu
Mon Apr 28 17:12:58 UTC 2008


To be fair, the basic selection algorithm has not changed from rfc1305, 
although the root distance metric and error budget have changed due to 
the much more precise clocks of today. It remains true that two sources 
with nonintersecting correctness intervals results in no source at all.

What is different is the adjustable tos parameters minclock, maxclock, 
minsane and other tinkerables. The minsane parameter is the minimum 
number of sources required for correct synchronization. It really should 
be equal to the minimum number of survivors minclock (3). It defaults to 
one only because most people would consider otherwise a violation of the 
principle of least astonishment.


Danny Mayer wrote:
> David Woolley wrote:
>>Danny Mayer wrote:
>>>David Woolley wrote:
>>>>Richard B. Gilbert wrote:
>>>>>Sort of!  Two servers is generally a poor choice.  If they differ, as 
>>>>>they inevitably will, which one should you believe?  'Prefer' will tell 
>>>>If they differ enough for voting to apply, both will be rejected.  If 
>>>>they are mutually true chimers and you don't use prefer, ntpd will use a 
>>>>combination of the time from both of them.
>>>No, it will choose one and use it until it decides that it is worse than 
>>>another one or they are all declared bad. It never combines both. The 
>>>real problem here is that it has no idea whether or not one is better 
>>>than the other when you only have two of them.
>>For RFC 1305, and I have no reason to believe this has changed, given m 
>>  servers that pass the basic sanity check, it will start with another 
>>parameter, f, at 0 and try to find m -f intersecting servers.  It will 
>>try with successively greater values of f until it finds a mutually 
>>intersecting set of servers. However, if f equals or exceeds m/2, it 
>>will stop with all servers marked as falsetickers.  m/2 = 1 in this 
>>case, so the termination condition will be met after one iteration, and 
>>it will fail to find any truechimers (the low end of the range will be 
>>set to the low end of the second server tolerance (search is done 
>>forwards) and the high end of the range will be set to the high end of 
>>the first (search is done backwards).
> It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2 
> of the NTPv4 draft for the current selection algorithms. Particularly:
>>If the selection
>>   algorithm cannot produce a majority clique, or if it cannot produce
>>   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.
> Danny

More information about the questions mailing list