[ntp:questions] Re: Make NTP timestamps leap-second-neutral (like GPS time)

hack hack at watson.ibm.com
Wed Jan 7 21:30:05 UTC 2004

In article <3FFC5316.1A702436 at udel.edu>, David L. Mills <mills at udel.edu> wrote:

>1. Dealing with historic leap seconds is easy assuming you run the
>Autokey security protocol or snatch the leapseconds table from NIST.
>3. Again if Autokey is lit, the current TAI - UTC offset is returned in
>the ntp_gettime() call, so TAI is always available for the current epoch.

Good.  Historic leaps weren't my main concern, and I have no improvement
to offer here.

>While it would not be hard to in fact run NTP on TAI, there are some
>gotchas you might not have stumbled on. First, consider what NTP is now
>used for: stock transactions, broadcast program coordination, ...

Oh, I fully agree that UTC is what really matters almost all the time.
That's why I would like to see the 2000-based LSO included in every packet,
so UTC can be derived from it immediately.  The difference between that LSO
and the official TAI-UTC would be a constant 32 seconds.

>As a practical matter, no national means for time dissemination other
>than GPS provides TAI directly or the TAI - UTC offset. Even in the case
>of GPS, receivers providing the offset are very few and those I know
>that do are no longer manufactured. If only UTC is available from the
>radios, the TAI offset would have to be known by some other means before
>NTP primary servers could deliver TAI. Apparently, should TAI be
>required, the NTP daemon would have to obtain the leapseconds table by
>some means before timetelling could begin. This is really hard for
>embedded systems like routers and traffic light controllers and your
>microwave, for that matter. This has always been the showstopper in any
>argument to run TAI instead of UTC.

Well, the revised NTP would *be* the (inter)national means for disseminating
the *current* LSO (not the whole historical table).  The problem for a local
stratum-1 that wants to support the new protocol is real, and would require
manual maintenance to add future leap second information as IERS bulletins
become available.  (Actually, clever programmers would automate that soon
enough by subscribing to Bulletin C and rigging their mail system to detect
and process the bulletins as they arrive.)  Embedded controllers have no use
for historical leap info -- they just need current UTC, and they can get that
from either old-format or new-format NTP packets.  In other words, the new
mechanism would not invalidate anything that is currently working.  This is
a very important property of protocol changes that I fully subscribe to.

This hinges of course on the ability to update the packet format in the right
way, and I don't have any bright suggestions here, unfortunately.

My main concern is that computer time-keeping will continue to improve, and
will (most likely) eventually run on a TAI-based clock anyway, probably well
before 2035 (but perhaps not 2010).  Now seems a propicious time to prepare
for this: 2000 is a nice round number, and happens to be in an unusually long
leapless period (which may end soon -- but I thought that 2 years ago already,
and I wonder what Terje thinks, given the predictions he made in 1999 in this
forum).  And that NTP jiggle (pinballs?) around leap time bothers me as a
matter of principle.


Separate, but related issue:  could the leap jiggle be avoided with the
*current* protocol?  Perhaps, and I'll address it in another post -- even
if it undermines my argument for revising the protocol.


More information about the questions mailing list