On Thu, 1 Jul 2004, Simon Burge wrote:

> Frederick Bruckman wrote:
>
>> CLOCK_HIGHRES sounds like the same thing as POSIX' CLOCK_MONOTONIC,
>> which we have.
>
> Note that Solaris' CLOCK_HIGHRES is defined as monotonic and linear
> (as Bill Sommerfeld mentioned - it's not affected by adjtime() et
> al), whereas our CLOCK_MONOTONIC is just monotonic.  It is however
> recommended in SUSv3 that CLOCK_MONOTONIC be linear:
>
>    Additionally, it is desirable (but not required by IEEE Std
>    1003.1-2001) that the monotonic clock increases its value uniformly.

In the man page for clock_settime(), Issue 6, there is added:

     Note that the absolute value of the monotonic clock is
     meaningless (because its origin is arbitrary), and thus
     there is no need to set it...

So I infer the idea is that mono_time should be time since boot, so 
that anyone attempting to use it for ToD improperly will be quickly 
educated. That would be the basis for CLOCK_MONOTONIC.

CLOCK_REALTIME should give no guarantees of monoticity, "of course", 
(with "of course" in quotes, because on NetBSD, it currently uses 
microtime()!).

Is there any use for the old microtime() semantics -- a CLOCK_BSD --, 
or any form of them? What possible code can't tolerate small backwards 
jumps, but can tolerate large ones? Observe that any large backward 
jump will look just like a small backward jump for some specific 
period of time in the future.

Frederick