# 109.74.206.120 – stale reference timestamp / high root dispersion **URL:** \ **Category:** Server operators\ **Created:** [September 9, 2026, 5:26pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677 "2026-09-09T17:26:41Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![MartinJohnaqluk](https://avatars.discourse-cdn.com/v4/letter/m/f4b2a3/32.png) [@MartinJohnaqluk](https://community.ntppool.org/u/MartinJohnaqluk)\ **Post date:** [September 9, 2026, 5:26pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/1 "2026-09-09T17:26:41Z")
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? ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [September 9, 2026, 5:40pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/2 "2026-09-09T17:40:07Z")
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? ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [September 9, 2026, 6:46pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/3 "2026-09-09T18:46:43Z")
“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](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. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [September 9, 2026, 7:24pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/4 "2026-09-09T19:24:34Z")
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. ---
**Author:** ![MartinJohnaqluk](https://avatars.discourse-cdn.com/v4/letter/m/f4b2a3/32.png) [@MartinJohnaqluk](https://community.ntppool.org/u/MartinJohnaqluk)\ **Post date:** [September 9, 2026, 8:24pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/5 "2026-09-09T20:24:17Z")
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! ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [September 10, 2026, 12:24am UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/6 "2026-09-10T00:24:38Z")
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](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/3/33042ef933e3c0021a2bc4faef682a3b9a287c69.png) ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [September 10, 2026, 8:51am UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/7 "2026-09-10T08:51:56Z")
In an e-mail exchange not long ago, @mlichvar describes that [an NTPv4 client will not leave the synchronized state again once reached](https://www.mail-archive.com/chrony-users@chrony.tuxfamily.org/msg03862.html), even when its upstream sources aren’t reachable for an extended period of time and metrics such as root distance deteriorate noticeably. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [September 10, 2026, 12:25pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/8 "2026-09-10T12:25:52Z")
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. ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [September 10, 2026, 2:39pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/9 "2026-09-10T14:39:31Z")
> [@mlichvar](#): > > 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. 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. ---
**Author:** ![jamie](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/jamie/32/1110_2.png) [@jamie](https://community.ntppool.org/u/jamie)\ **Post date:** [September 10, 2026, 3:32pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/10 "2026-09-10T15:32:49Z")
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. ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [September 10, 2026, 4:03pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/11 "2026-09-10T16:03:20Z")
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. ---
**Author:** ![jamie](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/jamie/32/1110_2.png) [@jamie](https://community.ntppool.org/u/jamie)\ **Post date:** [September 10, 2026, 5:42pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/12 "2026-09-10T17:42:44Z")
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. ---
**Author:** ![MartinJohnaqluk](https://avatars.discourse-cdn.com/v4/letter/m/f4b2a3/32.png) [@MartinJohnaqluk](https://community.ntppool.org/u/MartinJohnaqluk)\ **Post date:** [September 10, 2026, 5:55pm UTC](https://community.ntppool.org/t/109-74-206-120-stale-reference-timestamp-high-root-dispersion/4677/13 "2026-09-10T17:55:59Z")
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.