[ntp:questions] Re: HOWTO prepare ntpd to the leap of a second
serge.bets at NOSPAM.laposte.invalid
Fri Dec 23 20:49:19 UTC 2005
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
> 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?
Serge point Bets arobase laposte point net
More information about the questions