[ntp:questions] Re: Leap second talks are postponed
David L. Mills
mills at udel.edu
Mon Nov 21 17:05:10 UTC 2005
The implementations including my code do not step the clock, just stop
if or allow it to progress slowly during the leap second itself. If what
you mean by slewing is to force the clock to amortize the second at
"normal" slew rate, say 500 PPM, then the clock would be in error very
close to one second following the leap and take the better part of one
hour to resume expected accuracy. Meanwhile, NTP would scream and holler
because the step threshold would be exceeded. Of course, should you be
concerned about step corrections and forbid them as configuration
option, your applications would have to be content with the large error
during the amortization interval.
I'm not being facetious here; consider the advice of the IBM mainframe
community when running local time. For the DST spring forward, no
problem - just set the clocks ahead one hour in every timezone. For the
fall fack, stop the applications and turn the machine off for four hours
while all the clocks in the country survive the step. Of cource, should
we ever have a leap second deletion, then the slew issue will occur in
David J Taylor wrote:
> David L. Mills wrote:
>>>Windows W32time appears to handle leap seconds better than NTP on
>>>Windows right now, according to earlier discussions - it avoids the
>>>step change. David
>>You are gloriously misinformed. The NTP daemon does not do leap
>>seconds; the kernel does. NTP is not good or bad, just the messenger.
>>However, the model now used in FreeBSD, Solaris, Linux and Tru64 is
>>derived from my code as described on the NTP project page. You get to
>>smear me in the media based on that model, not NTP. There is no step
>>change in that model, just stopping the clock for the leap second,
>>but allowing forward progress to conform to the correctness
> Well, of course, it's implementation dependant, so my comment was
> addressed to the implementation part, not to NTP itself. Good to hear
> that some OS kernels have adopted your ideas.
> If I'm wrong, please correct me but, as I understand it:
> - NTP will step the clock on Windows at the leap second or sometime
> shortly after.
> - W32time will slew the clock at double its normal rate soon after the
> leap second. This behaviour has only recently been reported.
> To me, the slew seems better than the step. I believe that the Windows
> implementors are looking at updating the code.
More information about the questions