Re: [RFC PATCH v3 00/10] timekeeping: Fix drift tracking precision and add feed-forward discipline via vmclock

[David Woodhouse]

On Wed, 2026-05-20 at 14:33 +0100, David Woodhouse wrote:
> This is v3 of the series to allow feed-forward clock discipline, allowing
> a guest kernel to lock its system clock directly to a hypervisor-provided
> vmclock reference with nanosecond precision and no drift.
> 
> With all the drift-inducing bugs in the core timekeeping resolved in the 
> first patches of the series, the RFC timekeeping_set_reference() 
> function basically just sets the tick length and time_offset according 
> to the reference, and lets the now-fixed core timekeeping get on with
> its job.

I wanted to see what effect that had, if any, on normal NTP timekeeping
with chrony.

I set four identical bare metal hosts running the baseline 7.1-rc4+
kernel. With and without my timekeeping fixes, a pair with NO_HZ_IDLE
and a pair with HZ_PERIODIC (at HZ=1000).

I'll let the test run over the weekend; collating the data is a semi-
manual set of script hacks but for the time being this is being kept
updated with the latest results: https://david.woodhou.se/ntptest/

Any feedback on the analysis — and especially on the raw data that I'm
collecting — would be welcome.

This is just using chrony and NTP, no PHC as I wanted to simulate a
"normal" consumer-style setup.

In a future test I'll set up a proper feed-forward discipline and use
timekeeping_set_reference() to steer the kernel's timekeeping based
directly on the TSC.

I suspect that will give better results especially in the nohz case,
because chrony can only discipline what it *sees*, and has no way to
see the "intended" values including ntp_error and time_offset; only
what the actual xtime output has sawtoothed to after prolonged and
unpredictable periods of no ticks to drive the 'mult' dithering.

Attachment: smime.p7s
Description: S/MIME cryptographic signature