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