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
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
