Chrony, NTPsec, NTP(ntpd)…
Which one should I use?
I’ve used all tree of them over the years and i’ve had mostly no problem, but I mostly use Chrony for no specific reasons.
From my understanding:
- Chrony uses additional advanced algorithms to compensate for less than ideal consitions, such as network conditions and running under a hypervisor
- NTPsec is modified NTP classic, but with a minimalist approach, trimming away the fat as far as features go, making development simpler
- NTPd/NTP classic is the original, fully featured one
I don’t think it matters much which one you use for the pool, as they’ll all do a great job, but I believe you can get a tiny bit more accuracy out of Chrony. But I’ve only recently gotten into all of this NTP stuff, so if someone with more experience and insight disagrees, you should probably listen to them instead 
3 Likes
Thanks a lot. I saw on the main NTP pool website that they recommend using ntp.d (classic legacy NTP).
I tried to install NTP.d on Debian 12, but it seems that they replaced it with NTPsec by default in Debian12.
Think I saw a comment in a config file somewhere to volunteer to the pool in November, a little over a month ago. Then I did exactly this, seeing that NTPd was the recommended one due to being the most widespread and well known, so if you run into trouble, people will be able to help you. But, from reading the forum here, I get the impression that most people here are using Chrony.
I interpret it to mean you should use something proven and well known.
Updating the website would be appropriate! Maybe adding ntpd-rs, too?
Any of those implementations are appropriate. The more diversity in what people use the better, I’d think.
4 Likes
I was using ntpd for years, since it came with debian by default.
Debian 12 switched to ntpsec which seemed to use more resources than old ntpd, so i switched to chrony like a half a year ago.
No relevant differentes encountered so far.
The only issue I ran into is that chrony unlike ntpd returns garbage on error (which seems to be ok according to the rfc) which the ntppool-server-tracking page still handles, so sometimes the graph shrinks since it shows a red dot with like a 2000 ms delay or something like that.
Do you have an example of those errors?
I faintly remember that the reason why I was looking at the logs in the first place at the time I found holes in the CSV log was due to seeing and wanting to understand a “graph shrinkage” effect in connection with exceptional conditions with my chrony instance. Due to the issue with the holes, and since it was a rare occurrence only, I did not pursue the investigation.
So I hope that @someone has a more current example.
I dont. Sorry.
Last time I investigated it was in like July 2023 (?), found that its not really an issue with my systems (except that chrony doesnt behave 100% equally to ntpd/ntpsec, but still correctly) and moved on.
@ask, not specific to chronyd, but here another occurrence of “graph shrinkage”:
In this case, the shrinkage seems caused by trying to graph offset values that can be assumed to be invalid/nonsense based on the INIT kiss code and the leap indicator value of 3. The CSV log does not show the stratum, would be interesting to see what value it had in this case (I would expect it to have been 0).
Apart from the effect on the graph, the INIT kiss code as well as probably at least the similar STEP kiss code are errors that come to mind with respect to the question how to score “errors […] that have a response but aren’t RATE”, RSTR, or DENY. Others, e.g., related to failures in security mechanisms the polled server expects, could be worthwhile to consider as well.
EDIT: I faintly remembered this had been raised before, but initially did not find it. But here it is.
2 Likes
It may use more electricity than Chrony, though, if that is a greater concern.
I prefer Chrony, which is flexible, lightweight, and intelligent, chrony complete victory.
Hi there!
I have experience in large-scale environments with both NTPd and Chrony.
My experience is night-and-day: chrony is robust, converges quickly, and fixes most ntpd issues we faced in ideal and less-ideal environments alike. A look at ntpsec client tool improvements (Differences from NTP Classic) and it seems that these hard-to-track bugs were not the fruit of my imagination, so ntpsec might offer the same benefit. Also, the offset was at least 1 order of magnitude better than ntpd (say, 150us versus 1 to 5ms, depending on the “location” of the client, topology-wise) for the very same clients after the switch over to chrony.
[Advanced use for latency-sensitive workloads] One limit of chrony is that it does (at least did) not offer similar APIs to allow an external PTP client to steer the clock ; we were using an external PTP client that would take or give control of the clock to ntpd in degraded mode. Now, there is nothing wrong to use chrony ptp client or ptp2. Just be sure to very cleanly perform trials and deploy progressively, with third parties (say app owners) enlightened awareness.
Note on this last part (regarding: open source): the fact that an open source tool is missing APIs that an external vendor-driven client needs to integrate with it … this is why the vendor might want to get involved to the project. As a customer, I value when medium companies take the initiative to contribute to open source in their area.