[Hal, I've asked before, but again: Can you please configure whatever you use as your mailer to not always break threading when you reply?]
Hal Murray via devel writes: > The code that reads the clocks works hard to make sure that fuzzing the > bottom > bits doesn't make time go backwards. That logging is what happens when > things > go wrong. The fuzz applied is already small enough to not matter and on the order of the granularity between two clock reads, assuming not too old x86 hardware with stable TSC. PLus it changes it around such miniscule amounts that it really doesn't make any sense for it to get reported. However, looking at the clock values it really doesn't make sense to me how NTPd managed to do two clock reads in such a short amount of time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
