[email protected] said: > Sure. But if my new understanding is correct, all *this* problem requires > is stepback protection, not fuzzing. Please check me on that. Worst case, > lots of migration could make the TSC look a bit like a random variable with > a very low frequency of collisions (proportional to (2^64)^-2 by birthday > effect); filtered through the stepback check this would look a lot like > fuzzing.
Why are collisions interesting? 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. > 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. 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. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
