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

[Thomas Gleixner <tglx@kernel.org>]

On Wed, May 20 2026 at 13:21, David Woodhouse wrote:
> On Wed, 2026-05-20 at 12:39 +0200, Miroslav Lichvar wrote:
>> 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). 
>
> We could just use the TSC for this, insted of MONOTONIC_RAW, couldn't
> we? Do all our clock discipline of the *TSC* against the external
> sources, and then use the same timekeeper_set_reference() to ask the
> kernel's core timekeeping to track the TSC-to-realtime relationship
> that we desire?
>
> That's exactly what I'm planning to do for a dedicated hosting
> environment. I think the patches which allow PTP to return paired
> timestamps with reference to TSC instead of CLOCK_MONOTONIC landed in
> the net-next tree today?

Bah.

> (for TSC, read 'arch counter, timebase, etc.' — none of this is x86-
> specific but 'TSC' is quicker to type...)

As I said in the other thread, that's just creating yet another private
mechanism instead of collecting the counter value together with e.g.
CLOCK_REALTIME or utilizing the PMT correlated one which is available in
get_device_crosstime_stamp().

Can we please stop creating specialized interfaces and instead make them
generic, so they can be used for everything?

Then you can go and extend the posix-timer interface with
clock_set_time_reference() (or whatever name we come up with) and
provide the functionality for all steerable clocks. That'd allow chronyd
to completely ignore the kernel side NTP PLL and do everything in user
space. That obviously needs some thought and input from the chrony
folks, but that's a long term useful solution and not some 'scratch my
itch' side channel.

Thanks,

        tglx