On Thu, Apr 03 2025 at 10:32, Miroslav Lichvar wrote:
On Tue, Apr 01, 2025 at 08:29:23PM +0200, Thomas Gleixner wrote:
64 64 0.138
That's weird as it only delays the update to the next tick.
Ok, so it's not an instability of the clock, but rather an instability of the chronyd synchronization loop, which since kernel 4.19 expects the frequency to be applied as soon as the adjtimex call is finished.
Interesting.
Patch applies after reverting 757b000f7b93 ("timekeeping: Fix possible inconsistencies in _COARSE clockids").
I ran multiple longer tests to be able to compare the small values in the noise and yes, from the adjtimex point of view this seems to work as well as before the first COARSE fix. I didn't run any tests of the COARSE clock.
I did run those, but did not run the adjtimex() muck :)