David L. Mills wrote:
Serge,
You really should read the commentary in the NIST leapsecond file,
which explains the rationale for when the file is issued, the epoch of
insertion and the current TAI offset. The file does not expire when
the leap is inserted; it remains valid as a record of past TAI offsets
until the next edition is issued.
It could be that some sites have an old edition and others a newer
one. The Autokey protocol compares the leapsecond tables for itself
and its upstream servers and uses only the newest one. If the client
has dependent clients, it passes only the newest table to them.
When multiple valid sources display conflicting leap bits, the logical
OR of these bits is used. While a more sophisticated decision algorthm
could be used, the most common error is when an upstream server does
not implement or recognize the leap condition. Thus if a server sets
the bits, it probably knows what it is doing.
Dave
Serge Bets wrote:
On Thursday, December 29, 2005 at 14:16:09 +0000, David L. Mills wrote:
Serge Bets wrote:
The NIST file is absolutely true until expiration. This fact is not
exploited by the NTP daemon, but could perhaps be.
I don't understand your concern.
The NTP daemon will not assert leap=00 against any bogus source wrongly
saying leap=01 during June 2006.
The authority of the soon updated NIST leapseconds file, expiring only
later on 29 December 2006, thus valid, and showing no leap event on
30 June 2006, could perhaps be used to force correct leap=00.
Effectively overruling the less sure leap bits of other sources.
Serge.
Does ntpd maintain a copy of this leap second file somewhere? Where?
I'd always assumed that NIST servers set the leap second bits when it
was time to set them; that they propagated downward and the leap second
happened automagically, everywhere. Does GPS propagate the leap second
bits?
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
