Skip to content
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

Merged
merged 6 commits into from Sep 12, 2019
Merged

Conversation

thoughtpolice
Copy link
Member

@thoughtpolice thoughtpolice commented Sep 11, 2019

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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)

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>
@teto
Copy link
Member

teto commented Sep 12, 2019

do we have tests for ntp couldn't find any ? looks good

@lheckemann lheckemann added this to the 20.03 milestone Sep 12, 2019
@thoughtpolice
Copy link
Member Author

thoughtpolice commented Sep 12, 2019

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.

@thoughtpolice
Copy link
Member Author

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...

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...

@markuskowa
Copy link
Member

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.

How reliable would such a test on host that runs at a high load (load >> no. of cpus)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants