Subject: Re: Avoiding microtime(9) global state
To: Frederick Bruckman <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 07/01/2004 12:14:35
Frederick Bruckman wrote:
> On Wed, 30 Jun 2004, Bill Sommerfeld wrote:
> > > NetBSD should provide both facilities (ToD & interval time), and the
> > > code we write needs to be clear about which it is using and why.
> > indeed. as another example, solaris's clock_gettime(3RT) supports
> > CLOCK_REALTIME (wall clock ToD) and CLOCK_HIGHRES (interval time).
> > the latter is not adjusted by adjtime or settimeofday or the like.
> CLOCK_HIGHRES sounds like the same thing as POSIX' CLOCK_MONOTONIC,
> which we have.
Note that Solaris' CLOCK_HIGHRES is defined as monotonic and linear
(as Bill Sommerfeld mentioned - it's not affected by adjtime() et
al), whereas our CLOCK_MONOTONIC is just monotonic. It is however
recommended in SUSv3 that CLOCK_MONOTONIC be linear:
Additionally, it is desirable (but not required by IEEE Std
1003.1-2001) that the monotonic clock increases its value uniformly.
This can be fixed pretty easily. Also, currently our CLOCK_MONOTONIC
clock only has hz resolution which means it's not as useful as it could
be in practice.
> While we're on this, we might as well go for true nanosecond
> resolution, so we could leave microtime() alone, and the new kernel
> functions might be called nanotime(), nanotime1() (and monotime()).
Yes, indeed. This would be a good time to switch to timespecs instead
Also, Martin Husemann wrote:
> - division/modulus and addition of "large enough" integer types
> is cheap
One thing that's been keeping me from switching some MIPS ports to
using kern/kern_microtime is that a divide takes much longer than
a multiply. See MIPS_SET_CI_RECIPRICAL and MIPS_COUNT_TO_MHZ in
> A realtime_microtime() could read the RTC and add missing precission by
> locking and reading the bootstrap CPUs microtime value.
On platforms that have the RTC connected up to a I2C or SMBus it can
take a long time to read the RTC - about 6ms on one board I have here.
Simon Burge <email@example.com>
NetBSD Support and Service: http://www.wasabisystems.com/