NTP Performance

Achim Gratz Stromeko at nexgo.de
Sat Nov 23 09:22:46 UTC 2019

[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.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:

More information about the devel mailing list