Quoting Bill Frantz (frantz@communities.com):
> At 04:49 PM 5/22/00 -0700, Josh MacDonald wrote:
> >Quoting Jonathan S. Shapiro (shap@eros-os.org):
> >> What's the granularity? I want better than seconds. It's not that I think
> >> the clocks are accurate, but more bits tends to avoid sort collisions even
> >> when they are bad bits.
> >>
> >
> >I would try to have granularity of at least nanoseconds. The FreeBSD
> >stat command returns nanosecond granularity for ctime, atime, and mtime.
> >A 64bit counter is good at this granularity for about 580 years. Maybe
> >you want to avoid the Y2.5K problem, maybe you don't. I would prefer
> >storing a string representation of the number of nanoseconds since the
> >epoch and using 64bits for internal computation.
>
> Josh - What clock gives that kind of granularity? I thought the best you
> could do was the CPU clock which only gives you nanosecond granularity if
> you are running a 1000MHz or better processor.
A 500MHz machine has a clock granularity of 2 ns, we're already there.
Note on overhead: My 2-way PII Xeon @ 450MHz takes about 50 cycles for a rdtscll instruction (compare to 530 cycles for gettimeofday() on Linux 2.2.12).
-josh