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
