Rex,
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.
Dave
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.
Rex
"David L. Mills" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Rex,
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?
Dave
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?
Rexr
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
