Chrony: Comparison of NTP implementations(chrony.tuxfamily.org)
chrony.tuxfamily.org
Chrony: Comparison of NTP implementations
https://chrony.tuxfamily.org/comparison.html
52 comments
> the Network Time Foundation were funding 1 day a week of
> his time, but that was just weekend work, he's a busy guy
ntime is almost great as a client, but it's so minimal it doesn't have enough necessary features and it's unlikely to be anywhere as accurate as chrony or ntpd. openntpd falls in the same boat. The issue of ntpd was/is security and possibly excessive configuration.
> Reference clocks
Just saying "Yes" here is highly misleading. NTP supports dozens of reference clocks, including the protocols of may precision timing receivers. Last I looked chrony supported only a single kind of reference clock.
Just saying "Yes" here is highly misleading. NTP supports dozens of reference clocks, including the protocols of may precision timing receivers. Last I looked chrony supported only a single kind of reference clock.
> Just saying "Yes" here is highly misleading.
FWIW, the page also compares the number of reference clock drivers. chrony does not have any HW-specific drivers, but there is an interface which other programs can use to provide the timing data. The most commonly used reference clocks these days are GPS receivers, which are well supported by gpsd.
FWIW, the page also compares the number of reference clock drivers. chrony does not have any HW-specific drivers, but there is an interface which other programs can use to provide the timing data. The most commonly used reference clocks these days are GPS receivers, which are well supported by gpsd.
chrony seems great from this comparison and I remember using it in the past and being pleasently surprised at how good it was with laptops. These tests show the same. Anyone know why it hasn't become the default on Linux?
It is the default for redhat and fedora.
chrony seems great because this comparison is on the chrony website.
Then prove them wrong instead. Just because it's on their website doesn't mean it's misleading or incorrect.
Or, perhaps, simply treat it with due skepticism.
Sorry, but this is just flabby thinking. We know it takes 10 times as long to refute bullshit as to create it. No-one needs to spend their lives proving wrong every slated comparison on every website.
On the other hand, just calling bullshit because an open source project did a comparison page is a bit much. The incentive to lie isn't particularly high and doing a good comparison has the utility of letting you know what you still need to work on. So unless you have at least one example of how the page is wrong just calling bullshit by default seems uncalled for.
I can't speak for chrony but considering the amount of security issues with ntpd I would much rather run openntpd.
They don't do the same thing. At least last time I looked at it, openntpd was more like a SNTP client than a NTP client.
That means it's more suitable for following a reference clock, not keeping a number of machines in sync with each other and the rest of the world. Unless they have implemented more of the protocol now. This has security implications of its own.
That means it's more suitable for following a reference clock, not keeping a number of machines in sync with each other and the rest of the world. Unless they have implemented more of the protocol now. This has security implications of its own.
I'm running OpenNTPD on all my devices (laptops, servers, VMs) and as far as I can tell they are in sync. Both amongsts themselves, as well as with other devices that are running other NTP implementations.
I've heard other people claiming that OpenNTPD is not accurate enough and what not, but my anecdata says it performs well enough. Do you happen to have any specific gripes with it ? Is it the timekeeping algorithm that is lacking ?
Sibling comment mentioned leap seconds, and that's unlikely to change. AFAIK, for 'proper' leap second support, the daemon must support it (to parse the announcement from the upstream NTP) as well as the OS. Gathering from I've read on OpenBSD's mailing lists, leap second support in the kernel is not a priority -- to say the least. Seeing the fallout on other OSes, I'd say it's a sound decision. On a similar note, Google introduced leap smearing to not deal with introducing leap seconds across all of its' servers[1]. Several other actors, such as Amazon[2] and Akamai followed suite.
[1] https://googleblog.blogspot.fr/2011/09/time-technology-and-l... [2] https://aws.amazon.com/blogs/aws/look-before-you-leap-the-co... [3] https://blogs.akamai.com/2016/11/planning-for-the-end-of-201...
I've heard other people claiming that OpenNTPD is not accurate enough and what not, but my anecdata says it performs well enough. Do you happen to have any specific gripes with it ? Is it the timekeeping algorithm that is lacking ?
Sibling comment mentioned leap seconds, and that's unlikely to change. AFAIK, for 'proper' leap second support, the daemon must support it (to parse the announcement from the upstream NTP) as well as the OS. Gathering from I've read on OpenBSD's mailing lists, leap second support in the kernel is not a priority -- to say the least. Seeing the fallout on other OSes, I'd say it's a sound decision. On a similar note, Google introduced leap smearing to not deal with introducing leap seconds across all of its' servers[1]. Several other actors, such as Amazon[2] and Akamai followed suite.
[1] https://googleblog.blogspot.fr/2011/09/time-technology-and-l... [2] https://aws.amazon.com/blogs/aws/look-before-you-leap-the-co... [3] https://blogs.akamai.com/2016/11/planning-for-the-end-of-201...
IIRC (possibly outdated info) OpenNTPd lacked support for Linux and other platform PLL syscalls, just used the standard (and less precise) adjtime syscall.
Exactly. openntpd isn't very precise and doesn't have many necessary features for running in production as a local NTP stratum source.
If chrony had an MIT license, it has the potential to be more awesome. ntpd's configuration is its attack and misconfiguration surface. There's no one "perfect" ntp client/server, they have their strengths and weaknesses.
I miss systemd-timesyncd in that list... is it actually the default on modern Linux distros?
From https://wiki.archlinux.org/index.php/systemd-timesyncd :
> In contrast to NTP implementations such as chrony or the NTP reference server [systemd-timesyncd] only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it.
> In contrast to NTP implementations such as chrony or the NTP reference server [systemd-timesyncd] only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it.
How does any average users and admins want NTP server feature on their machine?
It just sounds like running a more complicated (meaning, more attack vectors) software for no reason.
It just sounds like running a more complicated (meaning, more attack vectors) software for no reason.
Systemd-timesyncd uses SNTP. SNTP is designed for desktop or embedded systems for a reason. It's more a convenience of not having to set your clock, or not having much resources.
Accuracy: 100ms, no clock slewing. Try to correlate your logs with that, or run any distributed applications. https://unix.stackexchange.com/questions/305643/ntpd-vs-syst... https://github.com/coreos/bugs/issues/391
Talking about attack vectors: SNTP has no no authentication, so you can practically set the clock on a server, if you have sufficient network access.
That's fine for me on my laptop, but I don't see much point favouring well established solutions for saving a couple of MB RAM on a server.
Accuracy: 100ms, no clock slewing. Try to correlate your logs with that, or run any distributed applications. https://unix.stackexchange.com/questions/305643/ntpd-vs-syst... https://github.com/coreos/bugs/issues/391
Talking about attack vectors: SNTP has no no authentication, so you can practically set the clock on a server, if you have sufficient network access.
That's fine for me on my laptop, but I don't see much point favouring well established solutions for saving a couple of MB RAM on a server.
> How does any average users and admins want NTP server feature on their machine?
To run one internal NTP reference that synchronizes to one or more external sources, with all other internal machines syncing with that one internal reference.
Or, to hook an external hardware time clock up to one machine, then have the other internal local machines sync with that one machine that has an external hardware time clock.
However, depending upon how one defines "average" user/admin will determine if either of the two above are things that such a user/admin might find useful.
To run one internal NTP reference that synchronizes to one or more external sources, with all other internal machines syncing with that one internal reference.
Or, to hook an external hardware time clock up to one machine, then have the other internal local machines sync with that one machine that has an external hardware time clock.
However, depending upon how one defines "average" user/admin will determine if either of the two above are things that such a user/admin might find useful.
Reference NTP server is less complicated than entangled steaming pile of "let's
not" that is systemd. I trust the reference implementation more than I trust
the team behind systemd with regard to network communication.
Why is this is getting downvoted?
systemd has a horrible security track record and should not be allowed on any server that is connected to the internet.
The last remote-root exploit from 2 months ago: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn...
The major distros urgently need to get rid of systemd and return to proven, modular init systems.
systemd was the biggest single mistake in UNIX history.
systemd has a horrible security track record and should not be allowed on any server that is connected to the internet.
The last remote-root exploit from 2 months ago: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn...
The major distros urgently need to get rid of systemd and return to proven, modular init systems.
systemd was the biggest single mistake in UNIX history.
I hate the binary logs of journald, the unnecessary complexity of stuff like systemd-hostnamed, dbus and the ignore-invalid-options policy but the init system it's actually very good.
I don't want to return to a pile bash scripts with `sleep n` to get the system to boot, even if it's a proven method.
I don't want to return to a pile bash scripts with `sleep n` to get the system to boot, even if it's a proven method.
This "pile bash scripts with sleep n" was at least debuggable and could be
inspected and traced in different ways. With systemd, when something doesn't
work as expected (which is often when you do anything that deviates even
a little from standard), tough luck.
The sad part is that much of the "standard" is not really standard, but what systemd thinks is "standard".
Or that they cling to "standard on paper" rather than "standard in use", and thus end up rolling back decades of real life usage in the process.
With systemd, perfect very much is the enemy of good. And both unix and Linux go where it is not by being perfect but by being good.
Or that they cling to "standard on paper" rather than "standard in use", and thus end up rolling back decades of real life usage in the process.
With systemd, perfect very much is the enemy of good. And both unix and Linux go where it is not by being perfect but by being good.
> The sad part is that much of the "standard" is not really standard, but what systemd thinks is "standard".
I didn't mean "standard" as in "POSIX 1003.1e", "SUSv3", or "RFC 3549", I meant it as in "whatever is currently most widely in use". Which actually reinforces your point.
I didn't mean "standard" as in "POSIX 1003.1e", "SUSv3", or "RFC 3549", I meant it as in "whatever is currently most widely in use". Which actually reinforces your point.
Many other dependency/supervisor driven init systems exist (upstart, minit, daemontools, etc.). Upstart even was the Ubuntu default for a while.
One of them should be adopted and fleshed out before systemd causes even more damage.
One of them should be adopted and fleshed out before systemd causes even more damage.
Try OpenRC, really, give it a try.
Simple, sane bash-like scripts, logging like you're used to and so easy to debug, and when you need to do your own custom stuff, simple and just works.
Gentoo showed me this tool a few years ago. So happy.
For years now I've heard loud stories about systemd +1 or -1. Same arguments over and over.
Meanwhile, dozens of my servers and desktops and laptops keep humming along, I've like just never had to fuck with it.
I should buy the OpenRC team some pizza. Thank you!
Simple, sane bash-like scripts, logging like you're used to and so easy to debug, and when you need to do your own custom stuff, simple and just works.
Gentoo showed me this tool a few years ago. So happy.
For years now I've heard loud stories about systemd +1 or -1. Same arguments over and over.
Meanwhile, dozens of my servers and desktops and laptops keep humming along, I've like just never had to fuck with it.
I should buy the OpenRC team some pizza. Thank you!
> Reference NTP server is less complicated than [systemd-timesyncd].
Reference ntpd source: ~130 kloc
systemd timesyncd source: ~2 kloc
Reference ntpd binary: ~700 KB
systemd timesyncd binary: ~38 KB
I get that you don't like systemd, or trust that team. But it's hard to say that ntpd is less complicated than timesyncd with a straight face. Maybe it is better engineered, more correct, more secure, or something; but not less complicated.
Reference ntpd source: ~130 kloc
systemd timesyncd source: ~2 kloc
Reference ntpd binary: ~700 KB
systemd timesyncd binary: ~38 KB
I get that you don't like systemd, or trust that team. But it's hard to say that ntpd is less complicated than timesyncd with a straight face. Maybe it is better engineered, more correct, more secure, or something; but not less complicated.
Well, to configure ntpd as a basic client, the general workflow is the natural workflow of any daemon launched by init.
1) Install the package
2) Modify the configuration file if needed
3) Enable the service
Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file.
For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd.
As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.
1) Install the package
2) Modify the configuration file if needed
3) Enable the service
Taken alone timesyncd can be considered simpler to configure (no package to install, short configuration file), but it follows its own workflow, specially the command to enable or disable it (timedatectl set-ntp true), and to a lesser extent the location of its configuration file.
For me it makes it harder to configure because, now, I must remember precisely all the steps where I could only remember a loss pattern, common with all other services, for ntpd.
As itself, it's not that bad, it's a few commands, I can remember them, but it would definitely suck if every single service had its own pattern.
You can do everything the common pattern way with timesyncd as well.
1) Install the package (it's probably part of the systemd package you already have)
2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf)
3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service)
Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.
1) Install the package (it's probably part of the systemd package you already have)
2) Modify the configuration file if needed (/etc/systemd/timesyncd.conf)
3) Enable the service (`systemctl enable systemd-timesyncd`; the same as any other service)
Sure, you can use timedatectl to enable it (which makes a D-Bus call to timedated, which then makes the same call that `systemctl enable --now` does). But you don't have to. It's a weird feature of timedated/timedatectl because they try to be the Swiss-army-knife of messing with time settings on the box.
Very interesting to see. I'm a big fan of (X)NTP and introduced it to several clients many moons ago, and still have code lurking in it AFAIK. But I was not happy with the maintainers seeming to lose whole versions of (my) code and have not run a real local ticker for a while. I still have plenty of users of ntp.exnet.com anyway!
I've used htpdate for the times ntp has been blocked by firewalls. It's worked fine for me without hiccups.
This link resurfaced again after getting a mention in cron.weekly issue #99; https://www.cronweekly.com/issue-99/
Gotta say, I'm happy about that, as I wrote the newsletter :-D
Gotta say, I'm happy about that, as I wrote the newsletter :-D
It took an embarrassedly long amount of time for me to notice this was on chrony website. Might be better described as 'things chroney has, it's competitors don't have and may or may not be important.'
This managed to put most of its content off-screen on Android, without letting me resize the viewport at all. Completely unreadable.
I miss the days when people would use tables and minimal or no css.
I miss the days when people would use tables and minimal or no css.
Those days site would come with a "best viewed in IE at 800x600" disclaimer because they would be completely unusable in any other configuration.
Maybe you miss the days of simple text as HTML. That one did work everywhere.
Maybe you miss the days of simple text as HTML. That one did work everywhere.
Requesting the desktop version in Chrome fixes this. But yes, absolutely terrible mobile experience.
Blocking resize is the real crime, I don't understand why you would do that.
Tables are pretty much the worst thing to use if you want it to look right on mobile.
Seems like a great candidate for a Rust implementation, but I can't seem to find one yet..
Thread carefully, because most NTP vulnerabilities are protocol misuse, not badly written servers. Thus Rust won't protect against them.
There are two NTP parsers already if you want to get started: https://crates.io/search?q=ntp
...latest on it appears to be that Poul-Henning Kamp is building a house and that's taken up the time that was devoted to it, for now https://twitter.com/bsdphk/status/886166233783119873
(the Network Time Foundation were funding 1 day a week of his time, but that was just weekend work, he's a busy guy)