# What makes an NTP server a good server, when is it 'good enough'? **URL:** \ **Category:** Uncategorized\ **Created:** [November 14, 2024, 8:44am UTC](https://community.ntppool.org/t/what-makes-an-ntp-server-a-good-server-when-is-it-good-enough/3604 "2024-11-14T08:44:39Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![n1zyy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/n1zyy/32/338_2.png) [@n1zyy](https://community.ntppool.org/u/n1zyy)\ **Post date:** [November 24, 2024, 12:59am UTC](https://community.ntppool.org/t/what-makes-an-ntp-server-a-good-server-when-is-it-good-enough/3604/10 "2024-11-24T00:59:58Z")
> [@marco.davids](#): > > Is there anything definitive we can say about this? Can we really make any meaningful claims about the accuracy of public NTP servers? In another thread @stevesommars linked to an interesting paper of his that explored some aspects of long-term monitoring: > [@Asymmetric latency measurement tool](https://community.ntppool.org/t/asymmetric-latency-measurement-tool/3336/8): > > I’ve done extensive measurements using standard NTP. See [Multiple Network Paths](http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf) in my PTTI paper. Some comments: If the NTP server or NTP client have local times that differ significantly (milliseconds or larger) the calculated asymmetry will be incorrect. This risk also exists with the custom UDP described in this thread. The unidirectional delay may depend on which UDP ports are used. I monitor NTP using multiple UDP client ports. NTP server implementations can have weird bugs.… One thing I recall noticing is that occasionally some servers gave _very_ incorrect time, off by years. But I feel like you could, with enough data, probably make a statement like, “The 90th-percentile accuracy of pool servers was within 250ms” or something. (To be clear, that statistic is a completely made-up example.) I wonder if the pool monitoring data used for graphs could give some answers here? Dave’s comment about root dispersion as a reasonable benchmark, and my side project to get all the stuff I manage into Ansible, led me to grab this data: ```auto % ansible all -m ansible.builtin.shell -a "sudo chronyc tracking | grep dispersion" nyc-2g | CHANGED | rc=0 >> Root dispersion : 0.004316320 seconds mia-2g | CHANGED | rc=0 >> Root dispersion : 0.001929239 seconds las-2g | CHANGED | rc=0 >> Root dispersion : 0.001757243 seconds lux-2g | CHANGED | rc=0 >> Root dispersion : 0.000888808 seconds mumbai-1g | CHANGED | rc=0 >> Root dispersion : 0.001670093 seconds korea-1g | CHANGED | rc=0 >> Root dispersion : 0.000842893 seconds singapore-ls | CHANGED | rc=0 >> Root dispersion : 0.000610336 seconds capetown | CHANGED | rc=0 >> Root dispersion : 0.001687264 seconds malaysia-ptp | CHANGED | rc=0 >> Root dispersion : 0.000001237 seconds sao-paulo | CHANGED | rc=0 >> Root dispersion : 0.001140296 seconds bangalore-do | CHANGED | rc=0 >> Root dispersion : 0.002006466 seconds singapore-do | CHANGED | rc=0 >> Root dispersion : 0.001366011 seconds ``` With the exception of `malaysia-ptp`, these are all stratum 2+ servers getting time over the Internet. At the same time, they’re all VMs inside data centers where I’ve taken some care to configure them with several good, nearby NTP sources. Someone using wifi on a laptop through their cable modem would probably have worse numbers. --- _[View the full topic](https://community.ntppool.org/t/what-makes-an-ntp-server-a-good-server-when-is-it-good-enough/3604)._