[ntp:hackers] [ntpwg] Further to the timestamping issue
David L. Mills
mills at udel.edu
Tue Jun 17 02:31:55 UTC 2008
I don't understand what you mean by "current behavior"; the currennt
behavior is documented on the ntpd page in the online documentation.
Earlier this year I reworked the code to handle appointment errors as
you describe. However, you might be using an older version. There was
some discussion on this list at that time; you might find it in the
Briefly put, a leap appointment is made from the NIST leapseconds file
or imported from a server using an autokey extension field. When the
clock is set, a counter is set as the seconds to the leap, if there is
one. The NIST file expires and must be retrieved from time to time and
appointments remade if necessary. In principle, you could make an
appointment in July to take effect in December and then go offline until
The WWV and WWVB leap warnings apply at the end of the current month. If
an appointment has not been made from either the NIST file or autokey
and a majority of peer leap warning bits are set, a leap appointment is
made for the end of the month. If less than 23 hours remain to the leap,
the system leap bits are set. If the clock is stepped or the system
restarted of less than a majority of peer leap warning bits are ser, the
appointment is cancelled.
The only requirent is that the clock must be updated during the day
before the leap in order to arm the kernel. Presumably, should you go
offline, either the local clock driver or orphan mode is configured to
take care of that. Addtional details are in the ntp_proto.c source file.
Rob Seaman wrote:
> Poul-Henning Kamp wrote:
>> The current leapsecond handling gives a very short warning about
>> an impending leapsecond, despite the fact that we know six months
>> in advance that it will happen.
> First, thanks to Poul-Henning for raising these issues.
> I would be as concerned as PHK, if his assertion is true. Dave says
> it is not. Which is it? Does NTP practice differ from NTP theory?
>> A device which is "off the net" during the short interval around
>> the leapsecond, will not know to do the right thing.
> A device can be unreachable for either a short or long interval. One
> obvious issue is that the local clock will drift, so the leap second
> will only be synchronized locally - but that is true of everything
> done with the clock during such an interval.
> The other case is if the device is down, not simply out. In this
> case, the leap second should (perhaps) be omitted. Basically it turns
> into a pragma to inform the clock's initialization method.
> In either case, the question is whether the leap second schedule has
> been persisted locally in advance. This seems no different than any
> other appointment calendar application. If an appointment is missed,
> it is skipped - no rescheduling for leap seconds. On the other hand,
> if a clock ticks in the woods and there is nobody to hear - the alarm
> still rings.
> David L. Mills wrote:
>> Warnings can be months in advance if armed from the leapseconds
>> file. The leapseconds values include the epoch of the next/last leap,
>> the epoch of expiry and the TAI at the next leap and up to a month if
>> from leap bits. We don't need a field for the next leap; we already
>> that. And, once the epoch has been determined, the client can go off-
>> and still leap the leap.
> All factions of the leap second debate support lengthening the six
> month scheduling lookahead. This would require no change to any
> standard. Is NTP ready to accept leap second schedule updates years
> in advance - and still realize reliable leap second handling? If not,
> what needs to change?
> There has also been discussion on LEAPSECS about publishing a rolling
> schedule that looks forward through several leap seconds. It appears
> that the state of the art for Earth Orientation modeling may soon
> allow sufficiently accurate prediction for a lookahead of several
> years. This would change the NTP "arming" paradigm into something
> much more clearly recognizable as a distributed appointment schedule.
> Which is to say that NTP now assumes that there are periods of time
> when a leap second has been announced, and periods when no leap second
> has been announced. In the future - and with no need to change ITU
> 460-4 - it may be the case that (multiple) leap seconds have
> perpetually been announced to the world. (The soonest ITU 460-4 might
> change now appears to be 2019.)
> I especially like the distinction in
> between how UTC reckons leap seconds and how NTP deals with them.
> The former would remain unchanged - the latter may have to adapt (and
> perhaps to NTP's betterment).
> Poul-Henning Kamp wrote:
>> I fail to fully appreciate how you compressed that into the
>> two bit field of the NTPv4 protocol.
> See ntpEntStatusLeapSecond and ntpEntStatusLeapSecDirection. How
> these values are loaded is an implementation detail, e.g., Autokey.
> There certainly is no requirement that every packet contain the full
> Rob Seaman
> National Optical Astronomy Observatory
> ntpwg mailing list
> ntpwg at lists.ntp.org
More information about the hackers