Serge,
Scarfing the current leapsecond file from NIST should not be a problem
with a shell script and cron job. If Autokey is enabled, even with no
server marked to use it, the file will be loaded and the leap bits set
accordingly. If Autokey is running with a number of servers, only the
latest data are used. Since old leap epoches don't change, the only
thing that can happen is the addition of a new epoch at the next
opportunity.
With Autokey each association is restarted once per day, so the latest
leapsecond data will be retained from each server. If those servers do
the same thing, it may take a few days for the data to flow from an
authoritative source.
Dave
Serge Bets wrote:
Hello David,
On Friday, December 23, 2005 at 2:08:02 +0000, David L. Mills wrote:
the kernel must include provisions to implement the leap. The ntpd
does not actually do the leap, just tell the kernel to do it.
First much thanks for all the infos. I was focused on the NTP leap bits,
not the way kernels are informed and do the leap. I'll add a paragraph
about that.
Autokey must be running in order to load that file so the leap bits
can be correctly set.
Yes. In some way loading the NIST file has an interest even outside of
Autokey, and those functions could be less dependant. It would benefit
to ease of use, and permit the file features even --without-crypto. Note
that's just loud thinking, not a suggestion.
Plan B: Rely on upstream servers to set the leap bits.
This is the default plan, when user does nothing special. It may fail,
for a variety of reasons like no leap bits in MSF radio, too late
announcement, or the spurious insertion announced some monthes ago at a
wrong date by some buggy GPS receivers.
I like to think to plan A as a way to cleanup those maybe wrong upstream
leap bits. Again loud thinking, that could mean use file and totally
ignore upstream, until the file expires. Then resume confidence to
upstream. Unless the notified operator has refreshed the file.
Hum... This would need at loading to extract the expire date from file,
and in Autokey to make use of it as fs, instead of modification date. So
that files with 6 monthes extended validity but no new leap event get
transmitted to Autokey peers as beeing newer. Don't know if it would be
feasable at all.
The Autokey protocol is restarted automaticall once each day and
refreshes the leapseconds file, but only from the direct upstream
server
What do you mean? The leapseconds file is not refreshed in cascade up
the stratums? Or is it lost at each Autokey restart?
Serge.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
