struct timeval for Sys V Rel 3.0 ?

[Doug Gwyn]

In article <18806 at watmath.waterloo.edu> egisin at watmath.waterloo.edu (Eric Gisin) writes:
>In article <7871 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>> You can't get time like that from a normal UNIX system, even a Berkeley
>> one.  Apart from the uncertainties introduced by time-sharing scheduling,
>> most implementations don't even maintain internal time that accurately.
>> 100Hz clock is typical.  Use time() instead.
>On Vaxen running BSD gettimeofday reads a hardware clock register
>with microsecond accuracy.
>On System V, the best resolution you can get is the long (clock_t)
>value returned by times(2). The resolution is on the order of 10 milliseconds.

The resolution is limited by the available hardware clock (which
may be no better than power line frequency), and may be less than
that if the kernel implementor so chose; there is normally a
round-robin scheduler increment that serves as the effective
resolution of time throughout the OS, except for special access
to finer-grained timers such as provided by Berkeley getitimer()
etc.  The higher theoretical resolution of such a timer on systems
with fast hardware clocks is not available in practice, because of
the basic (coarser) increment used to schedule the return from the
system call.  Ordinary UNIX is not well suited to precise timing
applications.  (Some vendors who target the real-time market have
attempted to improve this for their products.)