Subject: Re: machine-independent cycle counter based microtime()
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 01/21/2003 13:03:26
On Tue, 21 Jan 2003, Jonathan Stone wrote:

[JS: >...why not just call it cycletime()?  That should get us into the next
[JS: >century or so.
[JS:
[JS:
[JS: Cleaning up the in-kernel interfaces is a Good Thing, but we should
[JS: provide nanosecond resolution internally (in the kernel) from the
[JS: get-go.

You didn't read (or at least you did not quote) the second part of my
suggestion which was that "micro" perhaps ought to be viewed as meaning
"small", i.e., "subsecond" in the context of time.  So it's nanoseconds,
now.  If we go orders of magnitude smaller, what then?  picotime() replaces
microtime()?  I mean, granted, we're going to hit lim(C) pretty quick unless
we have some SERIOUS scientific breakthroughs, so it's not likely to go past
picotime(), if we get that far!, but must we keep renaming things every
time we jump to a smaller/larger unit of measurement?  This seems
ludicrous.

[JS: In a separate but related issue, microsecond-resolution NTP code is
[JS: ... getting pretty lame, by today's standards.  (Cycletime(), you say?
[JS: On which CPU, given an SMP system with multiple distinct CPU-clock
[JS: frequencies?)

see above.  I think "micro" is, in this case, taken too literally (in the
context specific to time as 'microseconds') or not literally enough (in
the general context of "very small").

				--*greywolf;
--
NetBSD: more is more.