# Suggestions for the offset threshold for pool server

**URL:** <https://community.ntppool.org/t/suggestions-for-the-offset-threshold-for-pool-server/3716>\
**Category:** Pool Development\
**Tags:** monitoring\
**Created:** [December 31, 2024, 2:32pm UTC](https://community.ntppool.org/t/suggestions-for-the-offset-threshold-for-pool-server/3716 "2024-12-31T14:32:30Z")\
**Posts on this page:** 1\
**Page:** 2

<div class="post-metadata">

**Author:** ![Sebhoster](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@Sebhoster](https://community.ntppool.org/u/Sebhoster)\
**Post date:** [April 6, 2025, 10:44pm UTC](https://community.ntppool.org/t/suggestions-for-the-offset-threshold-for-pool-server/3716/21 "2025-04-06T22:44:25Z")

</div>

I’m picking this thread back up since the consensus seems to be in favor of a lower offset threshold, but no conclusion has been reached.

> [@mnordhoff](#):
>
> What’s a reasonable worst-case scenario? What if, for example, a small country with some NTP servers and no monitors has a bad fiber cut and their international connectivity gets congested or is routed strangely?

Planning for internet congestion or outage of an entire country feels out of scope to me. The problems of a complete outage would be the same regardless of how high or low the offset threshold is chosen. If the country only has an unstable or congested link to the wider internet, lost packets would still impact the scoring the same way they do now. The only change occurs when the routing or congestion results in asymmetric packet travel times. But even then it only becomes a problem if the asymmetries become bad enough to induce more than 50ms of error.  
In any of those cases, the monitoring system can not really tell what is going on the inside of the affected network. But the decision that it makes is not only relevant for clients inside the area, but also for clients outside. So dropping the servers seems like the right decision to me for the current architecture of the pool.

> [@mnordhoff](#):
>
> - Maximum offset is 25 ms if latency is \<= 25 ms
> - Maximum offset == latency if latency is 25-100 ms
> - Maximum offset is 100 ms if latency is \> 100 ms

I think the goal here should not be to check if the server could be synchronized to a correct clock and only is behind a bad network, but to check if the server is able to be used as a reliable and precise time source. A server that my (synchronized) client sees with 100ms latency and 80ms offset might be working correctly, but is still not a good time source for my client. So I don’t think we should consider the latency.

> [@matuskral](#):
>
> if we have (or could have) the confidence areas calculated realtime, then the offset would define itself as the current 95/98.

Continously applying a relative threshold would over time delete the pool. We would measure - then drop 2-5% of the servers - then measure again, now the threshhold is 95% of the remaining server measurements - again, drop the worst 2-5% - if we repeat this often enough we slowly but surely decrease the pool size until only a handful of servers remain.

[Previous page](https://community.ntppool.org/t/suggestions-for-the-offset-threshold-for-pool-server/3716.md?page=1)