In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Mark Murray writes:
: >> No, he doesn't have access to the offset from the machines local clock.
: >> 
: >> I ran a quick & dirty test here on some logfiles: that offset is
: >> very close to white noise.
: >
: >With what amplitude?
: Depends on the termal environment of your xtal obviously :-)

Poul, what's the Allen Variance for the sample that you measured?
That's going to be the quality of the two oscillators under measure.
Here we see correleations on the order of 10e-15, but that's for
really good cesium clocks :-).

For PC hardware, these differences are going to be effectively random.
Why?  The quartz xtals in them are usually really really bad.  They
drift all over the place with temprature, humidity and all kinds of
other factors.  Even tiny changes in temperature can be measured in
the resulting frequency change of the OSC.  Temperature near the xtal
can vary quite a bit due to the vagaries of PC hardware.  The drift of
your clock is going to be effectively random.  Sure, you know that
what range it will be in, but from moment to moment, you don't know
what the silly thing will do.

I'm not sure how many random bits we can harvest from these
measurements, but they are a good source of at least a few bits.  All
the data I've looked at is for high precision clocks or at least temp
controlled xtals, which have much smaller variations.

Another good source would be if you had a Cesium clock and a GPS
receiver.  The delay due to atmospherics is another good source of
random data.  This varies +- 25ns and is highly locale dependent.  One
can measure this variance down to the nanosecond easily (giving about
5 bits of randomness) and with a lot of effort down to the pico second 
level, which would give you about 15 bits of randomness.

When you are measuring the offset of two clocks that have been
operating independently for a period of time, you'll find that the
offset is effectively random.  Since I think that ntp uses a one way
time measurement, you will know the original time, the time on the
remote, and maybe the approximate time that the packet returns.  You
can make low resolution estimates of the total delay and calculate an
offset based on that.  However, if the clocks are already close the
delay almost always swamps the offset and your estimates of delay will 
be so far off that you'll not be able to estimate more than a few of
the high order bits, if you are lucky.

It certainly would be better than nothing and would be a decent source 
of randomness.  It would be my expectation that if tests were run to
measure this randomness and the crypto random tests were applied,
we'd find a fairly good source.

Warner Losh
Timing Solutions

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to