Re: [LEAPSECS]Comparing Time Scales

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sat, 04 Feb 2006 00:58:01 -0700 (MST)

In message: <20060204.004443.21274680.imp_at_bsdimp.com>
            M. Warner Losh <imp_at_bsdimp.com> writes:
: In message: <43E459C9.4090806_at_usa.net>
: James Maynard <james.h.maynard_at_usa.net> writes:
: : M. Warner Losh wrote:
: : > In message: <43E3E944.80406_at_usa.net>
: : > James Maynard <james.h.maynard_at_usa.net> writes:
: : > : Thanks, guys, for your feedback. Here's another iteration.
: : > :
: : > : The numbering of NTP seconds in the vicinity of a leap second seems to
: : > : differ from one document to another. Here I follow the NTP (version 3)
: : > : specification, RFC 1305, in which the Leap Indicator (sys.leap,
: : > : peer.leap, pkt.leap) is 01 if a positive leap second is to occur at the
: : > : end of the current UTC day, and 00 if no leap second is pending.
: : > :
: : > : UTC = 2005-12-31 23:59:59, NTP seconds = 3 345 062 399, LS_pending = 01
: : > : UTC = 2005-12-31 23:59:60, NTP seconds = 3 345 062 400, LS_pending = 01
: : > : UTC = 2006-01-01 00:00:00, NTP seconds = 3 345 062 400, LS_pending = 00
: : >
: : >
: : >
: : In the NTP time scale, it is the last second of the UTC day, NTP second
: : number 3 124 137 600, that is repeated. The first instance of this NTP
: : second number is the leap second, during which (TAI - UTC) = 31 and the
: : NTP Leap Indicator is 01. The second instance of this NTP second number
: : is the the first second of the new UTC day, during which (TAI - UTC) =
: : 32 and the NTP leap indicator is 00. You can distinguish the leap
: : second (while it is occuring) by the fact that it is the last second of
: : the UTC day (time of UTC day = 23:59:60) and that the NTP Leap Indicator
: : is 01. You can distinguish the first second of the new UTC day by the
: : fact that, of the two seconds with the same NTP second number, it is the
: : one that has the NTP leap indicator set back to 00.
: :
: : Note that according to the write-up to which you referred me, it is
: : NTP second number 3,124,137,600 (not 3,124,137,599) that is repeated.
: : NTP second number 3,124,137,599 is the *next-to-last* second of the day,
: : not the *last* second of the day.)
:
: No. The article specifically says that after it the system time gets
: to ,600, it is decremented by one and there is specific code in the
: code that returns the system time to applications that makes it stand
: still. The second isn't *NOT* repeated. Repeat: The second is *NOT*
: repeated in what they said. Time stands still outside of the kernel,
: while inside the kernel the last second of the day *IS* repeated,
: hence the need for the limiter that the article talks about.
:
: Not all kernels keep time standing nearly still during the leap second
: (since that has other bad effects). Some expose this decrement to the
: users. The highlighed part of what I quoted said exactly this.
:
: I've actually implemented this for FreeBSD. You are arguing theory,
: and I'm arguing the fine points of an actual, real implementation.

More specifically, read the text I highlighted:

: : >>>The obvious question raised by this scenario is what happens during
: : >>>the leap second itself when NTP time stops and the clock remains
: : >>>unchanged. If the precision time kernel modifications have been
: : >>>implemented, the kernel includes a state machine that implements the
: : >>>actions required by the scenario. [[ At the first occurrence of second
                                            ---------------------------------
: : >>>3,124,137,600, the system clock is stepped backward one
       -------------------------------------------------------
: : >>>second.]] However, the routine that actually reads the clock is
       -------
: : >>>constrained never to step backwards, unless the step is significantly
: : >>>larger than one second, which might occur due to explicit operator
: : >>>direction. In this design time stands still during the leap second,
: : >>>but is correct commencing with the next second.

Notice the [[ ]] text. When it becomes 400, the system time is
decremented internally, which is why I wrote the 399.5 example that I
did. Also, the picture on the page shows how time stops/slows way
down during the leap second in Dave Mills' view of how time should be
returned to the user during the leap second. Text I didn't quote says
that the system time must be monotonically increasing, so it is
incremented by 1ns each call.

So internally to the kernel, the time does repeat the last second.
Externally, in a Mills' perfect world, time stands still during the
leap second. The second doesn't repeat, per se, but it freezes for a
second.

In FreeBSD, the actual internal time is exposed to the user. If we
froze time as returned from the system, then threaded applications'
threads would potentially stop during the leap second due to the way
certain timeouts are handled. This is a bigger problem, so we keep
time running by exposing the internal state.

These sorts of details, btw, are why I hate leapseconds. They cause
needless arguments over which part of the system you are talking
about. Really smart people do needlessly stupid things with them,
like making time kinda stand still.

The next generation of ntp appears to use the same time base that PTP
is using, at least form my reading of the links posted here a while
ago, eliminating this problem once and for all.

Warner
Received on Sat Feb 04 2006 - 10:34:46 PST