C9x <time.h> and clock precision

[Markus Kuhn]

Paul Eggert wrote on 1998-10-05 20:44 UTC:
>    Date: Sun, 04 Oct 1998 12:03:49 +0100
>    From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> 
>    You certainly do not measure the position of your radio telescope
>    with 3 cm precision (0.1 ns) by performing time request calls to
>    your C API! You would use external picosecond hardware phase
>    comparators clocked by caesium time normals, which send you the
>    data as ASCII floating point numbers for further processing in your
>    Fortran tools
> 
> It sounds like you're saying that C should not support high-resolution
> timestamps, and that people who need such things should use Fortran instead.

No, of course not. Please use a bit more common sense (this also
addresses some comments made by Dan Bernstein about the need for
attoseconds):

Fortran does not have a higher resolution time API. For scientific
applications, you just use whatever representation of numbers with the
required precision your language offers. For these applications, you
*anyway* must use handwritten inline assembler timing code in order to
access the hardware counter in a strictly deterministic way, taking care
of interrupts, caches, TLBs, pipelines, and all the other real-world
timing hazards that are completely outside the scope of the C standard
and what xtime_get() is intended for!

In DSP applications, you do not even convert to seconds but calculate in
a clock-dependent time scale and just adjust your constants. DSP applications
are also far outside the scope of <time.h>!

If you think that an API that does not provide this low-level control
over timing hazards can be useful for sub-nanoseconds measurements, then
this just indicates that you probably never have tried to use
computers yourself for high-precision timing with a 10 GHz oscilloscope
next to the machine to verify the results. I would never use a
vendor provided compiler library for such applications (and I *have*
spent days debugging C compiler timing functions under MS-DOS with
oscilloscopes for sub-millisecond hard real-time applications).

Of course you can time the position of your radio telescope with
nanometer precision in C. There is no reason why you would want to use
xtime to represent the quantities in the calculations involved in doing
this. You will just use normal floating point variables in whatever time
scale your instruments and your application define. The timing variances
of your processor (cache flushes, TBL reloads, multi-tasking, bus
arbitration, etc.) are at least two orders of magnitude worse than 1 ns,
therefore, you will never want to use anything like xtime_get() itself
as a source of sub-nanosecond timing information. You will always need
special hardware or assembler-level driver design for these things, and if
you think that the Pentium's internal bus cycle counter is suitable for such
applications, then I suggest you try building a GPS software receiver 
(100 ns resolution required) on top of it to see the real-life limits
of software timing.

> Perhaps I'm paraphrasing you incorrectly; still, I am extremely
> uncomfortable with the idea that the C standard should impose an upper
> limit on the quality of the clock.

I am not.

The limit of 1 ns is *much* smaller (at least two orders of magnitude)
than any realistic requirement for this type of a software clock.



We are moving *very* far away from the real problems, towards topics that
are best described as "academic" in the most negative sense of the word.
I hope this does not give some observers the impression that the proposal
does indeed need as much discussion as it does get here.

I am starting to get concerned that I might have wasted a lot of time
while working on this, especially since I didn't get any feedback yet
from the only ISO C committee member on this list.

To rephrase from a Tony Blair speech a few days ago:

  Please keep in mind that you do not have the choice between the xtime
  you have got and the xtime you want. You have the choice between xtime
  and tmx.

:-)

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>