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.