Subject: Re: monotonic time (was Re: CVS commit: basesrc)
To: Chris G. Demetriou <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 08/25/1999 12:40:51
Chris G. Demetriou wrote:
> Simon Burge <email@example.com> 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
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.