| Re: [chrony-dev] [PATCH] ntp: allow NTS pools to use multiple negotiated servers |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
- Subject: Re: [chrony-dev] [PATCH] ntp: allow NTS pools to use multiple negotiated servers
- From: Sofia Scalzo <sofiascalzo@xxxxxxxx>
- Date: Mon, 7 Sep 2026 16:40:36 +0100
- Arc-authentication-results: i=1; mx.google.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version; bh=LRzGDXcGzJm5DCUejgfDqvrWw+twObXjxgVeETB6FRg=; fh=k+ymY3GKe+h5SPVFNw/XO/9XWICqQUpxQaQ4GR1alRo=; b=rjmvoTs8Flw7rZj6SpYOJhgXfn27+iYkNi7JZUYZMnxDCkSI7VZ8ldrh43WjmouUGq NBpHKinYK1UcLdXh5Zjav0mVxJYmyt5nOo9IPLX+VENZeZCU+kOWA32ptQltxqle0S5y po/AO4g3ShBUGSWZB/SSNRw29DhTFIGyd1KiZUyooj8fGQIp1WOUbPJRn0Lmp3duRzHj FyDjk4GX7BmLSVa4uhXW36P+9ZTNvZc3JI+kTLtYN/udWQW+EY6jI+yYi4jz2EGzdMUq P7sNWrgOlmFpiMylr07R04Po838BByW/Qd9vVC2/qkZCwcUaym4iMJ7cmEZJvHXro4xo w08w==; darn=chrony.tuxfamily.org
- Arc-seal: i=1; a=rsa-sha256; t=1788795652; cv=none; d=google.com; s=arc-20260327; b=B/i9e99aISFTDG8uAtzeCnijDuFVxVbExlxQktXyzZ5RlUIikp8Yy/+tWZBvr5z4Xo +Wm9BJZaqN0jldxXfQztbfR837WH4XwWeDc9JHfTNowUOnjcQb6WrJCJPkkziFwEosGW V1n2QBx+d4z2z9VdbMSdO6uaDLxzO1bOxLrJre0j0+WIkWt/Ewsek8XKzDajb7FZTq3W +PMZsSg5EGXWwebM8Z6nEdNTghrdlyeMP0k4nR66qB75XRH9Zp2HMGqJbGqB6dEB25aJ MBPQG9F7/dZoSMbWKHS6wt8ts6l+r5vBoN9ma1UvLcFYj//YqqCWjE6ZqSNPmHarRjgY o5lw==
- Cc: chrony-dev@xxxxxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject; s=pps82601-s2048-2026-q3; bh=L9EudZ+IQW1Pqg Wwjpf7EHnhWgxSlRvdQArZf6Cw3K8=; b=YerGt0ZQO6syqoYXsdvqQSPjrHKFaG 4h63Uy+fNkBQNsje5cEx0kd36ctSQph4UA1J97AvhrvFluwvIn7w/wxCP3ahJvp3 vx03jBDtqsbIJcnMWY4+tI2eRz/UkpW8G7NntCsaRmzDho0c8Tt3RMw602TB+oy9 yLDs/pUb9pvYCr2cTpcVwKth9jVCvZmUu+XwvrhQuEH3H337Y/DuUMNefaxVBO2P sie8lB0ZFYqU4/XmjMqr0lwWagNKWdGUQrzdOiQ4Xz8/3cMc+ms6gj7Vgbeq3V1B sc+vNXidlwM0OkopNz/bW8WT5y1nCaQ7rBPnBCUYKCUwIN+PBq8a54Wg==
I need to correct my previous report. My test was using the installed
chrony 4.8, and I had not realized that the current development version
includes the maxntsretry source option.
I repeated the test with the unpatched development version using
maxntsretry and all responder VIPs became authenticated and reachable.
Thanks for pointing me in the right direction.
Best,
Sofia
On Thu, Aug 20, 2026 at 08:02:28AM -0700, Sofia Scalzo wrote:
> Allow an unresolved member of an NTS pool to reuse the NTS-KE address
> after another member moves to a negotiated NTP server address.
>
> This enables a pool resolving to one NTS-KE endpoint to discover
> multiple distinct NTP responders up to maxsources. Each tentative member
> retains independent NTS keys, cookies, and protocol state.
In this pool there is only one NTS-KE server that as the address of
the NTP server in the NTS-KE response provides a hostname that
resolves to multiple IP addresses? That's unusual. Are there any
public pools using this approach?
If I understand your patch correctly, it doesn't "enable", it only
makes the discovery faster by avoiding the delay before the next
attempt to resolve the unresolved source is made.
In a local test with three NTS-NTP servers with and without your patch
(with the same randomized order of resolved addresses) it took 194
seconds instead of 260 to send the first NTP request to the third
server. An improvement, but the main problem that the first successful
selection doesn't happen when all sources are selectable is still
there.
I think a better approach would be to allow NTS sources to start with
their original IPADDR_ID addresses and change them at the same time to
the resolved addresses of the NTS-KE-provided hostname, so the first
selection uses all sources. This would be a much more invasive change.
I suspect it might also be confusing to users as the sources would be
invisisible in chronyc reports without the -a option until a
successful NTS-KE exchange.
If this type of NTS pool is not going to be more common, I'm not sure
if it's not worth the additional complexity.
--
Miroslav Lichvar