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
: >
: >
: >
: >>>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.
: >
: >
: > So internally, once we hit the leap second time, we step backwards.
: > Some systems contrain the values returned from gettimeofday to not
: > notice the step, while others do not. This talks about incrementing
: > the time by 1 unit (usually a nanosecond or microsecond) while time is
: > catching up.
: >
: >
http://www.eecis.udel.edu/~mills/leap.html
: >
: > So it very much depends on if you are looking inside the kernel or
: > outside the kernel for what the correct values are. If you freeze
: > time, then doing a time exchange during a leap second is going to give
: > bogus results. If you step it back, then it will give good results,
: > but there are other bad effects.
: >
: > Basically, no matter what you do, it is broken (unless you tick in TAI
: > time).
: >
: > Warner
: >
: >
: >
: Thank you. You are trying hard to educate me on this matter, and I
: appreciate your efforts.
:
: Following the link you gave me in this message, <>, I found a discussion
: of how the leap second is to be handled in the NTP time scale. That
: discussion includes the following table to illustrate the leap second
: transition of 1998-12-31 23:59:60 UTC:
:
: +-----------+----------+------------+----------+---------------+
: | Date | Time | TAI Offset | NTP Leap | NTP Seconds |
: +-----------+----------+------------+----------+---------------+
: | 31 Dec 98 | 23:59:59 | 31 | 01 | 3,124,137,599 |
: +-----------+----------+------------+----------+---------------+
: | | 23:59:60 | 31 | 01 | 3,124,137,600 |
: +-----------+----------+------------+----------+---------------+
: | 1 Jan 99 | 00:00:00 | 32 | 00 | 3,124,137,600 |
: +-----------+----------+------------+----------+---------------+
: | | 00:00:01 | 32 | 00 | 3,124,137,601 |
: +-----------+----------+------------+----------+---------------+
:
: Funny, that's exactly what I wrote in my last iteration of my table!
:
: 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.
Warner
Received on Fri Feb 03 2006 - 23:50:43 PST