[ntp:questions] Re: Drift handling....

Richard B. Gilbert rgilbert88 at comcast.net
Thu Jan 5 14:53:25 UTC 2006


Roman Mäder wrote:

>>Next, the ntpd-server should have some strategy to handle with the
>>situation. A few suggestions:
>>
>>a) recalculate the 'actual' drift against other servers, and reconsider
>>the server selection in case other servers result in a 'sane' drift
>>value, or use a 'weighted average offset', weighting the 'good' servers
>>more than the others;
>>
>>b) recalculate the drift over a longer period (until it is within, or
>>limited by the 'normal range') and use that one (1s additional offset in
>>a 20s period results in a much larger calculated drift then 1s
>>additional offset over the past few hours or day);
>>
>>c) don't adjust your drift at all, but assume that a 'glitch' caused the
>>additional offset; correct for the additional offset, and continue with
>>the same drift value (or adjust it a very little bit);
>>    
>>
>
>if an inexplicable (to ntpd) glitch happens, make as few assumptions as
>possible. Probably the mode that ntpd uses when it starts without a drift
>file is useful here. Something like:
>- correct any offset
>- get a quick estimate of the drift
>- resume normal operation
>
>Roman
>
>  
>
I don't see how your proposal would help in the actual case!  Given that 
half the world's servers step the leap second and half fail to do so, it 
makes a big difference which servers you use to calculate the drift.

Of course the leap second screwup is one of those things that never 
should have happened and should never happen again.  The trouble is that 
it, or something like it, will probably happen again, a consequence of 
Murphy's Law.

If you know that there is a leap second coming and are sure that your 
system handles it properly, then you can tell which servers to believe 
and which are suffering from temporary insanity.




More information about the questions mailing list