Chris G. Demetriou wrote:

> Simon Burge <simonb@telstra.com.au> writes:
> > Is this worth thinking about more, or should I just drop it?
> 
> so, the kernel mono_time variable is supposed to be a
> monotonically-increasing kernel time variable...

Ick, I grepped for "monoton" and thought I'd looked around where "ticks"
was fiddled with, and missed "mono_time" altogether.  It's still
worth noting that there's still no capability for mono_time to have
non-hardclock-multiple values on machines with hi-res timers available,
although I'm not sure of the worth of this at the kernel level.

> however:
> 
> 1) there's no interface similar to microtime() to get a
> high-resolution mono-time (microtime() provides a 'time'-like value,
> i.e. it can go backwards).  I consider this (and the many bogus uses
> of time for timestamps which are related to driver timeouts, and the
> like) to be a bug.

Also on the bug front, it looks like the netiso code uses the value of
ticks without checking for the possibility of wraparound...

> 2) there's no guarantee that if somebody's not going to set the clock
> backward on you and reboot, or something, so you can't really have a
> guarantee that you'll have a monotonically-increasing-across-reboots
> clock.

Although it doesn't explicitly say so, the Solaris gethrtime() manpage
seems to imply that it only valid while the machine is up.  The other
notion that I left out was "linear".  Here's a quote from the manpage:

     Although the units  of  hi-res  time  are  always  the  same
     (nanoseconds),  the actual resolution is hardware dependent.
     Hi-res time is guaranteed to be monotonic (it won't go back-
     ward, it won't periodically wrap) and linear (it won't occa-
     sionally speed up or slow down for adjustment, like the time
     of  day  can),  but not necessarily unique: two sufficiently
     proximate calls may return the same value.

Simon.