Subject: Re: Avoiding microtime(9) global state
To: Frederick Bruckman <fredb@immanent.net>
From: Simon Burge <simonb@wasabisystems.com>
List: tech-smp
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
of timevals.

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
arch/mips/include/cpu.h.

> 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.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/