Jeffrey Lerman wrote:
Assuming that the current ntpd design spec is that:
a) Leap second flags can be cleared by EITHER the passage of the
actual leap second, OR the receipt (at any time) of a LI=0 from the
current upstream server
b) Leap second flags can be set by receipt (at any time) of LI != 00
from the current upstream server (or also from reading a leap-second file?)
Then it seems that it's important that the leap status in reply packets
be correct at all times.
On Unix-like systems supporting kernel PLL the leap second warning
received from an upstream server, from a refclock, or from a leap second
file is simply passed down to the kernel, starting an hour or so before
the leap event time.
The kernel then cares about handling of the leap second, so ntpd has to
wait until the kernel has finished doing so, and then ntpd can disarm
its internal leap second warning which is passed to its clients.
If there is even the slightest deviation in
the moment at which a server's reply packet LI value changes to 00, then
there will be trouble -- too soon and we risk clients missing the leap,
too late and we risk arming a bogus leap.
In my opinion "too soon" would have more impact here since clients could
disarm their leap second handling if they receive a reply from a server
without leap warning shortly before the leap second.
It would be very hard to have ntpd disarm its leap status immediately
when the kernel has finished handling the leap second. It could be
polling the kernel's status to see when the kernel has cleared his leap
flag, but the result would also depend on *when* the *kernel* clears the
leap flag.
Bearing in mind that I don't know if the actual design spec matches what
I wrote in a) above, but assuming for argument's sake that it does: It
seems to me that that's a brittle system. One way to add robustness
would be to program clients to independently set LI=00 during, say the
first half of the month, and to ignore the LI value from servers during
that time. That provides a (very long!) buffer time during which the
server can get around to zeroing the LI field, and should prevent bogus
seconds from propagating easily.
That sounds reasonable, and I could have sworn ntpd would refuse to
accept a new leap second warning a few seconds after a leap second had
just occurred. However, this does not seem top be the case.
Maybe a restriction in ntpd to accept incoming leap warnings only during
the last days of a month would help.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
