C9x <time.h> and clock precision

Paul Eggert eggert at twinsun.com
Wed Oct 7 09:01:24 UTC 1998


   Date: Tue, 06 Oct 1998 15:05:14 +0100
   From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>

   an API that does not provide this low-level control over timing
   hazards can[not] be useful for sub-nanoseconds measurements

I agree, but it seems to me that an implementation should be able to
supply such low-level control, perhaps as implementation-defined
TIME_xxx flags passed to xtime_get.

   you will never want to use anything like xtime_get() itself as a
   source of sub-nanosecond timing information.

I'm not sure that I agree with the ``never'', as clocks will keep
getting better and better, and eventually (I hope within my lifetime
:-) places outside the PTB will break the 1ns barrier.  And I would
like the spec to be modified so that xtime_get(TIME_MONOTONIC) can be
compiled to a single instruction accessing the hardware clock
register directly, which will make sub-ns access more practical.

Also, we must distinguish between the overhead of calling xtime_get(),
and the precision of the result.  For some applications, it's enough
that xtime_get() returns a precise value even if the amount of time
that it takes to invoke xtime_get() is greater than the precision.
All that's needed is that the clock had the reported value at some
time during the invocation of xtime_get().  (Hmm, perhaps the spec
should say something about this?)

   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.

I also hope that your time wasn't wasted, but I don't think that the
C9x is the only avenue for your work to be exploited.  If we can get
this into the GNU C library, for example, a lot of users will have it
available in fairly short order.  This will help convince the ISO C
committee the next time around.



More information about the tz mailing list