Terje,
The NTP daemon has no idea how to handle leapseconds, only to notify the
kernel that one is to occur. You should ask the kernel how it does that.
As described in the white papers at the NTP project page, one approach
is to stop the clock at the end of the previous day and start it up
again one second later. Whatever method you use, you want to slow the
clock progress down during the second, not speed it up.
The method used in the kernels that have my code is to actually set the
kernel time variable back one second, but force the clock value returned
to the caller always to be monotonically increasing, even if at a slow
rate. There is a diagram and detailed discussion in the white paper.
Dave
Terje Mathisen wrote:
David J Taylor wrote:
Hal Murray wrote:
As I've reported earlier on this news group even the Windows w32time
service is capable to slew the Windows system clock at UTC midnight
to compensate the leap second offset in just a few seconds.
How fast does Windows normally slew? I was expecting it to be 500
ppm which would take a long time to slew a whole second.
IIRC from the earlier posting W32time actually doubled the clock speed
(SetSystemTimeAdjustment) for two seconds. Is that how others read it?
Yes, that seems like the obvious way to handle it.
ntpd must calculate this as an extra adjustment on top of the current
drift value, so to avoid messing up clock stability.
You can of course discuss how fast this adjustment should be applied,
but my thinking is that such an exceptional situation should be handled
quickly.
Most people will be able to accep a timing glitch happening around the
exact leap second epoch. I.e. I think 2 seconds to get back in sync is fine.
Terje
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
