In message <200006060115.e561FA700787@thunk.hamachi.org>Bill Sommerfeld writes


>A different interface should be provided for timekeeping.

Either that, or this one shold be thrown away and replaced
with something more general.

>No, I haven't.  i've been meaning to look into options for
>high-resolution timekeeping purposes, but that has dramaticaly
>different requirements than random timer sampling.

>/dev/random wants an *efficient, low-overhead* sample of a timer of
>indeterminate origin and frequency.  

And timekeeping needs an "*efficient, low-overhead*" sample of a timer
of known origin and frequency. The requirements stated for
/dev/random are a strict subset of those for timekeeping.


>Raw access to the cycle counter
>is best for this purpose. 

Not really. Some CPUs dont' give you a raw cycle counter, but they do
give you a high-res, free-running clock. Except on some architectures,
the low order bits of that counter are zero, on some models.


[...]


>the existing /dev/random driver could do less in the driver interrupt
>hook than it does now; having to do a 64-bit fixed-point multiply or
>similar crud to scale it into a common timebase, and then undo it,
>would make it far more heavyweight than it needs to be.

Huh? you dont want to do that for timekeeping, either.  (if you take
a look at the timecounter stuff, this might be a lot clearer).


A good NTP PPS-API design might, for instance, record a timestamp at
each interrupt on a PPS device (at the time the interrupt is
requested), and only do the expensive multiply -- or, on an Alpha, an
even more expensive divide -- on the one instance per second when
the PPS signal goes off.

If we design this properly, then this  rnd-inspired API really
*is* redundant.