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