[ntp:questions] Re: NTP and DCF77 leap logs
David L. Mills
mills at udel.edu
Thu Jan 5 15:53:46 UTC 2006
I've said this several times; I say it again. The frequency surge must
be a bug; the only acceptable behavior is either to obey the leap as
designed or to ignore the leap and coast for 17 minutes one second off
the sources and then step to the correct offset. The frequency should
not be affected. This is not a case of frequency discipline
mismanagement; this is a bug.
Serge Bets wrote:
> On Tuesday, January 3, 2006 at 13:03:26 +0100, Serge Bets wrote:
>>But what happened 2 hours before is much less clear.
> Update after some more log crossing, and a pair of replay experiments:
> The bad frequency I saw on Windows was entirely due to a perturbating
> source 2 hours before the leap. Now, the fact that this initial
> perturbation was not at all stabilised and even aggravating 22 hours
> later is really annoying.
> The Windows ntpd specific new super-fast slewing works very well, as 2
> replays in normal conditions have shown me a very clean post-leap
> behaviour. Stable frequency and offset. Bravo Martin.
> In contrast, I replayed a leap with older code: False time during
> 10 minutes, time reset -1.000938 s at 0:10:46, and frequency explosion
> -629 followed by a long period of instability. Many other time resets.
> I can imagine what would happen if Murphy makes sources unreachable at
> this moment... Wander of 3 centuries per minute.
> Conclusion: The inclusion in the daemon of code doing the leap on
> platforms where the kernel does not itself leap should be reevaluated.
> Bug 508 discussion shows it's not easy to do universaly right, but the
> Win prototype from Meinberg nicely proves it's possible.
> While at it, I also simulated a negative leap deletion: Step +1 and
> frequency explosion exceeding +500 PPM unfortunately.
More information about the questions