Combining NTS and non-NTS servers?

Server operators
1

This isn’t directly related to the pool, but where else is there such an experienced group of people running NTP servers?

I have been playing around with NTS a bit, and have come across a lot of conflicting information about what happens when you combine NTS servers with non-NTS servers. My goal here is to refine my understanding of how everything works; this is a sandbox system, not something requiring mission-critical assurances of accurate time. I am running chrony 4.5.

I have the following (experimental, non-ideal) configuration. All NTS servers have the require keyword; all non-NTS servers do not.

sources:

chronyc> sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- 50.205.57.38                  1   8   377    43   +286us[ +286us] +/- 3535us
^- ntp1a.versadns.com            1  10   377    91  -1973us[-1973us] +/-   12ms
^+ usnyc3-ntp-001.aaplimg.c>     1  10   377    81   +138us[ +138us] +/-  804us
^* usnyc3-ntp-004.aaplimg.c>     1   9   377   189   +118us[ +176us] +/-  737us
^- virginia.time.system76.c>     2  10   377   22m   -369us[ -352us] +/- 6468us
^- a.st1.ntp.br                  1   8   377   178   +471us[ +471us] +/-   56ms
^- ptbtime1.ptb.de               1  10   377   138   +123us[ +123us] +/-   43ms
^- (redacted)                    1  10   377    61  +3297us[+3297us] +/-   11ms
^- stratum1.time.cifelli.xyz     1  10   377   34m  +2798us[+2824us] +/-   17ms
^- ool-18b97a39.dyn.optonli>     2   7   377     3  -1269us[-1269us] +/-   29ms
^- clock.nyc.he.net              2   7   377    19   +880us[ +880us] +/-   32ms
^- time-b-g.nist.gov             1  10   377   885   +992us[+1083us] +/- 5072us
^- ntp1.torix.ca                 1  10   377   127   +360us[ +360us] +/- 5986us

selectdata:

chronyc> selectdata
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
D 50.205.57.38              N ----- -----   49   1.0 -3250us +3833us  N
D ntp1a.versadns.com        N ----- -----   96   1.0   -14ms   +10ms  N
+ usnyc3-ntp-001.aaplimg.c> N ----- -----   86   1.0  -686us  +957us  N
* usnyc3-ntp-004.aaplimg.c> N ----- -----  194   1.0  -632us  +887us  N
D virginia.time.system76.c> Y ---R- ---R-  22m   1.0 -7096us +6129us  N
D a.st1.ntp.br              Y ---R- ---R-  184   1.0   -55ms   +56ms  N
D ptbtime1.ptb.de           Y ---R- ---R-  143   1.0   -43ms   +42ms  N
D (redacted)                N ----- -----   66   1.0   -10ms   +10ms  N
D stratum1.time.cifelli.xyz Y ---R- ---R- 1033   1.0   -14ms   +19ms  N
D ool-18b97a39.dyn.optonli> N ----- -----    9   1.0   -30ms   +25ms  N
D clock.nyc.he.net          N ----- -----   24   1.0   -31ms   +33ms  N
D time-b-g.nist.gov         N ----- -----  890   1.0 -4236us +6157us  N
D ntp1.torix.ca             N ----- -----  132   1.0 -5635us +6352us  N

Four servers support NTS, indicated with the “Y” for “Auth”, and all are configured with the require keyword in chrony.conf. It is described as such:

 require
     Require that at least one of the sources specified with this option is selectable (i.e. recently
     reachable and not a falseticker) before updating the clock. Together with the trust option this might
     be useful to allow a trusted authenticated source to be safely combined with unauthenticated sources
     in order to improve the accuracy of the clock. They can be selected and used for synchronisation only
     if they agree with the trusted and required source.

