chrony as default NTP client?

[Miroslav Lichvar]

With the latest improvements in the chrony package related to
NetworkManager and name resolving I think it is now good enough to
replace ntpd in the default configuration and the configurations
supported by system-config-date.

I'm proposing to add a support for chrony to system-config-date and
change the dependency. As chrony supports only a subset of the NTP
protocol and misses many of the ntpd features, users will have to
install the ntp package manually if they have a specific requirement
or need to use a more complicated configuration.

The reasons why I think chrony might be a better choice for default
installation:

Ntpd seems to be primarily designed for server environments, it
doesn't work very well when restarted frequently, because it needs a
lot of time to settle down. This is further worsened when tsc is used
as the system clocksource. Due to unstable kernel calibration the
clock drift may change between reboots by hundreds of ppm and ntpd
will need about 10 hours to settle down, while chrony needs only 10
minutes.

Even when everything has settled down, chrony is usually able to
control the clock 2-3 times better than ntpd. In some situations
the difference is even greater. 

Chrony doesn't step the system clock unless configured to do so. Our
default config allows stepping in first three clock updates and only
if the error is larger than 30 seconds. OTOH, ntpd will step the clock
whenever the assumed error is larger than 128 ms. It can be configured
to not do that, but this will disable kernel discipline which may
negatively affect the timekeeping performance and power saving as the
daemon will have to wake up every second.

Chrony has a smaller memory footprint.

I'd say the only major drawback is that chrony is not as widely tested
as ntpd and there could be serious bugs hidden. Although the project
is now over 12 years old, the user base seems to be very small.

What do you think?

-- 
Miroslav Lichvar