chrony as default NTP client?
mlichvar at redhat.com
Mon May 10 09:56:31 UTC 2010
On Sun, May 09, 2010 at 11:45:49AM -0600, Stephen John Smoogen wrote:
> On Wed, May 5, 2010 at 7:35 AM, Miroslav Lichvar <mlichvar at redhat.com> 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.
> Hi Miroslav,
> lets go over a couple of things to help lower the grumpiness of others.
> 1) Who are you?
> 2) What is your position in regards to knowing ntpd and/or chrony in
> stability and other things?
I'm the maintainer of the ntp and chrony packages, for 4 and 1.5 years
respectively. I'm also an upstream maintainer of chrony and I'm
familiar with internal designs of both applications.
> I think most people do not know who maintains ntpd, and do not know if
> this is a "Oh wow I just found this really great software program and
> we should change to it right away!!!!" kind of email.
Well, that's exactly what I thought when I first discovered chrony :).
> > 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.
> Ok time is one of those touchstone security tools that people get all
> kinds of crazy about when things get changed. Here are a couple of
> questions that might help:
> 1) Why chrony? Why not OpenNTPD [fill in the blank here]
I think the most important chrony features are covered in the original
OpenNTPD is not able to compensate for drift, i.e. it's not much
better than running ntpdate from cron.
Currently, the only other NTP client I know that might have enough
features and good perfomance to be considered as a default client (if
it worked on Linux) is dntpd from DragonFly BSD.
> 2) Where is the data that chrony actually controls the clock better?
One comparison is here:
An old test I did with a GPS reference clock (this may better
demonstrate clock control abilities):
> 3) How far have you/others tested it in comparison with ntpd?
I'm using chrony on most of my machines, some of them are running
24x7, some are rebooted/suspended daily, quality of the network
connection varies from wireless to fiber.
> 4) A release plan should probably look like the following:
> Fedora-14 we add chrony into alternatives or other commands needed to
> get it to work. System-config-date has pathways to configure one or
> the other when it is seen. Test days and reviews are done to see how
> it is going. Organize a short-term sig and get Mo to make a design for
> shirts (melting clocks sounds a good idea). People who test, find
> bugs, etc etc qualify for a drawing of stuff.
> Fedora-15 from feedback we have gotten on chrony, we go through the
> plan of making chrony default (or not) and make ntpd optional.
> This is one alternative plan ( a bit slow but for security related
> things probably better.). To speed it up we need to move get people
> motivated towards 12/13 testing and feedback.
If anyone wants to help with testing now
- enable "statistics loopstats peerstats" in ntp.conf and
"log measurements tracking" in chrony.conf
- run each for few days or weeks in your typical workload and network
- send me the logs from /var/log/ntpstats and /var/log/chrony
Or you can make your own analysis. The most important value is the
offset reported in the 3rd field in loopstats and the last field in
tracking.log. With gnuplot you can compare them (after concatenating
the rotated logs):
plot "tracking.log" using 7 with lines, "loopstats" using 3 with lines
More information about the devel