[ntp:questions] Re: ntp servers reporting leap second erroneously?
David L. Mills
mills at udel.edu
Sat Oct 15 16:36:08 UTC 2005
The spec is incorrect. The leap bits are turned on when the sources,
radio or NIST file, say so. The ntpd code announces to the kernel on the
day of the leap. The reason for this behavior is that the poll interval
can now be over one day and the kernel might not get the information in
the leap day.
Rex Vincere wrote:
> According to RFC 2030:
> Leap Indicator (LI): This is a two-bit code warning of an impending
> leap second to be inserted/deleted in the last minute of the current
> day, with bit 0 and bit 1, respectively, coded as follows:
> So, does this not mean that the LI should be turned on *only* on the day of
> the leap second?
> According to RFC 2030 then, all the servers indicating leap second before
> December 31st is in error.
> "David L. Mills" <mills at udel.edu> wrote in message
> news:dioddl$gc1$1 at dewey.udel.edu...
>>What makes you think this is a problem? The leap second display is
>>entirely and with emphasis purposeful. There is in fact a leap second
>>intended for the end of the year. The NTP servers will in fact show that
>>indication exactly as intended. On the last day of this year the kernel of
>>those compliant systems will be advised of the leap and those kernels will
>>implement it on the last second of the year. Those kernels that do not
>>implement the leap will observe the leap in 900 seconds and then regain
>>accurate synchronization. What is your problem?
>>Rex Vincere wrote:
>>>Recently I have noticed that a number of servers (on and off), and
>>>especially louie.udel.edu (all the time) are reporting a leap second.
>>>This has been going on for a couple of weeks now.
>>>This is the first time in about the 10 years I have been playing with NTP
>>>that I have seen a problem like this pop up.
>>>Or is this not a problem but a change to NTP I missed?
More information about the questions