Subject: Re: new MI/MD interface for rnd(4)
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/05/2000 18:34:30
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