Hal Murray via devel writes: > The general idea is that if your system clock goes tick, tick, tick, in great > big steps, you want to fill in the bottom bits with randomness. The code > does > that by assuming that the tick size is the time it takes to read the clock - > difference in times between 2 back-to-back readings. That's not right, but > doesn't normally cause any troubles. Maybe it skips samples that don't > change.
No, that description only holds for what are called "coarse" clocks. > That made sense a long time ago when the system clock was updated on a 10 ms > clock interrupt. Yes. > The error messages say that filling in the low bits made clock go backwards. Yes, but the real problem is that you got to identical timestamps from the system for two different reads of the realtime clock. ON the system he uses the timestamps have nanosecond resolution, but the clock probably updates in larger steps, depending on what the system timer is. System fuzz was determined to be around 1µs, so that would indicate HPET or something similarly low-frequency. > I'd really like to rip out all that stuff, but I have at least one Raspberry > Pi where I can read the clock faster than it ticks. Don't. This is a lot more complicated than you seem to think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
