| Re: [chrony-dev] RFC: chronyd -x serving time on a host whose clock is disciplined by another chronyd |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- To: Robin Nilsson <havrekli@xxxxxxxxx>
- Subject: Re: [chrony-dev] RFC: chronyd -x serving time on a host whose clock is disciplined by another chronyd
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Mon, 19 Oct 2026 12:16:53 +0200
- Cc: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792405021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0SbR4VGhDoEtuLEGW0RRDyz/Vhv0j6C97FtS5s2HOz4=; b=cU7QRn3D2SBVXZo5YtRSJNJT4CV3tSqypAgbMyqfd/gXjNzvraFkPc6yTsfGiod0d8vgf1 G3j8aF7W46gQ8guG/2iokcR/z1iqDiCmiGsK3cZwPbj9Vv8mZB5KvZxcrXrJ7Fe92GYpUp JyM562hggb0pBv/ikbOFS52AtY/OylM=
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
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.