logging

[Achim Gratz]

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