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

David L. Mills mills at udel.edu
Thu Jan 5 15:47:35 UTC 2006


Roman,

You are on the wrong trolley. The frequency and time disciplines are 
inexorably intertwined. The engineering design has been thoroughly 
studied, analyzed and simulated in vitro and vivo. You are invited to 
criticize and contribute, but you should see the papers and reports on 
the NTP project page first. It is not a question of reacting to specific 
perceived shortcomings, but a holistic strategy of the overall design. 
Having said that, there is an inviting opportunity to explore possible 
improvements using the NTP simulator included in the distribution.

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