New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ntp subsystem tweaks #68516
ntp subsystem tweaks #68516
Conversation
This is reckless, ill-advised, pointless, and I will be scorned for it, but it makes me feel a lot better. Signed-off-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
'iburst' allows chrony to make very quick adjustments to the clock by doing a couple rapid measurements outside of the default 'minpoll' option. This helps improve rapid time adjustment at boot, and is enabled by default. Signed-off-by: Austin Seipp <aseipp@pobox.com>
This option was added in 6336048 but it is essentially a complete duplicate of the existing cfg.servers and there seems to be no reason to keep maintaining it. Furthermore, it requires annoying duplication if you try to do option merging, e.g. merging in sets into your configuration.nix that add `services.chrony.initstepslew` options will overwrite the servers option unless you keep it, but that means you just have to duplicate config.networking.timeServers again anyway which is an implementation detail! Signed-off-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
do we have tests for ntp couldn't find any ? looks good |
Unfortunately not. :( It's hard to do anything other than just "make sure daemon starts and runs for a while", because QEMU VMs do not have network connectivity or upstream pools to sync with. QEMU timers are fairly inaccurate by default; I've seen upwards of ~5s deltas between two NixOS VMs in terms of clock skew, immediately after boot. There is one test we could write, I suppose: starting up one NTP machine in a NixOS test with a "freestanding clock" that just synchronizes to nothing, and then having a few other NixOS machines synchronize to that remote NTP daemon. The original machine would have some weirdly inaccurate clock, while the remaining machines would, theoretically, stay in sync. But again, this is essentially just "start and run daemon for a while", with a little cherry on top. I'm not sure what actual invariants we would want to check for, but I'm open to ideas... Because only Chrony has been modified in this PR, I have tested it manually. |
I'll also note that #51338 has a commit which does exactly this to test CockroachDB, so after that's merged, we effectively will have a test of Chrony, at least... |
How reliable would such a test on host that runs at a high load (load >> no. of cpus)? |
Motivation for this change
This is a slice of the patches that I originally posted in #51338 -- the uncontroversial changes. The intent is to make the original PR easier to merge/reason about after this is done.
Things done
sandbox
innix.conf
on non-NixOS)