sys_fuzz

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> I think your math is way off.  It would be right for 64 bit random samples, 
> but TSC values are not random.  If you boot two identical machines an hour 
> apart, a sample from one machine will never match a sample from the other 
> machine if the samples are collected at roughly the same time.  (Adjust "an 
> hour" and "roughly" as needed.)
> 
> If the machines are similar (aka same brand and specs and such) then the TSC 
> counters will tick at slightly different rates.  Half the time they will 
> drift apart.  The other half, they will get closer until they cross, then 
> drift apart.  If you sample when they are close you might get a match.  
> Otherwise, see above.

That makes sense. I was thinking of the low-order bits of the TSC as a
random function of the sampling time, which is how I made the mistake.
Just because two TSCs have that property doesn't make them uncorrelated
with *each other*.

> > It occurs to me that one reason to jump is that in the SMP case we have no
> > guarantee that the fuzz calculation itself is reliable. I mean, what happens
> > if a process migration intervenes between the "adjacent" measurement calls? 
> 
> We are assuming that the kernel generates correct time.

Fair enough.  I guess we have to.

> You could add writing code to check for that to your list.  Feels like shared 
> memory and a thread per CPU, but I don't have any good ideas for the inner 
> loop.

This seems more like a job for Gary, once we've cleaned things up
enough that he's willing to dive into the C code again.  He's
commented that he doesn't want to face the piles of crap I excavate
every day and I can't blame him for that - on the other hand I think
the Augean-stables part of this job is pretty close to being over.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>