So my interpretation of what is happening is:

  • The two Apple servers (no NTS support) have been selected as best (probably since they are very close latency-wise). They do not support NTS or have the require keyword, but are the ones steering the clock.
  • All four of the NTS servers (some of which are on different continents) show a “D” in selectdata, indicating they aren’t being used for setting the time because of large distance (very reasonably).
  • But, even though they aren’t selected or combined, the NTS servers fulfill the “selectable” criteria of the require keyword, and chrony considers everything good.
  • Therefore, while I cannot be confident that the exact offset from the Apple NTP server is not tampered with, I can be confident that it’s within the +/- 30ms-ish window the required NTS servers agree on. If there were a sharp disagreement, the clock would not be adjusted.

Is this an accurate understanding?

Obviously, this exact configuration with 13 servers, spanning several continents, is not ideal. What I’m generally curious about is whether, given the sparse number of NTS servers that exist today, it’s possible to incorporate a few of them with much closer non-NTS servers for at least a decent compromise, if not the best of both worlds.

I readily acknowledge that “it uses NTS!” is not proof that a clock is inherently trustworthy per se. Part of what I’m considering is how one would set up a stratum 2+ NTS server, where using non-NTS (or otherwise authenticated) servers seems important, but at least here in the US there are relatively few to choose from.

2

Oh, I am silly. There was an authselectmode ignore line in my config.

Changing it to mix has me confused. This is what I’m seeing:

chronyc> selectdata -v
  . State: N - noselect, s - unsynchronised, M - missing samples,
 /         d/D - large distance, ~ - jittery, w/W - waits for others,
|          S - stale, O - orphan, T - not trusted, P - not preferred,
|          U - waits for update,, x - falseticker, + - combined, * - best.
|   Effective options   ---------.  (N - noselect, P - prefer
|   Configured options  ----.     \  T - trust, R - require)
|   Auth. enabled (Y/N) -.   \     \     Offset interval --.
|                        |    |     |                       |
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
D 50.205.57.38              N ----- -----   71   1.0 -3416us +3701us  N
T ntp1a.versadns.com        N ----- -----  397   1.0   -14ms +9832us  N
D usnyc3-ntp-001.aaplimg.c> N ----- -----   76   1.0  -731us  +670us  N
* usnyc3-ntp-004.aaplimg.c> N ----- -----    6   1.0  -657us  +688us  N
D virginia.time.system76.c> Y ---R- --TR-  261   1.0 -7481us +6955us  N
D a.st1.ntp.br              Y ---R- --TR-   11   1.0   -57ms   +56ms  N
D ptbtime1.ptb.de           Y ---R- --TR-    6   1.0   -43ms   +42ms  N
T (redacted)                N ----- -----    0   1.0 -8931us   +12ms  N
D stratum1.time.cifelli.xyz Y ---R- --TR-  199   1.0   -14ms   +19ms  N

The usnyc3-ntp-004 server was set up with iburst, so I’m thinking what happened is that it was the initial clock it synced to. But now all other sources are being rejected: either for too large of a distance, or for not being trusted.

It seems extremely aggressive in rejecting usnyc3-ntp-001 for distance.

I’m going to let this run for a while, but as I think I understand the behavior I’m not sure it will change. The authenticated servers have a lot more uncertainty and can’t be used on account of distance, and the non-authenticated ones can’t be used because they’re not trusted?

3

There is a delay in the reselection of combined sources to prevent frequent switching between + and D, which causes jumps in the combined offset. When a source is marked as D, it needs to pass 32 selections to be marked as +, assuming the source marked as * doesn’t change.

If there are mixed iburst and non-iburst sources, the estimated skew (which impacts the estimated distance at the time of the selection) will drop sooner after start for the iburst sources, making it more likely the non-iburst sources will be marked as D. You can enable the selection log to see what is happening on start.

1 Like
4

I believe so, based on similar experiments that I did earlier in the year. When there was no NTS-capable server (I can’t remember whether deliberately or because I screwed up the configuration), chrony stopped synchronising to the (much nearer) non-NTS ones.

1 Like