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