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.