Pros & cons of chronyd & ntpd

A friend asked me today: what are the pros and cons of chronyd and ntpd? I've used both for a while, but never actually sat down to think about this question. So here are some initial thoughts:

  • ntpd (the older of the two implementations):
    • has had more time to mature
    • has had more time for the codebase to become more kludgy and less maintainable
    • supports a wider range of hardware
    • supports more different operating systems
    • has more features generally
    • was initially developed in an era where security wasn't as big a concern, so its codebase wasn't designed with security in mind
  • chronyd has almost the opposite benefits and drawbacks:
    • it's a newer implementation (although I'd still call it a mature codebase)
    • it has fewer features (although most people don't need that many features)
    • its hardware and OS support is more limited
    • its code was developed with security in mind
    • I personally find its monitoring output less easy to read - compare the following output:
root@db:~# ntpq -np
      remote           refid      st t when poll reach   delay   offset  jitter
===============================================================================
 ntp.gear.dyndns .POOL.          16 p    -   64    0    0.000    0.000   0.004
+172.22.160.61   172.22.254.53    2 u   46   64    1    0.466   -0.116   0.431
*172.22.254.53   .PPS.            1 u   47   64    1    0.798   -0.097   0.985
+172.22.254.1    172.22.254.53    2 u   46   64    1    1.098   -0.180   0.735
-172.22.254.20   172.22.254.53    2 u   43   64    1    0.618   -0.216   0.062
 172.22.254.2    172.22.254.53    2 u   42   64    1    0.292   -0.278   0.061
root@db:~# tail -n 1 /var/log/ntpstats/peerstats
58582 35057.111 172.22.254.20 1314 -0.000215695 0.000617722 0.187592440 0.000062219

root@maas:~# chronyc -n sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 172.22.254.53                 1  10   377   33m    +36us[ +496us] +/- 1481us
^- 172.22.254.20                 2  10   377    19   +447us[ +447us] +/-   18ms
^- 172.22.254.2                  2  10   377   194   -115us[ -115us] +/- 6183us
^- 172.22.160.61                 2  10   377    90   -726us[ -726us] +/-   28ms

root@maas:~# tail -n 1 /var/log/chrony/measurements.log
2019-04-09 09:42:54 172.22.160.61   N  2 111 111 1111   6  6 0.00  5.516e-04  1.142e-03  1.005e-05  8.240e-04  3.461e-02 AC16FE35 4B D K

I find chrony's switching of units from milliseconds to microseconds (and in some cases nanoseconds) and its floating point formatting in logs difficult to parse visually. However, chrony's excellent security track record means it has been adopted as the default NTP implementation on both Ubuntu and Red Hat. Both implementations claim excellent accuracy, and although I've never compared them empirically, they both seem to deliver on that claim. I tend to use whichever is the default for the distribution I'm working on.

Related posts