svn commit: r274739 - head/sys/mips/conf

[Ian Lepore]

On Tue, 2014-11-25 at 13:15 +0100, Dag-Erling Smørgrav wrote:
> Ian, please try the attached patch.
> 
> The way this is intended to be used is that you set up a system with an
> /etc/rc that does nothing else than mount the root file system and
> append the output from "sysctl -b hw.attachtimes" to a log file, then
> reboot.  You let it run for as long as you wish, then copy the log file
> to another machine and run the attachtimes utility (source code below)
> on the log file to extract the data and display either the raw numbers
> or a histogram showing the distribution.
> 
> See freefall:~des/software/attachtimes.tgz for an example of how to set
> this up.  All you need is the loader and kernel, a minimal /etc, and the
> tools required by /etc/rc (sh, fsck, mount, df, sysctl, halt, reboot).
> The example contains quite a bit more than that because I wanted to be
> able to boot it in single-user mode for debugging.
> 
> The patch can easily be modified to record the actual timestamps instead
> of just the delta, but remember to modify the utility as well, or the
> output will be complete nonsense.
> 
> DES

Getting the results for this is going to take a while... I can't get the
system past mountroot right now.  I have no idea why.  It's been months
since I last successfully booted -current on this old hardware.  I'm
also very busy with $work.

For the 3 numbers that are identical at the start, I think we're reading
garbage in binuptime() because the clock driver isn't working yet.  The
numbers first change with at91_st0, that's the clock driver.  atmelarm0
is the parent of everything listed between nexus and it, so the large
number there is probably the subtraction of the post-init clock value
from the pre-init clock garbage.

In a more general sense, I'm going to repeat a couple things...

The clock all this is being measured with runs at 32 KHz.  That's 'K'.  

This output is evidence that the system behaves exactly as I've been
saying it behaves for a long long while.  You seem convinced, I don't
understand why, that there must be some error here.  I don't understand
why you think a system like this would behave any differently each time
it is powered on.  The only actual entropy involved is whatever minor
thermal transients may exist in the crystal oscillator.  With 32KHz
resolution (or even a few MHz) that amounts to not a lot of measurable
variation at all.

The repeatability of the boot sequence of hardware like this is nearly
perfect at the resolution we're measuring.  While that may be bad for
gathering entropy, it's a wonderful thing when you're debugging, because
problems that would be almost impossible to nail down on modern complex
hardware are 100% reproducible by just hitting the reset button.  That
reproducibility extends all the way into multiuser mode unless there is
a network connection where packet arrival times start adding
interrupt-based entropy.

-- Ian