[ntpwg] [ntp:hackers] Further to the timestamping issue

[Rob Seaman]

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  
> have
> that. And, once the epoch has been determined, the client can go off- 
> net
> 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 http://www.cis.udel.edu/~mills/leap.html 
  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  
schedule.

Rob Seaman
National Optical Astronomy Observatory