Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Markus Kuhn writes: A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
Poul-Henning Kamp wrote on 2006-01-19 09:46 UTC: http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. Just for the record, am I right in assuming that your point is already fully addressed in the UTC-SLS FAQ at http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/#faqcrit ? Anticipating your objection, I wrote there: All other objections to UTC-SLS that I heard were not directed against its specific design choices, but against the (very well established) practice of using UTC at all in the applications that this proposal targets: * Some people argue that operating system interfaces, such as the POSIX seconds since the epoch scale used in time_t APIs, should be changed from being an encoding of UTC to being an encoding of the leap-second free TAI timescale. * Some people want to go even further and abandon UTC and leap seconds entirely, detach all civilian time zones from the rotation of Earth, and redefine them purely based on atomic time. While these people are usually happy to agree that UTC-SLS is a sensible engineering solution *as long as UTC remains the main time basis of distributed computing*, they argue that this is just a workaround that will be obsolete once their grand vision of giving up UTC entirely has become true, and that it is therefore just an unwelcome distraction from their ultimate goal. I do not believe that UTC in its present form is going to disappear any time soon. Therefore, it makes perfect sense to me to agree on a well-chosen guideline for how to use UTC in a practical and safe way in selected applications. This issue has been discussed dozens of times here and we all know were we stand by now. If that is not it, then I can only guess that you did not understand the scope of this specification: Rubberseconds were given up in 1972 for UTC pulse-per-second time-codes, like the ones many time-code radio stations send out. I think everyone still agrees (me certainly!) that they are not practical there for exactly the reasons explained in the above Internet Draft. I do *not* propose to change the definition of UTC in ITU-R TF.460 in any way here. This proposal is primarily about operating system APIs, where rubber seconds have been in use by serious timekeeping people at least since 4.3BSD introduced the adjtime() system call. Up to 500 ppm rubber seconds are used today by many NTP servers to resynchronize the kernel clock, Microsoft's Windows XP NTP implementation is slightly less cautious and uses rubber seconds with up to +/- 400 ppm for resynchronizing its kernel clock. In fact, if you look at *any* form of PLL (circuit or software), then you will find that its very purpose is to implement rubber seconds, that is to implement phase adjustments via low-pass filtered temporary changes in frequency. People have been using PLL rubber seconds in operating systems for quite a long time now, and this practice is still widely considered the state-of-the-art way of implementing a UTC-synchronized clock. All that was missing so far is a commonly agreed standard on what exactly such a PLL-rubber-second clock should do near a leap second, such that all PLL clocks in a distributed system can perform the rubber leap second in *exactly* the same way. The above proposal is *not* about redefining UTC in any way. It is merely a guideline for *interpreting* UTC in Internet Protocols, operating system APIs, and similar applications. Its aim is to eliminate the hazards of some of the currently implemented far more dangerous alternative ways of interpreting UTC in such environments [e.g. those listed as options 1a) to 1i) in Appendix A]. Some of these alternatives have caused quite some off behaviour on 1 January in NTP-synced equipment. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Internet-Draft on UTC-SLS
Markus Kuhn wrote: A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt Accepting that UTC-SLS is not the right choice for some applications and that operating system APIs should be very clear on what timescales are being served up in different cases, I think UTC-SLS is a valuable contribution and a good choice for the default timescale for quite a lot of systems. In particular, it would be a good substitute in current APIs which claim to return UTC but actually don't handle leap seconds. Appendix A argues against putting the adjustment interval after the leap second (method 4a) by pointing out that some time signals contain announcements of the leap second before it happens but not after. I think a stronger argument against this method of adjustment is that during positive leap seconds UTC and UTC-SLS would be indicating different dates: UTC UTC-SLS(A.4a) 2005-12-31 23:59:58 2005-12-31 23:59:58 2005-12-31 23:59:59 2005-12-31 23:59:59 2005-12-31 23:59:60 2006-01-01 00:00:00 2006-01-01 00:00:00 2006-01-01 00:00:00.999 2006-01-01 00:00:01 2006-01-01 00:00:01.998 (Exact fractional times depending on whether the correction interval starts at the start or the end of the leap second). This is a pity, in my opinion, because I think it would be nice to leave open at least the option of implementing UTC-SLS as simply steer your clock towards UTC at the rate of 1ms per second though I understand that that wouldn't be the right choice in many cases. Ed.
Re: Internet-Draft on UTC-SLS
The biggest objection that I have to it is that NTP servers will be at least .5s off, which is far outside the normal range that NTP likes to operate. Unless the prceice interval is defined, you'll wind up with the stratum 1 servers putting out different times, which ntpd doesn't react well to. ntpd runs at a 1024s interval, typically. Depending on when the leap second is announced, and when it polls, ntpd would see a 1s step (since the rubber seconds happen over 1000s). It wouldn't believe it (since it has popcorn outlier rejection). It would then believe the step after 2048s, but since the step is so large, it would just exit (depending on the flags given to ntpd). This will lead to *MORE* clock skew, not less. I'm also concerned about the fact that many radio time codes do not announce the leap second pending until the last hour or less. This makes it hard to propigate out to the non-stratum 1 servers. It is a horrible idea. It is a horrible kludge and I'm not mollified by the weak justifications that are given in the faqcrit. My concerns are real and valid and this will cause more problems than it kludges over. It is a terrible idea. Warner
Re: Internet-Draft on UTC-SLS
How delightful! A discussion about the design merits of actual competing technical proposals! One indication that the discussion is maturing is that someone with strong opinions on one extreme of the issues can find aspects to agree with and disagree with in each of the prior messages. I'll even refrain from taking umbrage over the comment about serious timekeeping people :-) Markus Kuhn says: if you look at *any* form of PLL (circuit or software), then you will find that its very purpose is to implement rubber seconds, that is to implement phase adjustments via low-pass filtered temporary changes in frequency. An excellent observation. Almost by definition, a real world clock is meant to be compared, and perhaps adjusted, to the time kept by other clocks. This is certainly true of NTP. Ed Davies says: Appendix A argues against putting the adjustment interval after the leap second (method 4a) by pointing out that some time signals contain announcements of the leap second before it happens but not after. Right, but we should separate the trigger of a timekeeping event from its implementation. There are any number of ways - starting with a simple semaphore - to arrange for the clock adjustment associated with a leap second to occur at any arbitrary point (or range, as with UTC-SLS) after the trigger. I think a stronger argument against this method of adjustment is that during positive leap seconds UTC and UTC-SLS would be indicating different dates: This may be a fact - it does not itself constitute an argument. An argument would have to answer the question: So what? A date+time expression (such as ISO 8601) forms one atomic unit. The precise issue we have been debating over the last half dozen years amounts to that one cannot separate the date (units of days) from the time (units of seconds) in a self-consistent fashion. Look at it another way. We're dealing with issues of signal processing. An allied field is image processing, and several folks on this list have extensive experience with image processing algorithms and standards. A key issue in building any image processing application is to settle on a consistent point of view of how the coordinates overlay the pixel grid. (Some might have it the other way.) For instance, is the origin at the center of a pixel, or at the lower left hand corner, or at the ULHC or what? Consider (just as an analogy - nobody bust a gut) a particular second of time as a pixel - a day as a one dimensional image vector 86400 pixels long. Does the day start at the beginning of a second, or at its middle, or at its end? I'm not posing this as some deeply philosophical question - in practice the question is already answered, of course. Or is it - in the case of a leap second? It is entirely up to us to define (in a coherent fashion) our point of view about whether the single day containing a leap second is 86401 seconds long, or rather whether each of the two days bracketing a leap second are 86400.5 seconds long. A bit of a mess? Yes. But there are only two ways to resolve the conflicting definitions of the day and of the SI second when implementing systems - reset one of the clocks with a quasi-periodic schedule - or - introduce rubber seconds. And really, aren't these just different sides of the same coin? My objection is that you invent a new kind of seconds with new durations instead of sticking with the SI second that we know and love. Perhaps we can all stop anthropomorphizing? There isn't much to love about any units - SI, or otherwise. And another way to look at this discussion is exactly as an exploration of the boundaries of our ignorance regarding timekeeping. Having a definition of the SI second is not the same as knowing it. 1000 seconds is an incredible silly chosen number in an operational context. At the very least make it 15, 30 or 60 minutes. I would tend to agree with this. The Babylonians must have their kilogram of flesh. How about 10 minutes - 5 before midnight and 5 after? But mostly I object to it being a kludge rather than a solution. Um - a kludge is a type of solution - it is subclassed. There are certainly good solutions and bad solutions, but simply changing our terms doesn't add anything to the discussion. I would far rather we tried to define a time API for POSIX to adopt that makes sense. By make sense I mean: o conforms to relevant international standards ie: recognizes the defininition of leap seconds since for all purposes and intents we're probably stuck with the blasted things for another 20 years. Bless you, my son. o is workable from a computer architecture point of view o Caters to the needs of relevant user communities. By all means! Here's a strawman: Use a 128 bit signed integer. Assign the top 120 bits as one integer field with resolution of 1/2^56 seconds. Assign the bottom 8
Re: Internet-Draft on UTC-SLS
On Jan 19, 2006, at 10:02 AM, Rob Seaman wrote: How delightful! A discussion about the design merits of actual competing technical proposals! Apologies for failing to credit the quotes from Poul-Henning Kamp.
Re: Internet-Draft on UTC-SLS
Poul-Henning Kamp wrote on 2006-01-19 11:59 UTC: My objection is that you invent a new kind of seconds with new durations instead of sticking with the SI second that we know and love. Furthermore, you significantly loosen the precision specs set forth in the NTP protocol. Having just observed Linux kernel crashes caused by a rubber second that was -1 (!) SI seconds long last New Year's eve, I believe you overestimate quite a bit what the precision specs set forth in the NTP protocol count out there in the real world today. I hope you appreciate that the brutal way in which some systems implement leap seconds currently is *far* worse in any respect than UTC-SLS ever could be. If your NTP server - halts the kernel clock for 1 second, or - steps it back by 1 second at midnight, or - starts to oscillate wildly and finally loses synchronization and resets everything after 17 minutes (all these behaviours have been observed, see ongoing NANOG or comp.protocols.time.ntp discussions) then *this* is the worst-case scenario that your entire NTP-synched system must be prepared for. UTC-SLS is infinitely more harmless than a negative step in time. And rather than have one focused moment where things can go wrong, you have now streched that out over 1000 seconds. 1000 seconds is an incredible silly chosen number in an operational context. At the very least make it 15, 30 or 60 minutes. Your choice of words occasionally leaves signs of diplomatic skill to be desired. Anyway, to repeat what Appendix A of the spec says in more detail: I did play with this idea and discarded it, because having prime factors other than 2 or 5 in the smoothing-interval length I leads to unpleasant numbers when you explain the conversion between UTC and UTC-SLS by example. For instance, if we used I = 15 min = 900 s, then we get UTC = 23:45:00.00 = UTC-SLS = 23:45:00.00 UTC = 23:45:01.00 = UTC-SLS = 23:45:01.00 UTC = 23:45:02.00 = UTC-SLS = 23:45:01.998889 UTC = 23:45:03.00 = UTC-SLS = 23:45:02.997778 ... UTC = 23:59:58.00 = UTC-SLS = 23:59:57.00 UTC = 23:59:59.00 = UTC-SLS = 23:59:58.00 UTC = 23:59:60.00 = UTC-SLS = 23:59:59.00 UTC = 00:00:00.00 = UTC-SLS = 00:00:00.00 I find that having infinite decimal fractions showing up obscures just the real simplicity of the conversion much more. It get's much worse when you do UTC-SLS - UTC conversion examples. That's why I prefer I = 1000 s over I = 900 s or I = 1800 s. Blame the ancient incompatibility between Indo-Arabic and Babylonian number systems if you want. And I do not like I = 60 min simply because a) see above b) this cannot be implemented by DCF77/HBG/etc. receivers, which get only 59 minutes advance warning. c) it could shift by 0.5 seconds deadlines on the full hour in time zones that differ from UTC by an odd multiple of 30 min. But mostly I object to it being a kludge rather than a solution. By pasting over problems the way you propose, you are almost guaranteed to prevent them from ever being resolved a right way. (In this context either of fixing/extending POSIX or killing leap seconds counts as a right way in my book.) So my initial assertion *was* right then after all ... [Outline proposal deleted] Now, please show some backbone and help solve the problem rather than add to the general kludgyness of computers. Been there, done that: http://www.cl.cam.ac.uk/~mgk25/time/c/ About 8 years ago, when I was still young and naive as far as the real world is concerned (you actually remind me a lot of these Sturm und Drang days ...), I tried to convince people of a solution that I believe goes somewhat into the direction of what you now have in mind. I had enormous enthusiasm for comprehensive-kitchensink API approaches that allowed me to write applications that can display 23:59:60. I still agree that the POSIX time and time zone API can be improved substantially. But I no longer think that any effort should be made whatsoever to expose real-world applications to the time value 23:59:60. I believe that UTC-SLS is not a kludge, but is a most sensible and practical solution, *if* we accept the premise that civilian time remains tied to UT1. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Rob Seaman writes: if you look at *any* form of PLL (circuit or software), then you will find that its very purpose is to implement rubber seconds, that is to implement phase adjustments via low-pass filtered temporary changes in frequency. An excellent observation. But missing the point entirely: We use PLL because we want to steer things to be synchronous, not because we see them as a means to implement rubber seconds. 1000 seconds is an incredible silly chosen number in an operational context. At the very least make it 15, 30 or 60 minutes. I would tend to agree with this. The Babylonians must have their kilogram of flesh. How about 10 minutes - 5 before midnight and 5 after? That's far to big a torque: 1. PPM Advantages: Sufficient resolution to represent any likely physical measurement or realizable frequency for the forseeable future (13.8e-18 seconds resolution). Any guess at likely physical measurements is going to fall short for some purposes. For one thing, one might want to represent theoretical values in addition to experimental. That said, you are likely correct for our purposes. Heisenberg, Bohr and Planck has a lesson for you :-) Now, please show some backbone and help solve the problem rather than add to the general kludgyness of computers. Do you find this tone of voice productive when collaborating? :-) You know, I've been in computing for so long that I have become alergic to kludges and quick fixes of all kinds. The worse and the more hackish they are, the more red spots I get. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
M. Warner Losh wrote on 2006-01-19 16:58 UTC: http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt The biggest objection that I have to it is that NTP servers will be at least .5s off, which is far outside the normal range that NTP likes to operate. Unless the prceice interval is defined, you'll wind up with the stratum 1 servers putting out different times, which ntpd doesn't react well to. Please read the proposal carefully (Section 2): UTC-SLS is not intended to be used as a drop-in replacement in specifications that are themselves concerned with the accurate synchronization of clocks and that have already an exactly specified behavior near UTC leap seconds (e.g., NTP [RFC1305], PTP [IEC1588]). What this means is: - NTP still uses UTC on the wire, exactly in the same way in which it does so far, *independent* of whether any of the NTP servers or clients involved supply UTC-SLS to their applications. - NTP implementations (by this I mean the combined user-space and kernel-space segments) should convert NTP timestamps that have been received over the wire through the UTC - UTC-SLS mapping, and steer after that what gettimeofday() provides to users . - NTP implementations should equally also convert any timestamp received from gettimeofday through the UTC-SLS - UTC mapping before it goes out the wire. In other words, *no* incompatible changes are made to the NTP protocol. In a correct UTC-SLS implementation, you should *not* be able to distinguish remotely, whether some NTP server synchronizes its kernel clock to UTC or UTC-SLS, because this must not influence its NTP interface in any way. I hope this answers your concerns. [Pretty much the same applies not only for NTP, but also for PTP and other timecodes.] I'm also concerned about the fact that many radio time codes do not announce the leap second pending until the last hour or less. This makes it hard to propigate out to the non-stratum 1 servers. I fully agree that leap seconds should be announced as early as possible, and I think that anything less than a month is undesireable. GPS sends out announcements within days after IERS does, which is excellent service. NIST sends out announcements a month in advance on their WW* stations, which is also pretty good. DCF77/HBG sadly do so only 59 minutes in advance, which is not ideal, but still useful. However, MSF has no leap warning at all, nor do some time codes used in the power or military industry. And recent extensions to the latter added only a leap second warning that arrives a few seconds before the leap. I consider the leap-second handling of these latter time codes pretty useless. It is a horrible idea. Since you seem to have arrived at this initial conclusion based on a misunderstanding of the intended interaction between NTP and UTC-SLS, I would be interested to hear your view again, after you have appreciated that UTC-SLS *can* be implemented in NTP software easily and robustly in a way that is fully backwards compatible with the existing NTP protocol and infrastructure. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Markus Kuhn writes: Now, please show some backbone and help solve the problem rather than add to the general kludgyness of computers. Been there, done that: http://www.cl.cam.ac.uk/~mgk25/time/c/ I remember looking at your proposal before and it suffers from a lot of problems. For instance it is pseudo-decimal while all contemporary computers are binary. This costs a fortune in performance and creates more coding mistakes than you can count. It doesn't have enough resolution for any of the people involved in serious timekeeping (NIST, BIPM, Timing.com etc) It is a two-part representation, which means that you face the silly problem that the C language doesn't give you access to the carry bit, but I guess that is really obscured by the use of pseudo-decimal. It also to some extent confuses representation and presentation which are two very different things. So while well intentioned, you simply didn't go far enough. My proposal tries to lay the groundwork for handling the entire problem way into the future, by extending the range both upwards and downwards and supports multiple timescales with enough room for another 250 accidents of standardization in that area. But I no longer think that any effort should be made whatsoever to expose real-world applications to the time value 23:59:60. That is not for us to decide really. (And my proposal doesn't address it btw, I'm only talking about the representation, not the presentation.) If the leap-seconds are here to stay, and unless heavy duty political power is brought to the issue by USA, that seems to be the case, we will have to get used to 23:59:60. And unless we handle it correctly, we will not be able to certify POSIX systems in a lot of critical applications in the future. Provided we define a convenient and sensible API for handling date time, 23:59:60 will not give people any more problems than any other time of the day, because it will be entirely handled by the library functions for timedate conversions. Poul-Henning PS: And this should not in any way be taken as a surrender on my part, I still think leapseconds are wrong in every way one can imagine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], Tim Shepard writes: The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. As I learned from a recent posting to this mailing list, it seems that even TAI has rubber seconds (adjustments to the rate is made from time to time to compensate for errors that have been accumulating, making TAI a better (more useful) approximation time). Do you object to those adjustments (rubber seconds) to TAI as well? As long as the corrections are of the small magnitudes we have seen (10e-12 and below) and as long as they are applied to both TAI and UTC at the same time, I have no trouble with them. The reason I say 10e-12 is that only high end cesium and hydrogen units are affected by that in practice, everybody else can just ignore it. Remember, we can also risk other fundamental units needing an adjustment, the kilogram being in the high risk bracket here. This draft bugs me a bit because it changes the length of a second (as seen by its clients) by a rather large amount (a thousand ppm). A change in rate of ten ppm could accomplish the phase change with less than 1 day's warning before the UTC leap second insertion if accomplishing it could be split between the 50,000 seconds before UTC midnight and the 50,000 seconds after UTC midnight. But the half second delta to UTC is also a non-starter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Internet-Draft on UTC-SLS
Tim Shepard wrote on 2006-01-19 20:29 UTC: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt This draft bugs me a bit because it changes the length of a second (as seen by its clients) by a rather large amount (a thousand ppm). If you can give me specific examples (and references) for applications that fail with 1000 ppm short-term frequency error (only 1000 ms cumulative phase error), but would work fine with 10 ppm (or 100 ppm) rubber seconds, I would be most interested! I have found the limit 500 ppm required in a number of hardware specifications, but never with any rationale for where this number originally comes from. One recent example is Intel's IA-PC HPET, October 2004, Table 1 (note, this is a hardware spec, not a software API), the maximum frequency error of Intels new PC High Precition Event Timer. A rule of thumb is that you get 20 ppm from a reasonable crystal and 200 ppm error from a really bad, but still commonly available one. So I always understood the MPEG2 limit of 30 ppm as a requirement for manufacturers to simply not pick the very cheapest crystals that they can get on the market, whereas a spec of 500 ppm allows manufacturers to do exactly that. A change in rate of one ppm would not bother me, but that would take a bit more than 11.5 days to accomplish the change. Well, it is always a trade-off between frequency offset and duration of the correction. I don't know any better methodology than trying to list all application constraints that I can think of and then simply get used to one particular pair of numbers that sits sensibly between all these constraints. See Appendix A for what I ended up with so far. A change in rate of ten ppm could accomplish the phase change with less than 1 day's warning before the UTC leap second insertion if accomplishing it could be split between the 50,000 seconds before UTC midnight and the 50,000 seconds after UTC midnight. Do you really like the idea of shifting midnight, the start of the new date, by 500 ms, compared to UTC? I know, in the U.S., midnight is not a commonly used deadline, because the U.S. 12-h a.m./p.m. time notation has no unambiguous representation for the difference between 00:00, 12:00, and 24:00. But elsewhere, it is a fairly standard deadline, and it would seem elegant to me to have at least that exactly identical in both UTC and UTC-SLS, in the interest of all the real-time stock-market and ebay traders out there and their increasing abuse of high-precision legal time. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Internet-Draft on UTC-SLS
In message: [EMAIL PROTECTED] Markus Kuhn [EMAIL PROTECTED] writes: : M. Warner Losh wrote on 2006-01-19 19:20 UTC: : : In other words, *no* incompatible changes are made to the NTP protocol. : : In a correct UTC-SLS implementation, you should *not* be able to : : distinguish remotely, whether some NTP server synchronizes its kernel : : clock to UTC or UTC-SLS, because this must not influence its NTP : : interface in any way. : : In the systems that I observed over the leap second, I can say that : those systems that did implement a UTC-SLS-like approach to steering : out the extra second were definitely observable while they did this. : : Yes, of course! If you connect a GPS receiver that delivers an : undocumented UTC-SLS-alike timescale on its output to an NTP server that : in turn knows nothing of this UTC-SLS-alike timescale and is not : implemented accordingly, you must get a mess. What did you expect? What : you observed is *not* an implementation of UTC-SLS, but just a : connection of incompatible components! No. You misunderstand me. There were no GPS receivers that did UTC-SLS-alike timestamps. This was what CLIENTS of the GPS receiver did. The GPS receiver did exactly the right thing, ntp did the right thing, our products did the right thing. What I observed was in the CLIENTS how they dealt with the leap seconds. GPS-RECEIVER --- GPSNTPD --- NTP CLIENT1[*] windows NT box +-- NTP CLIENT2[*] Linux box +-- NTP CLIENT3[*] FreeBSD box +-- NTP CLIENT4[*] FreeBSD box The items marked with a [*] are the ones I observed. client1 and client2 were the ones that I observed implementing UTC-SLS like time and such time was visible to the outside world. I was clearly able to see both on the GPSNTPD clients 3 and 4 the skews of clients 1 and 2 during the leap second, where I observed no such skews relative to GSPNTPD. I'm saying that certain OSes have implemented the UTC-SLS-like systems. I'm saying that ntp daemons running on those systems use the actual system time for time exchanges, rather than real UTC. I'm saying that this can cause confusion to a downstream ntp client and that's my basis for thinking this idea is not good. I'm further saying that for the OS to support ntpd, it would need to also support UTC and provide an interface to get the raw UTC time. It would need to keep track of steers for the purpose of implementing UTC-SLS and steers needed to compensate for the changing base clock frequency separate so that it could give the right time when asked for UTC time. It would also need to give some kind of feedback to ntpd that it didn't do the small steer it wanted because UTC-SLS is going on at that time (since otherwise ntp would think that there's some frequency step going on if it just ignored it, and doing both steers concurrently would be very hairy). It is a seductive idea that leaves one with a big hangover in the morning. : : However, MSF has no leap warning at all, nor do some time codes used in : : the power or military industry. And recent extensions to the latter : : added only a leap second warning that arrives a few seconds before the : : leap. I consider the leap-second handling of these latter time codes : : pretty useless. : : IRIG-B (all IRIG?) has no leap second announcement that I could find. : The Irig standard I could find (IRIG STANDARD 200-04, issued September : 2004, at http://www.jcte.jcs.mil/RCC/PUBS/pubs.htm) makes no mention : of the format of the leap seconds at all (the leap second convention : appendix says that leap seconds happen). Talking to engineers here : who have implemented IRIG at various places reveals that there are : multiple conventions for dealing with leap seconds in irig (the new : standard being to do 59, 60, the old standard was to do 59 59). : There's no provision for leap second announcement, although control : bits do remain unassigned... : : The IRIG world is clearly a huge mess, with more than two dozen : formats in use. A useful beginner's overview is at : : http://www.symmttm.com/pdf/Gps/an_Time_and_Time_Code_Ref.pdf Excuse me, but isn't it a bit patronizing to point someone at a beginner's guide? I don't need beginner's overviews. I have plenty. I've been dealing with Irig for several years now, as well as many other time codes and timing issues (including leap seconds). What I need is references to standards and copies of standards. I want to understand all the variations of IRIG so I know what the sales/marketing folk are talking about when they ask me if thus and such standard is easy or hard. : which outlines on page 23 the 27-bit IEEE 1355 power-industry extension : to IRG-B that has a Leap Second Pending (LSP) bit that becomes 1 up to : 59 sec before leap second insertion. That was the one I referred to. If : you have a good and very reliable signal, it may be just good enough to : insert 23:59:60
Re: Internet-Draft on UTC-SLS
In message: [EMAIL PROTECTED] Markus Kuhn [EMAIL PROTECTED] writes: : M. Warner Losh wrote on 2006-01-19 19:20 UTC: : Effectively, you'd have to have two time scales in the kernel. UTC : and UTC-SLS. You make it sound simple, but the hair in doing this may : be quite difficult. There's more book for the kernel to keep, and it : would have to expose the bookkeeping to userland for ntp to work. : What makes this hard is that ntpd may introduce steers into the normal : system time at normal times which it doesn't want to confuse with the : steers in frequency that are used during a UTC-SLS operation. : : You correctly point out some of the design considerations that have to : go into such code. You describe roughly one of the (several) different : ways of implementing all this that I have in mind. In comparison to how : complicated the Mills kernel PLL is already today, that does not : actually sound like an overwhelming additional complexity. Actually, it : sounds quite doable when you think through it a bit. Not trivial, but : carefully doable without performance penalty. Anything that makes the Mills' kernel PLL more complicated is unlikely to be implemented correctly. There have been several subtle bugs in Mills' implementation that have taken a long time to sort out. In fact, members of this list have found some of them and have a lot of experience with Mills' kernel PLL. Many people in the timing community are unhappy with Mills' implementation. They believe it to be way too complex and have been trying to implement a much simpler implementation that gives more control to the measurement process to apportion the errors that it measures by doing simpler steers. It moves the kernel time control in the wrong direction. : The important thing is: All this has to be done only *once* for each : operating system and *once* for each each NTP client/server used on it, : by someone who understands the issue, and then the problem is hopefully : solved. We've handled far more complicated things in OS kernels, right? No. It has to be done continuously. By that I mean that you can clearly write an implementation once, but over time you will find flaws with that implementation (I can 100% guarnatee that). As you find the flaws, you'll have to investigate them and fix them. In addition, other parts of the kernel change, and some of those changes, though innocent looking, can have a big impact on how you implemented the dual UTC UTC-SLS offset. By way of illustration, in FreeBSD 2.2, the timing implementation was changed from keeping the current time, to keeping an uptime plus a boot time. Adjustments to the boot time were used to accomplish phase shifts in the system time. Unbeknownst to the person implementing this, despite him having integrated the Mills kernel NTP portion into a prior version of FreeBSD, this broke the exact semantics of system time around the leap second. It took years for someone (me) to notice and fix this problem. : I also fully appreciate that the existing *interface* between : kernel-level clock drivers and user-level NTP clients and servers is by : far not as well specified as it could be. With all due respect to its : author, I do not hope that RFC 1589 will not remain the last word on : clock-driver interfaces. A detailed proposal for a new standard on that : area should help to smooth the process of getting the above right. I : think a serious clock-controlling API this is what some people have been : asking for for a long time from POSIX. In order to implement your UTC-SLS proposal, it must change. : I believe it is good engineering practice to specify the functionality : before the interface and implementation, therefore I would like to : discuss aspects of desired functionality (including UTC-SLS) before : starting to work on a proposed successor to adjtimex(), ntp_adjtime(), : etc. While I agree in principle, I can tell you as one who has bloodied his knuckles on implementing timekeeping that what you are saying sounds hard to get pedantically right. : I am not claiming that the spec-writing job is finished, or even half : finished yet. I see a replacement for RFC 1589 etc. as the next job on : the agenda before UTC-SLS (and lots of other time API ideas floating : around here and elsewhere) can start to fly. Unfortunately, it makes it hard to evaluate your proposal in the absense of a concrete spec. What is there now sounds nice, but it still strikes me as difficult to implement. Warner
Re: Internet-Draft on UTC-SLS
Ed Davies: Appendix A argues against putting the adjustment interval after the leap second (method 4a) by pointing out that some time signals contain announcements of the leap second before it happens but not after. Rob Seaman: Right, ... Ed Davies: I think a stronger argument against this method of adjustment is that during positive leap seconds UTC and UTC-SLS would be indicating different dates: Rob Seaman: This may be a fact - it does not itself constitute an argument. An argument would have to answer the question: So what? You're right - I left the denouement implicit. With this method (4a) UTC-SLS would not have the property listed in section 3: the time always equals UTC at full or half hours. I think this is a valuable property; as the text following the 4a), 4b) and 4c) options notes: ...would be reached at midnight, which is a time commonly used to schedule events and deadlines. I hope that makes sense. Ed.
Re: Internet-Draft on UTC-SLS
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] Markus Kuhn [EMAIL PROTECTED] writes: : M. Warner Losh wrote on 2006-01-19 19:20 UTC: : Effectively, you'd have to have two time scales in the kernel. UTC : and UTC-SLS. You make it sound simple, but the hair in doing this may : be quite difficult. There's more book for the kernel to keep, and it : would have to expose the bookkeeping to userland for ntp to work. : What makes this hard is that ntpd may introduce steers into the normal : system time at normal times which it doesn't want to confuse with the : steers in frequency that are used during a UTC-SLS operation. : : You correctly point out some of the design considerations that have to : go into such code. You describe roughly one of the (several) different : ways of implementing all this that I have in mind. In comparison to how : complicated the Mills kernel PLL is already today, that does not : actually sound like an overwhelming additional complexity. Actually, it : sounds quite doable when you think through it a bit. Not trivial, but : carefully doable without performance penalty. Anything that makes the Mills' kernel PLL more complicated is unlikely to be implemented correctly. Actually the Mills PLL isn't implemented correctly in the first place, The fact that the design is pretty baroque doesn't help. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Internet-Draft on UTC-SLS
A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt Background information, FAQ, etc.: http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ Abstract: Coordinated Universal Time (UTC) is the international standard timescale used in many Internet protocols. UTC features occasional single-second adjustments, known as leap seconds. These happen at the end of announced UTC days, in the form of either an extra second 23:59:60 or a missing second 23:59:59. Both events need special consideration in UTC-synchronized systems that represent time as a scalar value. This specification defines UTC-SLS, a minor variation of UTC that lacks leap seconds. Instead, UTC-SLS performs an equivalent smooth adjustment, during which the rate of the clock temporarily changes by 0.1% for 1000 seconds. UTC-SLS is a drop-in replacement for UTC. UTC-SLS can be generated from the same information as UTC. It can be used with any specification that refers to UTC but lacks provisions for leap seconds. UTC-SLS provides a robust and interoperable way for networked UTC- synchronized clocks to handle leap seconds. By providing UTC-SLS instead of UTC to applications, operating systems can free most application and protocol designers from any need to even know about UTC leap seconds. Please have a careful look at the full specification and rationale. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
