Re: [chrony-dev] RFC: chronyd -x serving time on a host whose clock is d

> Please have a look at this merge request I have been slowly working on:
> https://gitlab.com/chrony/chrony/-/merge_requests/33

Thanks, that is a much better place for it than a -x special case. I'll
drop the -X patch and test 'clock SYS:MONOTONIC_RAW main' instead, with
our setup (chronyd -x in a container serving the host chronyd that
disciplines CLOCK_REALTIME) and the scenarios from my simulation tests:
host steps and slews, +-500 ppm frequency changes and leap seconds. I'll
report back what I find.

> It doesn't try to compensate for the suspend time (BOOTTIME -
> MONOTONIC). Is the goal of doing that forcing chronyd to detect
> a forward time jump and reset the statistics as would happen with
> CLOCK_REALTIME?

Yes. MONOTONIC_RAW stops during suspend, so without it the served time
is behind by the whole suspend after resume, and the null driver has to
slew that out. With BOOTTIME - MONOTONIC added, the scheduler sees the
jump and resets the sources as with CLOCK_REALTIME. Our servers never
suspend, so I don't need it, and I agree it isn't worth the extra
clock reads.

If suspend support is wanted later, I think it can be done without any
extra reads in normal operation. A CLOCK_REALTIME timerfd armed with
TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET is cancelled when the clock
is set and also on resume: timekeeping_resume() calls timerfd_resume(),
and the injected sleep time changes the realtime-monotonic offset that
timerfd_clock_was_set() checks. With that fd in the select loop, the
suspend offset would only need to be read again when the fd becomes
readable. A false alarm, such as a step of the system clock by another
process, would just read an unchanged offset.

Another option might be to let makestep work for a main clock that
chronyd doesn't control, since a step is then only a change of the
offset. Suspend would then be corrected like any other step, but only
after the next measurement. I'm not sure if MR 33 allows that.

> Is that just adding an alias to CLOCK_MONOTONIC in clock_gettime()?

Yes, CLOCK_BOOTTIME as an alias of CLOCK_MONOTONIC, since clknetsim
doesn't simulate suspend. It was only needed for the -X tests, so I'll
leave it out unless you want it anyway.

--
Robin

Den mån 19 okt. 2026 kl 12:17 skrev Miroslav Lichvar <mlichvar@xxxxxxxxxx>:

On Fri, Oct 16, 2026 at 02:09:06PM +0200, Robin Nilsson wrote:
> 1. Is this a use case you would want to support in chronyd, or would you
> rather recommend a different setup? (For example, the host chronyd
> serving time itself. That loses the single movable authority we want,
> but I may be missing a better option.)

Yes, it's a use case I want to support.

> 2. If it is welcome, what interface would you prefer: a directive
> (something like "localclock raw") or an option? And would daemon-only
> timestamps be acceptable for a first version, or should kernel RX/TX
> timestamps be mapped into the private domain from the start?

Please have a look at this merge request I have been slowly working
on:
https://gitlab.com/chrony/chrony/-/merge_requests/33

It's a more general (and IMHO cleaner) approach to supporting other
clocks than CLOCK_REALTIME. It's functionally almost complete, but
it needs more cleanup and optimizations. If you add 'clock
SYS:MONOTONIC_RAW main' to chrony.conf, it should be functionally
close to your patch.

It doesn't try to compensate for the suspend time (BOOTTIME -
MONOTONIC). Is the goal of doing that forcing chronyd to detect
a forward time jump and reset the statistics as would happen with
CLOCK_REALTIME? I don't like much the overhead of three extra clock
reads.

As for using daemon timestamps, I think that is fine. I hope the kernel
will support other clocks for SW timestamping at some point in future.

> 3. I also have unit and clknetsim simulation tests (host steps and
> slews, +-500 ppm, leap seconds, suspend). I left them out to keep
> the patch small and can add them in the form you prefer. The
> simulation tests need clock_gettime(CLOCK_BOOTTIME) in clknetsim; I
> will send that separately as a two-line clknetsim patch.

Is that just adding an alias to CLOCK_MONOTONIC in clock_gettime()?

--
Miroslav Lichvar