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

David L. Mills mills at udel.edu
Thu Jan 5 15:38:17 UTC 2006


Roman,

Disregard the frequency discipline; that's has to be a bug and must be 
fixed. As for the mitigation when some sources show leap and others not, 
the code does leap if any acceptable source leaps. Either the kernel 
leaps or there will be a 17-minute interval when the sources have leaped 
before the client does leap. The frequency should have nothing to do 
with that.

Dave

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
> 




More information about the questions mailing list