Simon Burge <simonb@netbsd.org> writes:
> > 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.

Right.  i think that's my point "1".  8-)


> > 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.

FWIW, unless i'm mistaken, mono_time is _not_ linear, just
monotonic...



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.