[ntp:questions] Re: ntp servers reporting leap second erroneously?

David L. Mills mills at udel.edu
Tue Oct 25 23:49:17 UTC 2005


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.


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

More information about the questions mailing list