Chris G. Demetriou wrote:

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

Yes, it is :-(

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

Bugger, correct. mono_time is bumped after the adjtime() adjustment is
factored in.  mono_time is also a timeval, not a timespec - it should
probably change.  Hmm, I wonder if the ntp4 stuff that Jonathan and Bill
is looking at has anything to say about this...

I just looked on a Solaris box, gethrtime() returns the number of
nanoseconds since boot - it's not related to "real time" in anyway.

Simon.