How to decide if a pool server is “Good Enough” to be in the pool - A simple question to ask but I am not sure it is a simple question to answer.
Should “Good Enough” be only based on the monitoring system results. If the monitoring system is happy (not removing the server) then should I conclude that the server is rated good enough or is there some other measurable metric that could be used to help decide. Not saying the monitoring system is in any way broken but just trying to decide what can/should be used to decide if a server is good enough.
On and off over the last few years I have been running a system that monitors the pool quality by testing the time provided by some of the pool servers. Basically from a number of locations around the world do DNS queries to 2.pool.ntp.org and 2..pool.ntp.org and checking the responses received. Similar to the monitoring system but coming from a slightly different point of view.
Recently for example my testing is seeing a server that has had a score between 10 ~ 12 for the last few weeks. It does not seem to climb higher because the clock offset is quite often high (about 80ms) but because the pool score is above 10 the ip address is still being provided to users. Raised the question - what is good enough to be in the pool and if I find something like this then what is the best way to let the pool and/or person managing the server know that there may be an issue.
One criteria is if the server is reachable enough. Currently the monitoring system is happy if there are at least a few monitoring nodes that can reach the server, even if it is unreachable from most other places.
In one extreme case one server’s score was a solid 20, even if it was reachable only from usmci1-3strqkc. This server has since been deleted.
Some “big car company’s NTP servers” in the Philippines (222.127.1.18 - .27) are reachable only from at most a dozen monitoring nodes. Their official scores tend to be close to 20. My own NTP server in the Philippines can’t reach them. Maybe they’re only available to Globe networks (as that’s where they’re hosted) and a handful of others. Write your possible followups regarding this Philippine case to the linked thread, thanks.
May we have the IP of the offending server with this high offset? In general, the acceptable level of offset to be part of the active pool is coded in the scoring algorithm.
} else if *offsetAbs > 25*time.Millisecond {
offsetSecs := offsetAbs.Seconds()
if offsetSecs <= 0.100 { // 25ms - 100ms range
step = -6.667*offsetSecs + 1.167
} else { // 100ms - 750ms range
step = -2.308*offsetSecs + 0.731
}
// Sanity check: never exceed +1
if step > 1 {
step = 1
}
} else {
If I plug some figures into that I get
For a clock offset of 87ms -> step = -6.667*0.085 + 1.167 = 0.600305
For a clock offset of 145ms -> step = -2.308*0.145 + 0.731 = 0.39634
For a clock offset of 316ms -> step = -2.308*0.316 + 0.731 = 0.001672
For a clock offset of 317ms -> step = -2.308*0.317 + 0.731 = -0.000636
If I am correct that suggests that an offset below 317 will return a positive step which will increase the server socre. 317 and above will start to reduce the pool score but only slowly.
From my independent monitoring clients:
The server had error of 400+ seconds on 2026-08-15 01:11 and on 2026-08-20 07:15:.
The server reports stratum 3, but does not specify a reference ID.
The root delay is high, over 200 msec. Perhaps a closer upstream source could be used.
You do know that pool servers are not atomic-clocks, but systems that provide pretty accurate time for almost all systems in the world that need good time.
As I remember correctly the goal of the pool is to set time accurate to 0.01sec, often better then that.
Typical this is accurate enough to do enough for most things.
If not, the institutions buy an atomic-clock themselves to have better numbers.
I’m sorry, but I do not understand your problem.
When server is off a lot it will be taken out of the pool.
As others asked too, what server is this? So we can verify your claim.
As typical you won’t get bad servers that give wrong time, but there are limits.
This smells to me like the server is struggling under load. I have a couple of servers in the pool in underserved regions that are doing thousands of requests per second, and I had forgotten to disable ip_conntrack on one of them. The table would fill up and drop connections, so monitoring would take it out of the pool, and the table would drain and it’d come back in.
I hadn’t read the scoring code before, but I agree with your reading: 0.731 / 2.308 = 0.3167… seconds seems to be the point where step = 0. That’s higher than I would have thought, but I guess it’s the answer for what’s considered “Good Enough.”
More generally, there was a pretty similar discussion a while back:
For my own servers, I usually configure the list of servers by hand and expect offsets to be on the order of a couple milliseconds or less, but they’re generally running in well-connected data centers, or my home LAN where I’ve ended up with a growing collection of GNSS-locked stratum 1s. I assume some pool clients are things like a low-power device connected through an intermittent cellular connection which will limit how close they could get.
This is a “For the record”, “For the benefit of the tape” type post that may be useful to reference in the future when discussing what servers are “Good Enough”.
It started out at a score of 20 which has slowly fallen to 10.1. If it were active it would be serving time to users. The score has been sitting just above 10 for the last few days and does not look like it will fall below 10 so I guess it is still considered good enough.
I am about to swing the forced offset to 100 mSec in the other direction to see what the pool monitors do and may post more “For the record” posts in future.