The Configuration recommendations for servers joining the pool say, “if you are going to join the pool we recommend you use ntpd.” Is this recommendation still valid? I’m considering adding some servers to the pool, but they’re running chrony and if the pool would prefer not to have chrony servers then obviously I shouldn’t.
Personal opinion, I do not represent the NTP Pool:
I forgot about that text and I run Chrony servers in the Pool. 
I suspect that was written a long time ago, at a time when perhaps the NTP reference implementation was the only solid and popular server, and it should probably be changed.
There might be especially buggy and problematic implementations, but Chrony is fine.
3 Likes
to @mnordhoff’s comment - I run one ntpd and one chronyd instance (with probably more to come in the near future) and they seem to perform roughly the same. Upstream bandwidth and congestion seems to affect the pool score far more than the NTP implementation.
1 Like
That recommendation was written long time ago and it definitely needs an update. Some major Linux distributions replaced ntp with ntpsec, so that should be mentioned too.
FWIW, in my monitoring of the pool servers the most used implementations (counting IP addresses) are currently:
- ntp - 56%
- chrony - 24%
- ntpsec - 9%
- openntpd - 2%
As for the amount of handled NTP traffic, the biggest share probably has Cloudflare with their anycast addresses included in every pool zone. They run chrony with cfnts as a proxy, so I think most of the pool’s time service is provided by chrony, despite the pool’s recommendation.
6 Likes
Openntpd was known for ignoring leap second flag and causing disruptions. So unless leap second is completely retired (in 2035), we shall against openntpd’s adoption in the pool.
1 Like
Somewhat related: A number of pool servers use google and other smeared leap-second sources.
This caused errors at the previous leap second.
3 Likes
Out of curiosity, is your method of distinguishing between the implementations documented or code published?
No, I did not publish that. It’s not that difficult. It looks for differences in handling of unknown extension fields and MACs (RFC 7822), old and future NTP versions, the poll field, changes in the reference timestamp, difference between TX and RX timestamp (indicating a SW or HW implementation), etc. The biggest problem is with overloaded servers and networks. A missing response needs to be tested multiple times to get more reliable results.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.