Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]

[frantz@netcom.com (Bill Frantz)]

At 17:19 10/31/95 -0600, Martin Diehl wrote:
>     2. When doing time domain measurements (Hewlett Packard had some good 
>     application notes on this subject), you must consider base clock 
>     jitter.  Ill try to illustrate with a diagram:
>     
>     actual event:            V                    V
>     clock granularity:  /...../...../...../...../...../...../
>     
>     the problem is that no matter how small the basic clock unit is 
>     (symbolized by "/", above), you can't be sure how much of that unit 
>     has passed when the event (symbolized by "V", above) occurs.  For 
>     example, on the original IBM PC, clock interrupts occurred about 18.2 
>     times per second (55ms interval).  In that architecture, you can't 
>     time an event and have an uncertainty of less than 2 times 55ms

Ah, but there is a neat hack that works well if you can dedicate the whole
processor to doing the timing.  This works with systems that do not have
preemptive multi-tasking.  (Getting it to work with preemptive
multi-tasking is a harder excersize).  Credit where credit is due, I first
saw this technique used, probably in 1968, on the IBM/360 (60HZ clock) with
a pair of programs called PACER and RATER.

Monitor the clock location.  (It doesn't matter whether it is incrmented by
hardware or software.)  Run a timing loop from when it changes until it
changes again and count the number of times through the loop.  Then use the
same timing loop and count how many times the loop runs from a clock tick
to the event of interest (or from the event of interest to the next clock
tick).  Use the ratio of the two counts to interprolate between the times
you can get from the clock.

You have used the processor's instruction rate to synthesize a better clock.

Bill