In message <E1E11sG-0006BQ-00_at_mta1.cl.cam.ac.uk>, Markus Kuhn writes:
>Poul-Henning Kamp wrote on 2005-08-05 12:17 UTC:
>> Also, your UTS proposal is a total non-starter: Rubber seconds is not
>> a usable solution.
>
>I beg to differ strongly, and I slightly suspect you live a bit in a
>dream world with regard to the short-term accuracy that is practical on
>most computers (other than dedicated hard-realtime systems):
Markus, sorry, but I think I know more about that than you do.
I have been writing operating systems and control systems for 25
years, and measured more weird timing stuff than you imagine over
the years.
>On paging, preemptive, multi-tasking operating systems that run on
>caching CPUs with branch prediction logic, which is what the POSIX
>standard addresses (so-called "soft real-time applications"), any form
>of second that you can measure is already in practice very noisy and
>rubbery.
Typically the noise is about three orders of magnitude less than
what your proposal would introduce.
And who said anything about the time being used only from userland
in the first place ?
What about protocols with timestamps in them ? (not just NTP, but
also telco protocols, radius etc.)
And far too many places it is just not acceptable to have a slice
of time where time interval measurements are systematically 1e-3
wrong.
>You may find it a quite challenging exercise to write a POSIX
>application that can somehow detect, on its own, that a UTS leap second
>is in progress, especially if all its peers also use UTS to answer the
>gettimeofday() API call.
I have a posix application that operates with time at the 1e-9 level,
and it would not only find out, it would freak out a lot of people.
>Remember that the frequency error that UTS introduces was carefully
>chosen to be
>
> - within a single order of magnitude of the frequency error of the
> crystal oscillators commonly used in office and server equipment
UTS introduces approx two orders of magnitude more instability than
a cheap computer right in front of the A/C unit would otherwise
have (1 PPM/C).
>You really need a dedicated experimental setup to find out that a UTS
>leap second is in progress if you have no other reference clock.
If we are talking about "trivial home computers", then UTS doesn't bring
any advantage over a second step.
If we talk about anything in the real world, UTS is just a no-go. Seconds
have a very well defined length, and that is it.
Read my lips: No rubber seconds.
>On the other hand, the traditional NTP kernel driver behaviour, which
>brutally subtracts 1 s from the time_t clock at the start of an inserted
>leap second (and sets an obscure LEAP flag in an obscure adjtimex()
>system call), is trivial to detect. It even breaks monotonicity.
Yes, it is about as bad as UTS, but bad in different ways. It cannot
be fixed as long as we stick with the POSIX_MISTAKE and still have
leap seconds.
If leapseconds continue, no matter what the rate, the UNIX crowd needs
to get their act together.
If we get a decent horizon for leap seconds, the best idea would
be to declare that time_t includes leapseconds from 2007-01-01
00:00:00 and just take it from there.
We can't do anything for the previous leapseconds, old timestamps
are ambiguous and that is all there is to it.
We could leapsecond correct time_t subtractions pre 2007, but it
would need compiler support to turn arithmetic subtractions into a
function call which could look up the leap-seconds, and it would
probably break more than it would fix, so I'd advise against it.
The Microsoft crowd also has the same problem to fix.
>It is merely the current, unfortunately chosen, NTP-driver way of
>representing UTC leap seconds on a POSIX API that causes the concerns
>that you and others express about leap seconds in this context.
No, Markus, it is not.
It is the concern that whenever I plug a cable in, I never know if
(and in the few cases where that comes out true: how) the equipment
in the other end handles leapseconds.
> http://www.cl.cam.ac.uk/~mgk25/uts.txt
>
>for a more detailed rationale.
I've seen it and read it (several times) and I'm firmly against it.
It does not solve any problems without introducing new ones that
are often even bigger.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Fri Aug 05 2005 - 06:29:31 PDT