[ntp:questions] Re: HOWTO prepare ntpd to the leap of a second
David L. Mills
mills at udel.edu
Sun Dec 25 01:36:26 UTC 2005
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
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
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
> What do you mean? The leapseconds file is not refreshed in cascade up
> the stratums? Or is it lost at each Autokey restart?
More information about the questions