[ntp:questions] Re: ntp servers reporting leap second erroneously?
David L. Mills
mills at udel.edu
Tue Oct 25 23:59:15 UTC 2005
Be careful when you change the slew rate. The change itself amounts to
an extra pole in the transfer function and leads to nasty overshoot
behavion in some systems, especially for relatively large corrections.
Fortunately, inserting a leap second amounts to stopping the system
clock or allowing it to proceed slowly. So long as time throughout the
system is well discipline, all clocks should exhibit the same behavior
at the same time; if not they wouldn't be synchronized any more. The
scheme I described has that property.
A little reflection should result in a state machine to realize the
intended behavior. An example is in the nanokernel distribution at
Martin Burnicki wrote:
> Hal Murray wrote:
>>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.
> Maybe the following is a bit nitpicking, but "Windows" doesn't slew the time
> at all.
> Whichever time adjustment service is running, it can modify the tick
> adjustment value under Windows as required/desired.
> 500 ppm is a limitation which is specific to ntpd, and maybe operating
> systems which implement the kernel clock algorithm developed by Dave Mills,
> which is great, BTW. AFAIK the limitation is with respect to the time
> synchronization algorithm and the stability of the control loops.
> Windows doesn't implement Dave Mills' clock model, and other time adjustment
> services are not limited to the 500 ppm value.
> The article I was referring to can also be found in the NTP questions
> mailing list archive:
> In the log output you can see that the tick adjustment value is temporarily
> changed from 156250 to 78125, so the system time temporarily increases with
> half speed only until the time offset introduced by the leap second has
> been compensated.
More information about the questions