chrony as default NTP client?

[Miroslav Lichvar]

On Wed, May 05, 2010 at 09:21:23PM -0400, Mail Lists wrote:
> On 05/05/2010 09:35 AM, Miroslav Lichvar wrote:
> > 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.
> > 
> 
>  Strong NO vote.
> 
>   Replacing a robust and mature package with an immature one which may
> have security issues (in fact has had recently) should not be taken lightly.

FWIW, ntp recently had a security issue too.

>    The prime motivation of this project is a use case of intermittent
> internet connections of 5 mins a day.

Yes, that was the original motivation when the project was started.
But as it turned out, the employed concepts work very well even with
continuous network connections. I still haven't seen one report where
ntpd would perform better than chrony.

>   I seriously doubt that is the common use case for majority of fedora
> users.

It might be not the most common one, but there surely is a group of
notebook users that connect to internet only few times a day.

>   Aside - I also dont understand the motivation to start again and
> reimplement the wheel all over again ... 

What if it is a wooden wheel and we need something better now that we
have asphalt roads.

The core ntpd algorithms were designed 25 years ago and haven't
changed since then. But typical network conditions did change a lot.
The problem with slow convergence and slow response to temperature
changes is acknowledged by NTP folks. It is discussed regularly in the
ntp newsgroup, but they refuse to do anything about it. I doubt that
the PLL/FLL discipline will ever be replaced.

If you want ntpd to perform well, you will be advised to run it
without restarts, on an idle machine, and in a room with stable
temperature. Probably not something a typical Fedora user has.

You might also find interesting that Linux kernel is not following the
NTP specification and has PLL tweaked to use 4 times shorter time
constant, even though it is strongly discouraged by the NTP author. If
it was following the specification, the time needed to settle down
would increase dramatically.

> and not take advantage of a
> mature product and work to improve ntpd or enhance it.

It's not like no-one has tried. There were many, including myself.

The problem with the NTP project is that the development is closed.
Even the most trivial bugs take a lot of effort to fix. It's possible
to pay them to be a NTP forum member and increase the chances of them
accepting the patches, but that's not what I'd call an open
development.

Also, we are carrying an intrusive (and not very easy to port) patch
that was rejected -- the power saving patch. I have to admit I was
hoping I could drop it one day if chrony was the default client.

-- 
Miroslav Lichvar