Thanks for the reply. I may have explained it badly.
-x does not adjust the clock, but it is not passive either: the man page
says chronyd "will assume the clock is free running and still track its
offset and frequency relative to the estimated true time", and it serves
the system clock plus that correction.
The -x server syncs to public servers, not to the host. The host's own
chronyd syncs to the -x server and adjusts the system clock. When both
run on the same machine, the server sees the system clock move (because
the host chronyd slews it) and changes its correction, and the host
chronyd then follows the new served time. Neither syncs to itself, but
both keep reacting to each other's changes, and that is the loop I
measured.
You are right that the simple answer is to keep the server off the hosts
that follow it, and that is a fair answer to question 1 in my mail. The
point of -X is to make that restriction unnecessary by giving the -x
server a clock the host chronyd cannot touch.
Robin
I am confused. The purpose of -x, according to the chronyd write up, is to
stop chronyd from adjusting the clock. Ie, it asumes your system clock is
accurate. If you have some other program adjusting the clock (why would you
have two programs handling the clock?) then that is going to cause trouble.
Note that -x is NOT a feedback loop.It does NOT try to adjust the clock at
all. It just reads system clock and ships that time out to other machines if
you are using the machine as a source of time. It does not, as far as I can
tell, adjust the system clock at all.
Just don't use two things that adjust the same clock, and especially do not
use another machine which syncs to your machine to sync your machine. Don't
try to "fix" chronyd. Just don't do it.
William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273
Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950
UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 _|_www.theory..physics.ubc.ca
I cannot reply to emails from outlook.com or hotmail.com or other microsoft domains.
Microsoft throws away all emails from my UBC address, and refuses to tell me
why.
On Fri, 16 Oct 2026, Robin Nilsson wrote:
> [CAUTION: Non-UBC Email]Hi,
>
> I run chronyd -x as a containerised NTP server (one instance, no clock
> control, no CAP_SYS_TIME) that a cluster orchestrator can move between
> hosts. Every host runs a normal chronyd that disciplines its own clock and
> uses that server as its only source, so sooner or later the server runs
> on a host whose clock it is indirectly disciplining.
>
> With plain -x that is a feedback loop: the null driver measures the host
> CLOCK_REALTIME, which the host chronyd slews towards the server, which
> in turn corrects for the host's slewing. Two loops end up driving one
> oscillator. On two x86 servers (chrony 4.8) the served time oscillated
> with growing amplitude, about +-160 ms against independent references
> within 25 minutes, and the server's frequency estimate swung between -275
> and +592 ppm. A disposable VM reproduced it (p90 of the served error from
> 12.7 to 55 ms). With the server on a different host from its clients the
> setup is stable.
>
> As an experiment I gave -x a private raw clock (-X, Linux only) that the
> host's clock discipline cannot reach:
>
> LCL_ReadRawTime() = R0 + (MONOTONIC_RAW_now - M0) + (S_now - S0),
> S = CLOCK_BOOTTIME - CLOCK_MONOTONIC (time spent in suspend)
>
> R0/M0/S0 are sampled once before LCL_Initialise(). sys_null.c is
> unchanged, so its frequency/offset model now disciplines the raw
> oscillator, and R0 is only an anchor whose error is corrected like the
> host clock's error with plain -x. The patch also has to:
>
> - use daemon timestamps only (kernel/HW timestamps are in the
> CLOCK_REALTIME domain), so -X refuses hwtimestamp, refclock, RTC and
> makestep/initstepslew;
> - time leap seconds in served time rather than raw time, and require
> "leapsecmode slew" (the null driver cannot step);
> - keep the null driver's offset correction when the scheduler detects a
> jump (after a resume it is the whole error estimate).
>
> Results so far: the upstream unit and simulation tests pass with the
> patch. In a VM, host steps of +-1 s and +-30 s, +-500 ppm and a +1 %
> tick left the served error median at <= 0.45 ms, where plain -x followed
> them (up to +29 s). On real hardware a native chronyd has followed a -X
> server on the same host since 2026-10-01. Deliberate host steps of
> +-1 s and +-500 ppm were not visible in the served time (within about
> 0.7 ms of Netnod).
>
> The prototype is about +250 lines in local.c, main.c, ntp_io.c,
> ntp_io_linux.c, reference.c and refclock.c. I know it is not
> mergeable as it stands: it has no kernel timestamp mapping, it is Linux
> only, it supports only the slew leap mode, and it is an option rather
> than a directive. So before going further I would like to ask:
>
> 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.)
> 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?
> 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.
>
> The patch (one commit against current master) is here:
>
> https://github.com/oatsbran/chrony/commits/independent-raw-clock
>
> Thanks,
> Robin Nilsson
>
>