> > 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
