Re: [LEAPSECS] A lurker surfaces

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sun, 31 Dec 2006 19:38:22 -0700 (MST)

In message: <9E593403-D4BB-4DE3-8945-1F7400814976_at_noao.edu>
            Rob Seaman <seaman_at_noao.edu> writes:
: Poul-Henning Kamp wrote:
:
: > Rob, If you feel uncomfortable with calling leapseconds
: > discontinuities, then we can use the term arrhythmia instead.
:
: Which raises the question of why projects requiring an interval time
: scale lacking in such arrhythmias would have selected UTC in the
: first place.

The real world often times requires both kinds of time keeping, with
correlation back and forth between all the timescales. The customers
want to deal with times in UTC. To get an effective, high precision
time system, you need to count seconds in a sane way (UTC isn't a sane
way for this purpose) so some conversion between this count and UTC is
needed.

The problem is that most interesting systems have a need to do things
based on UTC time of day, as well as in a time scale that has none of
the complications of the unpredictable UTC implementation we have
today. So you can't just 'pick one' because real-world systems need
to use different ones for different things, and they also need to
translates events from one timescale to events in the other
timescale.

Let me give you a concrete example. Let us say we are measuring a
number of atomic clocks against one another. We get the measurements
and those measurements are in a monotonic timescale that is defined as
PPS's from some epoch (or number of 5MHz or 10MHz ticks from some
arbitrary epoch). We get data from GPS, which has a similar
timescale. We compute the clock states and deside that we need to
steer one of the clocks. These algoritmns are very much elapsed time
sorts of deals. So we schedule a time to steer it, and then note the
time when we are done steering it. Since we cannot easily get the GPS
or timer times without interfereing with the operations of those
subsystems (maybe because the steering system and GPS system are on
dufferent cpus), we get the system time when the steer starts and when
the clock tells us the steer is complete (since a steer isn't an
instantaneous event). Since this system also is an ntpd server, that
system time is in UTC. Now we have to convert UTC into the internal
timescale so that the algorithms know when the steer happened and can
take that into account for their next round of measurments and
decision making.

To make this all work out well, one has to have perfect leap second
knowledge and all the special case code you have for dealing with the
arrhythmia of a leap second has to work perfectly. Anything that can
be dobe to make things more perdictable helps out quite a bit...

Warner
Received on Sun Dec 31 2006 - 18:40:24 PST