109.74.206.120 – stale reference timestamp / high root dispersion

Server operators
1

I’m seeing what appears to be a synchronisation issue with NTP server 109.74.206.120.

The server responds normally to NTP requests and advertises itself as Stratum 2, with LI=0, but its reference timestamp appears to be approximately 18.5 days old.

Test performed on 2026-09-04 using:

chronyd -Q -d -d 'server 109.74.206.120 iburst'

Relevant output:

stratum=2
root_delay=0.005280
root_disp=1.607635
refid=5a9b0c0e
reference=1786932308.013579334

The reference timestamp remained exactly the same across multiple responses.

Chrony reported:

root_dispersion=1.607647
dist=1.614168

The actual network performance to the server appears reasonable, with samples showing offsets around 9–13 ms and delays around 3–8 ms.

Chrony considers the individual packets valid (valid=1 good=1), but the combination of an approximately 18.5-day-old reference timestamp and ~1.6-second root dispersion seems unusual for a server advertising itself as a synchronized Stratum 2 source.

Could someone confirm whether this server is currently active in the NTP Pool and whether the Pool monitoring system is seeing the same issue?

2

Seems to be ok:

ntpdate 109.74.206.120
2026-09-09 19:37:50.131803 (+0200) -0.016630 +/- 0.013310 109.74.206.120 s2 no-leap

Problem being?

3

“whether this server is currently active in the NTP Pool” → this is easy to verify from the server’s score page: https://www.ntppool.org/scores/109.74.206.120

Its score is currently 20, which is well above 10, the threshold for including in the pool. However, if you look at the score graphs it’s quite clear that the clock is slowly drifting, as would be expected when the clock doesn’t get properly synchronized. Once the offset grows large enough, the server will get dropped from the pool.

In short, yes, there’s a problem but the pool monitoring system thinks the problem isn’t yet severe enough.

4

A caveat. . I’ve seen clients that reject NTP responses with
(NTP Transmit Timestamp - Reference timestamp) > 1 day.

I am not aware of a formal specification though.

5

Hi,

I just wanted to flag what looks like an ongoing synchronisation issue with the NTP server 109.74.206.120.

I’ve been testing the server periodically since 4 September using chronyd. The server is responding normally to NTP requests and continues to advertise itself as a Stratum 2 server with Leap Indicator 0 (synchronised).

However, its reference information appears to have stopped updating.

Across every test I’ve performed, the server has continued to report the same:

Reference timestamp: 1786932308.013579334

and the same upstream reference:

Ref ID: 90.155.12.14

The reference timestamp was already around 18 days old when I first noticed the issue on 4 September and is now approaching 24 days old.

At the same time, the server’s reported root dispersion has been steadily increasing:

Date Approx. root dispersion
4 September 1.608 seconds
6 September 1.777 seconds
7 September 1.851 seconds
8 September 1.937 seconds
9 September 2.061 seconds

The server’s actual time is currently still reasonably close to other sources. For example, my latest test showed an offset of around 16 ms, so I’m not suggesting that it is currently serving time several seconds incorrectly.

The concern is more that the unchanged reference timestamp and steadily increasing root dispersion appear to indicate that the server has lost, or is no longer successfully updating from, its upstream reference 90.155.12.14, while it continues to advertise itself as a synchronised Stratum 2 source.

The latest test on 9 September showed:

Stratum: 2
Leap indicator: 0
Reference ID: 90.155.12.14
Root delay: 5.280 ms
Root dispersion: ~2.061 seconds
Measured offset: ~16 ms

chronyd still considers the individual NTP responses valid, so the server itself is reachable and responding consistently.

I thought it was worth flagging in case the operator isn’t aware of the upstream synchronisation problem, or in case the NTP Pool monitoring system isn’t currently detecting it.

Happy to provide the full chronyd debug output from the individual tests if that’s useful.

Thanks!

6

The NTP Pool assigns scores to servers based on valid responses plus 1) reachability, and 2) offset. Scoring does not consider the reference time age.

Current chrony considers this server to be a valid source. If your requirements are stricter, perhaps you could use another NTP server, or even configure your own.

By the way, this chart shows 109.74.206.120 offset since the Reference Time got stuck.
This level of detail is not collected by the NTP Pool monitors.

image
image1636×774 9.24 KB

7

In an e-mail exchange not long ago, @mlichvar describes that an NTPv4 client will not leave the synchronized state again once reached, even when its upstream sources aren’t reachable for an extended period of time and metrics such as root distance deteriorate noticeably.

8

Difference client implementations have different (default) limits for the root distance (root delay / 2 + root dispersion), e.g. in ntp/ntpsec it’s 1.5 second, in chrony it’s 3 second, in timesyncd 5 seconds.

I think it would make sense for the pool monitoring system to remove servers with large distance to keep most clients happy with what they get. There needs to be some room for their own peer delay and dispersion. Maybe 1 second would be reasonable.

9

I agree on that, as it makes no sense to let monitors keep scoring all servers.
Maybe the system should be changed to something like this:

Bad scoring monitors are removed from monitoring a server if they consistently score poor/bad then average for that server.

If all servers are gone, can happen, then only best 10 monitors check again, still nothing? Then the NTP-server is removed from DNS-requests and emailed it’s bad.

When good scoring, only the best 5 monitors keep active and 5 in reserve, all the rest isn’t testing your server anymore, unless no monitor can reach you.
It resets (1 or 2 times) after action of the NTP-server that has this problem, still no good scores?

Action requested from the NTP-owner.
Maybe an NTP-Server is ‘back online button’ to confirm it’s still maintained?

Just an idea.

10

Server maintainer here.

Thanks for the messages - this should now be fixed.

This was caused by authselectmode being the default of mix and the configuration only having two NTS capable sources, both of which went offline a few weeks ago (and I didn’t notice).

With authselectmode set to mix, chrony won’t use the non-authenticated sources even if the trusted sources go offline, by design. In hindsight, it was risky only having two NTS sources in this scenario but there are hardly any public stratum 1 NTS capable servers in the UK. I’ve changed it so that there are now 9 NTS capable sources so this shouldn’t reoccur.

11

I don’t get this.
Why only use NTS sources?

I mean, there are plenty trustworthy servers in the pool, that we all know that are proud to keep timekeeping but are not NTS.
Plenty good STR1 sources that are not NTS,

I can do NTS, but I prefer not to do it, as anyone can put up a GPS+PPS and have their own server. I fail to see why you don’t have your own TRUSTED NTP STR1 server that supplies time.

Most of us are in here, supply details, so you can check if they run ok.

I really fail to see why they have to be NTS.

12

chrony will continue to use (and prefer) non-NTS sources with authselectmode set to mix, as long as it has an NTS source to confirm that the time is reliable/reasonable.

The issue is that even with a “trusted stratum 1 server”, without NTS it is vulnerable to MITM attack. I am not saying that this is a likely scenario but it is something that NTS was designed to address. I’m not aware of any downside to enabling and using NTS, as long as you have sufficient, independent NTS sources to avoid the problem described in this thread.

13

Thank you for resolving so quickly.

Lots of comments about why this that and the other which detracts from a community.

Appreciate the quick resolution.