On Wed, Jun 30, 2004 at 01:19:44PM -0700, Erik E. Fair 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.

My theory is, given a modern CPU with cycle counters

 - accessing the RTC is expensive (and needs locking)
 - accessing the cycle counters is ~free (and per cpu, most likely atomic)
 - division/modulus and addition of "large enough" integer types
   is cheap
 - there are lots of places that need relative times (i.e. intervals),
   many of them in time critical paths
 - there are only very few things that need ToD, and besides maybe NTP
   related ones none of them are timing critical

So I think of a very simple (per CPU) microtime implementation that only does
monotonic (but not strong monotonic) interval time, by subtracting the per
CPU last cycle count from the current, converting to seconds and 
microseconds (should we go nano here?) and handles overflow into seconds. The
regular (but maybe not once per second) IPI to sync CPUs would adjust those
timeval and record the current (at IPI) local cycle count.

A realtime_microtime() could read the RTC and add missing precission by
locking and reading the bootstrap CPUs microtime value.

I would try to eliminate all needs for a strong monotonic microtime variant,
but I'm not sure I understand the implications here.

Martin