Re: Comparing Time Scales
In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : In message: [EMAIL PROTECTED] : James Maynard [EMAIL PROTECTED] writes: : : M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : : James Maynard [EMAIL PROTECTED] 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.
Re: Comparing Time Scales
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. But there's a difference between NTP timestamps, and the details of the implementation of a system which uses NTP for synchronization. The NTP timestamps have more than 64-bits in them when you include the leap warning bits. NTP timestamps do not repeat any seconds when a leap second occurs. Note that in Figure 8 in RFC-1305 the sequence of NTP timestamps are: 2,871,590,399 + 2,871,590,400 + 2,871,590,400 2,871,590,401 The plus represents the leap warning bits indicating an upcoming (or in-progress) leap second insertion. There are four distinct seconds, each with its own unique timestamp. I'll extend this to include half seconds, just to be very clear: 2,871,590,398.5 + 2,871,590,399.0 + 2,871,590,399.5 + 2,871,590,400.0 + 2,871,590,400.5 + 2,871,590,400.0 2,871,590,400.5 2,871,590,401.0 When the leap warning bits are included, each point in time has a unique time stamp (to the resoultion of the NTP timestamp, which is better than a nanosecond with all 32 bits of fraction). A computer system could represent UTC time in a way which also makes this clear, for example by a structure or abstract data type which includes in it (1) the day number and (2) how-many nanoseconds are we into this day. When executing a leap second insertion, we would get all the way up to 86,400,999,999,999 nano seconds in the day before we wrapped around that field to zero and incremented the day number (one nanosecond later). -Tim Shepard [EMAIL PROTECTED]
Re: Comparing Time Scales
In message: [EMAIL PROTECTED] Tim Shepard [EMAIL PROTECTED] writes: : But there's a difference between NTP timestamps, and the details of : the implementation of a system which uses NTP for synchronization. Ah, I was getting the two confused and didn't quite realize it until your clarification. Thanks! Warner
Re: Comparing Time Scales
So internally, once we hit the leap second time, we step backwards. Lovely waxing crescent moon last night. I could see it out of the north facing windows of our family room. It might be simpler in some sense to pretend that the moon (and the sun for that matter) always rises due east and set due west, but there it was, shining in the window because its declination last night happened to lie above the equator. Whatever time does, it does not step backwards. It may be simpler - in some sense - to build a clock or software interface that accommodates the lunar correction to the solar day by stepping backwards more or less contemporaneously with a leap second, but when you get down to it, this is - well - a naive kludge. If you freeze time, then doing a time exchange during a leap second is going to give bogus results. Time neither freezes... If you step it back, then it will give good results, but there are other bad effects. ...nor steps back during a leap second. Just like the 29th of February, a leap second is an extra unit of time that is interpolated into the grand eternal sweep of history and causality. Why not design our computers, clocks and communications technology to implement that simple fact - just like our calendars and palm pilots recognize the fact of an extra day in February every four years? Hey gang! Let's put on a Gedankenexperimenten! Imagine we are faced with the prospect of a quadratically accelerating sequence of negative, rather than positive, leap seconds. (We'll ignore the trifling anthropic dilemma of the moon looming ever closer in our sky.) Two questions to ponder: How would we implement these? And would the ITU feel more driven - or rather less - to modify UTC as a result? To address the first question, we can start with the statutory requirement from ITU 460-4: 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month As we can see from the current discussion, system designers don't necessarily even try to implement statutory requirements. Notions about freezing time or of stepping it back arise - it seems to me - out of balking at the clear and explicit requirements of the task at hand. But in the case of a negative leap second, there would be no additional wrinkle in time to iron out or to double over - just the simple need to omit a second from the count. If we were merely faced with omitting a second every year or two, would the requirement really seem particularly onerous from the point of Posix or NTP or our other technology? Would GLONASS have noticed the event even at the minimal level seen this New Year? What is it about a 61s minute that is deemed more herculean than a 59s minute? We manage to deal with months containing 28, 29, 30, and 31 days. The great majority of months (4497/4800) aren't even denumerable with the length of our week. Why then is a requirement that one minute out of 800,000 accommodate one extra (or one fewer) second seen to be such an imposition? Especially when anybody who does find it so can simply choose to use TAI instead? Eppur si muove! Rob Seaman NOAO
Re: Comparing Time Scales
Warner Losh wrote: From: James Maynard [EMAIL PROTECTED] Subject: Re: [LEAPSECS]Comparing Time Scales Date: Fri, 03 Feb 2006 15:37:40 -0800 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 If you read different documents carefully, you'll see this sequence: UTC = 2005-12-31 23:59:60.0, NTP seconds = 3 345 062 400.0, LS_pending = 01 UTC = 2005-12-31 23:59:60.5, NTP seconds = 3 345 062 399.5, LS_pending = 01 UTC = 2006-01-01 00:00:00.0, NTP seconds = 3 345 062 400.0, LS_pending = 00 Where the 399 second repeats. The documents say that just after time is incremented to 400, the last second of the day is repeated Warner This looks like something that needs to be resolved in a standards committee, such as David Mills' working group on Version 4 of the NTP protocol. Meanwhile, you have to cope with different implementations that do it different ways! If a device has leap second information available to it at all, it should know at least an hour ahead of time that a positive leap second is pending. Given that information, it should be able to arm itself for the upcoming leap second. Once in armed for leap second state, each NTP server and client would count the one-second epochs in the last 61-second minute of the day, assigning NTP second numbers correctly and displaying (if it has a display) the UTC time correctly. (Of course, I think the method shown in my table should be the standard way of assigning NTP second numbers. But that would be a matter for the standards committee to resolve.) So I *think* my table shows how the leap second *should* be handled on the various time scales listed in the table. There remains the standards effort -- electropolitical engineering -- of reaching agreement on an unambiguous standard to describe how leap seconds should be handled. -- James Maynard Salem, Oregon, USA
Re: Comparing time scales
Here's another iteration on my paper. I corrected several of the dates in the table from my birthday (-12-23) to the end of the year (-12-31). (Was that one of those Freudian slips?) I also tried to close up the columns of the table a little, hoping to make room to add another column for another time scale. But it seems that to do that, I would have to compress the GPS time scale to show only GPS seconds, and not the GPS week number and the second number in the week. (I guess that will be the next step.) -- James Maynard Salem, Oregon, USA Leap Second History.pdf Description: Adobe PDF document
Re: Comparing Time Scales
In message: [EMAIL PROTECTED] James Maynard [EMAIL PROTECTED] 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
Re: Comparing Time Scales
In message: [EMAIL PROTECTED] James Maynard [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : James Maynard [EMAIL PROTECTED] 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
Comparing time scales (second try!)
(Oops, I forgot to attach the attachment!) Thank you, Warner, for your thoughtful reply enumerating the reasons that you are in camp #2. It caused me to research the matter further, so that I could understand your point of view. I purchased a copy of the IEEE 1588 standard and began to study it. Referring to IEEE 1588 (= IEC 61588) and a table on the IERS Web site, I was able to prepare a table summarizing the behaviour of the UTC, TAI, GPS, NTP, and PTP time scales, espeically at times at or near a leap second. I've attached that table as a *.PDF file. Would you be kind enough to review it, to see if I've got it right? -- James Maynard Salem, Oregon, USA Leap Second History.pdf Description: Adobe PDF document
Re: Comparing time scales (second try!)
Thanks, Steve. I'll incorporate your comments in my next draft of this memo to self. (I also note that I didn't correctly incorporate the examples in Table B.2 of Annex B of IEEE 1588.) -- James Maynard Salem, Oregon, USA
Re: Comparing time scales (second try!)
James Maynard wrote: Thanks, Steve. I'll incorporate your comments in my next draft of this memo to self. (I also note that I didn't correctly incorporate the examples in Table B.2 of Annex B of IEEE 1588.) And here's the revised paper. Have I got it right yet? -- James Maynard Salem, Oregon, USA Leap Second History.pdf Description: Adobe PDF document
