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. 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.
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.
Thoughts?
--Jeff
On 8/2/2012 7:20 AM, Martin Burnicki wrote:
Jeffrey Lerman wrote:
How are the leap-second flags meant to be cleared after a leap second?
Is it supposed to be automatic? Is there a bug in some code (ntpd or
elsewhere) that is failing to clear the flag in (some versions of) ntp
server software?
I've just run some tests. On a test machine:
- configured ntpd to use the current leap second file
- configured the local clock as only ref time source
- set the system date/time to 2012-06-30 23:59:45 UTC
- started ntpd
On a different machine:
- ran a test program which sends 4 requests/s to the test machine
and prints the contents of the reply packets, including leap status
Found that with both the current stable version (4.2.6p5) and a
current dev version (4.2.7p290) the leap second warning in the reply
packets already disappeared shortly *before* the leap second actually
occurred.
This means if this server sends a reply to a client shortly before the
leap second the leap warning may have already been turned off, and
thus the client might *disarm* the leap second shortly before the leap
second occurs. This sounds like a bug to me, so I'm going to file a
bug report for this.
Anyway, this does *not* seem to be directly related to the actual
problem where the leap bit is not reset at all, or is set again if
there's a time source which still has the bit set immediately after
the leap second.
For completeness I've repeated the same test with the latest version
of the 4.2.4 branch, namely 4.2.4p8. This version of ntpd resets the
leap warning bit in the leap status sent to clients a few seconds
*after* the leap second, so this could be a possible issue for clients
accepting a new leap warning immediately after a leap second has
occurred.
I did check earlier this morning and I was unable to
find a bug filed against ntpd regarding this issue - does anyone know if
we should go ahead and file a bug? It'd be nice to have more
information on whether this is really an ntpd issue.
I'm sure a bug will be filed, but eventually we should first find out
more details so we can write an appropriate summary of the issue.
Martin
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
