Re: Ambiguous NTP timestamps near leap second

From: Warner Losh <imp_at_BSDIMP.COM>
Date: Thu, 16 Feb 2006 12:31:30 -0700 (MST)

> "M. Warner Losh" wrote on 2006-02-14 21:18 UTC:
> > ntp time stampes are ambiguous at leap seconds (the leap indicator
> > bits aren't part of the time stamp, exactly), which is a good reason
> > to change them. However, the cost to change them could be quite high
> > if done in an incompatible manner.
>
> No, this ambiguity alone is surely not a good enough reason to change.
> It can be fixed trivially in a backwards compatible way, without
> introducing TAI or leap-second status bits. Simply add to the NTP
> specification the paragraph:

The leap status bits are already in the time echange packet, but not
part of the timestamps themselves. You need the whole packet to know
which second the timestamps are from. The problem comes when the
timestamps strattle a leap event, or when the timestamps are
propigated to parts of the code taht don't have the leap status
bits...

> No reply from an NTP server shall ever represent any point in time
> between 23:59:60 and 24:00:00 of a UTC day. If a client requests an
> NTP timestamp and the response would represent a point in time during
> an inserted leap second, then this request shall be ignored.

The problem isn't the inserted leap second, since the status bits are
the same for it as for the previous second. The problem is the
following second. However, the problem could be kludged around in
that way. It isn't a perfect solution, since it opens up the
possibility of a reduced amount of data (TAI wouldn't suffer from
that). However, it is a good enough solution in that this loss of
data is typically non-critical and the timing window is small.

> Rationale: NTP runs over UDP, and therefore must be (and is perfectly)
> able to cope with occasionally dropped packets. Dropping NTP server
> reply packets for one second every few years will hardly affect any
> application, because NTP clients already implement robust retry
> and filtering mechanism today.
>
> NTP is actually one of the simple cases, where no harm is done by simply
> going offline very briefly near a leap second. In other applications,
> e.g. streaming media, things are not that easy, and other workarounds
> are needed if one wants to remain backwards compatible with existing UTC
> practice while minimizing the chance of leap-second induced
> malfunctions. UTC-SLS is what I'd recommend for most of these cases (but
> not for the NTP protocol itself).

But won't stretching time in one part of the system result in
anomalous resutls in these multi-media applications? They play out
their data in TAI seconds not UTC-SLS due to hardware oscillators that
pace the output of the data. Long, large slews in system time
evolution would cause the system time to elapse at a different rate
than the media is played out, even when it isn't playing out over the
leap second. Real multi-media applications will still need to run in
UTC time so that the external timing requirements would still be met
if this media were destined for down-stream consumers (eg, TV stations
couldn't use UTC-SLS since they have to broadcast at a fixed field
rate that can't be stretched or shrunk by a part per thousand).

That's the problem with UTC-SLS. It is good enough for the wrist
watch crowd, but there are many applications that it is ill suited for
where one must use TAI or UTC, and many of these applications may be
co-located on the same box.

Warner
Received on Thu Feb 16 2006 - 11:35:05 PST