Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock

[Miroslav Lichvar <mlichvar@redhat.com>]

On Tue, May 19, 2026 at 04:50:41PM +0100, David Woodhouse wrote:
> The design has two major purposes:

>  • Avoiding the redundant work of having *hundreds* of guests on the
>    same host *all* calibrating the same underlying oscillator, while
>    enjoying the added fun of steal time as they're trying to to so.

But isn't that work still duplicated, only moved to the kernel? The
userspace part could be a simple loop waiting for vmclock
notifications and following the changes of the host. The only
difference would be a longer delay, but still insignificant for the
intended purpose, right?

I don't like the idea of adding more clock control loops to the kernel
much. It's a complexity that will likely grow as different
requirements come and the code will be even more difficult to
understand. IMHO the NTP PLL and hard PPS loops shouldn't have been
included in the kernel. The kernel time control API should have been
just setting/stepping the time and changing the
frequency, both possibly at a specified time instead of the time of
the call.

> > Have you considered a different approach that would address the
> > problem with frequency step by adjusting the guest's clocksource
> > frequency to match the original host? That would correct all system
> > clocks, i.e. not only REALTIME/MONOTONIC, but also MONOTONIC_RAW and
> > AUX clocks.
> 
> You mean TSC scaling to change the frequency of the actual counter? 

Yes, in hardware if available, or in software if not. An additional
32-bit multiplier applied like this:

 cycles += (cycles * mult) >> shift

Larger adjustments can be done in the normal multiplier for all clocks.

> When stepping between non-identical hosts, that might be helpful. But
> we still have to deal with the variance of the counter over time even
> without migration in the picture.

Whatever is synchronizing the guest clock to the host (using the PHC
or vmclock page) will take care of that? The point is to avoid
migrations causing a frequency step.

I'm not sure what identical and non-identical hosts mean in this
context, same nominal CPU frequency, or a CPU tied to the same crystal
oscillator?

> > The guest would still be in control of its clock and follow its own
> > preferences to stepping, maximum frequency errors, etc. It could still
> > compare the stability and accuracy of the host's clock and use it for
> > synchronization only when it's actually better than other available
> > time sources (some VPS providers are known to have poorly synchronized
> > host clocks).
> 
> I think that mode is already available as a PTP clock, isn't it?

Yes, but it's slow due to missing frequency transfer, not feed-forward
as you call it. The host's frequency offset could be exposed in the
PHC's timex.

> > There is a work in progress for chrony to support MONOTONIC_RAW as the
> > main clock. It would be nice if that could be corrected in migrations.
> 
> Not sure I understand this. I thought the whole point of MONOTONIC_RAW
> is that it *isn't* skewed by NTP?

It isn't adjusted, but it can be used as a stable reference avoiding
the multiplier-induced jitter, interference from other processes, and
synchronization loops, e.g. when an NTP client is synchronizing to an
NTP server running on the same system (in different containers). 

-- 
Miroslav Lichvar