[ntp:questions] Re: Make NTP timestamps leap-second-neutral (like GPS time)
David L. Mills
mills at udel.edu
Wed Jan 7 18:42:31 UTC 2004
You should add to your proposal that POSIX does in fact run on TAI. So,
you can't set your Atomichron to UTC time unless you dial up the IERS
and see the latest leapsecond bulletin.
As you may know, these issues have been hotly debated by many folks
inside and outside the NTP community. There are several white papers
bearing directly on NTP timestamp calculations, timescales and leap
handling on the NTP project page linked from www.ntp.org. A few
1. Dealing with historic leap seconds is easy assuming you run the
Autokey security protocol or snatch the leapseconds table from NIST. As
part of the Autokey protocol, the leapseconds table is automatically
downloaded from the server; so, assuming a path exists ending at a NIST
server, the upstratum clients can calculate intervals spanning leap
epoches. The retrieval scheme was cooked up by Judah Levine and me and
reported in a PTTI paper. Like all my other papers, this one is online
2. Insertion of leap seconds is completely automatic in the case of
stock FreeBSD and Tru64 kernels, Solaris kernels (not tested) and with
patched Linux, SunOS, HP-UX, Ultrix and probably others. The only
question is the behavior during the leap second itself, as described on
a project page. The behavior you describe where the leap is haphazardly
amortized does not happen, even if the radio itself is haphazard.
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
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, air
traffic control, secure timestamping and very many others. All of these
applications require reference to UTC and some (legal) to UT1. If we
really do want to synchronize worldwide databases, doing so in other
than conventional civil (solar) time does not seem like a good idea.
Even the space community reckons space time relative to TAI, but records
experiment data with UTC timestamps, warts, leaps and all.
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.
Michel Hack wrote:
> Currently, NTP timestamps are defined to represent UTC based on a sliding
> epoch such that UTC can be derived from seconds-since-epoch using simple
> Gregorian conversion (where each day has exactly 86400 seconds).
> I propose to redefine NTP to be tied to TAI (International Atomic Time)
> but referenced to 2000, so that: NTP(2000) = UTC(2000) = TAI-32 = GPS-13
> and from now on: NTP = TAI-32 = GPS-13
> This is a good time to propose such a change. There have been no leap
> seconds since July 1999. I wish I had done so sooner (this here is based
> on an internal memo I wrote a year ago).
> My primary reason for opposing the current definition is to eliminate
> the timestamp jiggle that occurs for several minutes to tens of minutes
> after a leap second event when machines following NTP adjust their epoch
> to absorb the new leap second. Under the new proposal, there would be no
> clock adjustment due to the leap second -- only the rule for converting
> NTP time to UTC would be affected.
> A second argument is that current NTP timestamps make it difficult to
> measure an interval by subtracting time stamps. If the end points
> straddle one or more leap seconds, these have to be taken into account
> (based on a table of Leap Second events). Worse, if one of the end
> points is within the jiggle period that follows a LSE, there will be an
> unpredictable error that could even exceed one second (due to overshoot
> effects during the adjustment period). If the entire interval is
> during the jiggle period, the error might be as large as two seconds --
> a very large relative error in this case since it would be with respect
> to several minutes, i.e. possibly 1%.
> An immediate problem is how NTP would adjust the local clock after a
> Leap Second Event, in an OS that (so far) does not support this well.
> One possibility would be for NTP to defer dealing with it until it is
> in a position to perform a step change, e.g. during bringup. It would
> then maintain an artificial 1-second offset between NTP timestamps and
> OS (e.g. Unix) timestamps until the OS time can safely be changed. NTP
> could also use a linear slew (predictable and invertible) on top of the
> OS time adjustments made as part of the NTP protocol, so as to absorb
> this artificial offset gradually. I'm not sure if this would mesh with
> a Unix adjtimex() that has support for inserting a Leap second at the
> next midnight UTC, because the handling of this may use internal slewing
> that NTP cannot control or know precisely -- I only just came across a
> mention of this when scanning this newsgroup, and haven't studied it yet.
> The proper solution for Unix would be to listen to Marcus Kuhn (see below).
> The argument has been made that tracking TAI as opposed to UTC (when UTC
> is what most users want to see) requires a historical record of leap
> second events. For the purpose of converting past timestamps, this is
> required for the current definition too, since each leap second has
> redefined the effective epoch. For the purpose of converting current
> time, only the current LSO (Leap Second Offset) is required. For the
> purposes of near-future timestamps, the next LSE (Leap Second Event)
> must be known, but NTP already deals with that for times less than one
> day in the future (and other means could be used to cover a few months
> into the future). The most common time reference these days is GPS,
> and its time signal includes the LSO. What is missing however is an
> LSO field in the standard NTP packet format. (*** Need to check whether
> NTP maintenance messages include means to report LSO, which changes
> infrequently after all. For past timestamps, a means to distribute a
> Leap Second Table might be useful -- but I would argue that if any
> program needs updating to pick up this table, it might as well have
> the table canned in. Leap seconds after 2000 may need a distribution
> mechanism -- assuming there will be more leap seconds. ***)
> Coexistence of the new and old protocol has to be considered. If the
> new LSO field is one that is now zero, it could be used to recognise
> the new protocol, because as long as the LSO is zero, old and new are
> fully compatible. Old versions receiving timestamps from new versions
> might not be so lucky: they might treat them as falsetickers if they
> are in the minority. Hopefully everybody would upgrade soon enough.
> If they are *requested* timestamps, the new version could convert them
> so as not to disturb the old version, and that problem could be avoided.
> Only old receivers of new broadcast-mode packets would then be at risk.
> I'd like to mention also that IBM S/390 (and now z/Series) defines its
> TOD clock with reference to TAI -- specifically, IBM = TAI-10 (because
> it was defined to have IBM(1972)=UTC(1972), whereas TAI(1958)=UTC(1958),
> and UTC used corrections more complicated than leap seconds from 1958
> to 1972). This new definition was introduced in the second edition of
> S/390 Principles of Operation, in 1991 I think; the prior definition
> used the same rule NTP, Unix and everybody else seems to use, namely
> make number-of-seconds-in-epoch come out as UTC when converted using
> plain gregorian rules. The operating system (MVS, OS/390, z/OS) keeps
> the current LSO in a public variable.
> Finally, I'm grateful to Markus Kuhn for having written such a thoughtful
> proposal for Unix to deal with UTC vs TAI, Leap Seconds, and local time
> zones: http://www.cl.cam.ac.uk/~mgk25/c-time
More information about the questions