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
Received on Thu Jan 19 2006 - 13:04:12 PST