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?
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.
The prime motivation of this project is a use case of intermittent internet connections of 5 mins a day.
I seriously doubt that is the common use case for majority of fedora users.
I think this is a terrible idea.
gene/
PS: Aside - I also dont understand the motivation to start again and reimplement the wheel all over again ... and not take advantage of a mature product and work to improve ntpd or enhance it.
Mail Lists lists@sapience.com writes:
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.
I think this is a terrible idea.
Yes. I certainly wouldn't use it, and especially object to the proposed strong-arm tactics of eliminating all configuration support for ntpd. The case for making chrony default is weak enough, and the case for throwing roadblocks in the way of people who prefer ntpd is nonexistent.
regards, tom lane
On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote:
Mail Lists lists@sapience.com writes:
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.
I think this is a terrible idea.
Yes. I certainly wouldn't use it, and especially object to the proposed strong-arm tactics of eliminating all configuration support for ntpd. The case for making chrony default is weak enough, and the case for throwing roadblocks in the way of people who prefer ntpd is nonexistent.
I'm not suggesting to remove the ntp support from s-c-d, just to add a support for chrony and change the dependency to a name provided by both packages and marking chrony as default in the comps.
On Thursday 06 May 2010 13:10:36 Miroslav Lichvar wrote:
On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote:
Mail Lists lists@sapience.com writes:
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.
I think this is a terrible idea.
Yes. I certainly wouldn't use it, and especially object to the proposed strong-arm tactics of eliminating all configuration support for ntpd. The case for making chrony default is weak enough, and the case for throwing roadblocks in the way of people who prefer ntpd is nonexistent.
I'm not suggesting to remove the ntp support from s-c-d, just to add a support for chrony and change the dependency to a name provided by both packages and marking chrony as default in the comps.
I think it would be better to drop ntp support completely from s-c-d once chrony becomes default in Fedora. We aim to support default Fedora configuration tools. Radek Novacek is now working on date/time DBus interface under FMCI umbrella.
Jaroslav
Jaroslav Reznik wrote:
I think it would be better to drop ntp support completely from s-c-d once chrony becomes default in Fedora. We aim to support default Fedora configuration tools. Radek Novacek is now working on date/time DBus interface under FMCI umbrella.
Speaking of configuration tools, we also need to have a look at KDE's date/time dialog. Currently, there is an option to enable NTP support, but 1. it doesn't notice that it's already enabled by system-config-date or Anaconda :-(, 2. it's quite lacking in options (you can only enable/disable it and pick one server (not even a list of servers), no other options), and 3. it obviously doesn't support Chrony at this time.
Kevin Kofler
On Sunday 09 May 2010 19:13:57 Kevin Kofler wrote:
Jaroslav Reznik wrote:
I think it would be better to drop ntp support completely from s-c-d once chrony becomes default in Fedora. We aim to support default Fedora configuration tools. Radek Novacek is now working on date/time DBus interface under FMCI umbrella.
Speaking of configuration tools, we also need to have a look at KDE's date/time dialog. Currently, there is an option to enable NTP support, but
- it doesn't notice that it's already enabled by system-config-date or
Anaconda :-(, 2. it's quite lacking in options (you can only enable/disable it and pick one server (not even a list of servers), no other options), and 3. it obviously doesn't support Chrony at this time.
Kevin Kofler
I was thinking about it and I talked to Mirek Lichvar about it. We will probably need a custom distribution path if we'd like to reuse system config interface Radek Novacek is working right now. I don't like it but it's not going to be upstreamable :( Same for other configuration modules... Another possibility is to have own custom KCM (next to system-config-date).
Jaroslav
2010/5/6 Miroslav Lichvar mlichvar@redhat.com:
On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote:
Mail Lists lists@sapience.com writes:
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.
I think this is a terrible idea.
Yes. I certainly wouldn't use it, and especially object to the proposed strong-arm tactics of eliminating all configuration support for ntpd. The case for making chrony default is weak enough, and the case for throwing roadblocks in the way of people who prefer ntpd is nonexistent.
I'm not suggesting to remove the ntp support from s-c-d, just to add a support for chrony and change the dependency to a name provided by both packages and marking chrony as default in the comps.
for the desktop/default/gnome spin... but not for the full dvd i hope. other than that having an option is a nice idea if it is less "expensive" on resources and enough for a certain group of users (desktop ones). removing support for ntpd would be a completly different deal.
kind regards, Rudolf Kastl
-- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, May 06, 2010 at 01:10:36PM +0200, Miroslav Lichvar wrote:
On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote:
Mail Lists lists@sapience.com writes:
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.
I think this is a terrible idea.
Yes. I certainly wouldn't use it, and especially object to the proposed strong-arm tactics of eliminating all configuration support for ntpd. The case for making chrony default is weak enough, and the case for throwing roadblocks in the way of people who prefer ntpd is nonexistent.
I'm not suggesting to remove the ntp support from s-c-d, just to add a support for chrony and change the dependency to a name provided by both packages and marking chrony as default in the comps.
I would suggest to have only one NTP client in the s-c-d. In my opinion users which use s-c-d won't know what is different between ntpd and chrony. Selection will be only confusing.
In my opinion complains about security bugs and stability are quite invalid. It will mean that we should automatically reject all new alternative programs as suspicious and full of bugs. They might be less stable that their widely used friends but they also might be more stable. I don't see this as a valid argument.
Maintainer's decisions should be respected in this cases because he is generally the person who knows the package, in this case NTP, well. Especially when he actively maintains it for more than four years. It of course doesn't mean he should drop ntp from distro. It will be here for people who prefer it. "Default" means "this is generally the best", not that "this is the fastest" or "this has the most features" of "this is the most accurate".
Regards, Adam
On Thu, May 06, 2010 at 02:21:50PM +0200, Adam Tkac wrote:
On Thu, May 06, 2010 at 01:10:36PM +0200, Miroslav Lichvar wrote:
I'm not suggesting to remove the ntp support from s-c-d, just to add a support for chrony and change the dependency to a name provided by both packages and marking chrony as default in the comps.
I would suggest to have only one NTP client in the s-c-d. In my opinion users which use s-c-d won't know what is different between ntpd and chrony. Selection will be only confusing.
If only one of them is installed, no selection has to be presented.
The ntp.conf and chrony.conf files have very similar syntax, the server specification directives are identical, so I think supporting them both will be easy.
Once upon a time, Mail Lists lists@sapience.com said:
Aside - I also dont understand the motivation to start again and reimplement the wheel all over again ... and not take advantage of a mature product and work to improve ntpd or enhance it.
The project goals are different. Ntpd is designed for long-uptime servers with good quality, stable clocks, and supports external reference clocks (GPS, WWVB, etc.). Chrony is targeted more at the desktop systems, where the system is not on 24x7, and may not have as stable of an environment.
Chrony was started because the ntpd authors were not interested in adapting ntpd to other setups.
Chrony would probably be a better choice for most desktop and especially notebooks (anything that isn't on 24x7); it usually converges to a stable clock much faster than ntpd (which can easily take 12 hours or more in some cases).
Chrony is also hardly "immature"; as pointed out in the message you replied to, it has been around for many years. As for security, the last update to ntpd in Fedora 12 was for security as well (and ntpd has had some major issues over the years).
If you have a legitimate issue with Chrony, state it, but please don't throw stones in the NTP glass house.
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 wrote:
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.
There was a "super accurate timing" thread a few days ago. Certainly much newer than the alternatives, so I suppose it is also more "immature". Still interesting, though.
On Thu, May 06, 2010 at 02:10:20PM +0200, Roberto Ragusa wrote:
Miroslav Lichvar wrote:
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.
There was a "super accurate timing" thread a few days ago. Certainly much newer than the alternatives, so I suppose it is also more "immature". Still interesting, though.
The RADclock client seems to be designed for LAN environments, at least the current version. It misses multiple source support and falseticker detection which is important in our default config, as the quality of pool.ntp.org servers varies a lot.
However, many of the ideas they use are used in chrony too. I'd not be surprised if chrony configured for LAN performed similarly well as RADclock (in terms of absolute clock).
Mail Lists wrote:
The prime motivation of this project is a use case of intermittent internet connections of 5 mins a day.
I seriously doubt that is the common use case for majority of fedora users.
I think intermittent Internet connections are actually extremely common. Think laptops/notebooks/netbooks. For frequent travelers, even only 5 mins/day of Internet access might be a realistic estimate, though a bit extreme. But ntpd is already a FAIL with much more uptime than that.
Kevin Kofler
On Sun 9 May 2010 10:26:35 am Kevin Kofler wrote:
Mail Lists wrote:
The prime motivation of this project is a use case of intermittent
internet connections of 5 mins a day.
I seriously doubt that is the common use case for majority of fedora
users.
I think intermittent Internet connections are actually extremely common. Think laptops/notebooks/netbooks. For frequent travelers, even only 5 mins/day of Internet access might be a realistic estimate, though a bit extreme. But ntpd is already a FAIL with much more uptime than that.
Here is how I see this: The user installs their system for the first time, they set their clock using NTP while they have the connection to the internet when they installed their packageset/updates. Now they have an accurate clock.
How much drift can happen that each and every time they connect to the internet, even if it's only for five minutes, would they need to resync their clock? I have NTP disabled altogether on this machine, and since I've installed it, it's still within about 5 seconds of my mother's Windows machine which _does_ have ntp disabled.
I find that having NTP enabled in most cases for mobile systems is simply unnecessary; there is a large (I would say upwards of 95% in my most unscientific guessings) chance that these users aren't going to be doing anything which requires their clocks to be synced with any amount of precision. And if they are, they should _know_ that and be able to set up a tool (whether it is NTP or Crony) themselves.
Imo the use cases for having a constantly synced-to-the-second clock are minimal at best.
Kevin Kofler
Ryan "All the clocks on my desktop are KDE Plasma's Fuzzy Clock applet with about 10 minute precision so who am I to talk?" Rix
On Sun, May 09, 2010 at 01:15:03PM -0700, Ryan Rix wrote:
I find that having NTP enabled in most cases for mobile systems is simply unnecessary; there is a large (I would say upwards of 95% in my most unscientific guessings) chance that these users aren't going to be doing anything which requires their clocks to be synced with any amount of precision. And if they are, they should _know_ that and be able to set up a tool (whether it is NTP or Crony) themselves.
I guess you've never had to debug Kerberos before. Luckily, neither have i, so i'm not one to talk. There are a number of apps that are pretty dependent on the clocks being in sync with each other to a degree. Granted, not everyone is running all those apps, but then it begs the question why Fedora provides so much out of the box in the first place. Let's assume that NTP is probably a good thing to support out of the box on most machines, assuming we can support it right in the first place.
-Yaakov
On Mon, May 10, 2010 at 2:45 AM, Yaakov M. Nemoy loupgaroublond@gmail.com wrote:
On Sun, May 09, 2010 at 01:15:03PM -0700, Ryan Rix wrote:
I find that having NTP enabled in most cases for mobile systems is simply unnecessary; there is a large (I would say upwards of 95% in my most unscientific guessings) chance that these users aren't going to be doing anything which requires their clocks to be synced with any amount of precision. And if they are, they should _know_ that and be able to set up a tool (whether it is NTP or Crony) themselves.
I guess you've never had to debug Kerberos before. Luckily, neither have i, so i'm not one to talk. There are a number of apps that are
I have. The users who end up with the most problems are laptop users. I wonder if windows basically does a forced 'get my time right from sources' when it awakes as I rarely had issues with AD/windows boxes on it... but other OS's have that problem. I believe that SSL will also have problems in some use cases if the clocks are too off.. but that might have been Kerb related also.
pretty dependent on the clocks being in sync with each other to a degree. Granted, not everyone is running all those apps, but then it begs the question why Fedora provides so much out of the box in the first place. Let's assume that NTP is probably a good thing to support out of the box on most machines, assuming we can support it right in the first place.
-Yaakov
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, May 9, 2010 at 4:15 PM, Ryan Rix ry@n.rix.si wrote:
Here is how I see this: The user installs their system for the first time, they set their clock using NTP while they have the connection to the internet when they installed their packageset/updates. Now they have an accurate clock.
How much drift can happen that each and every time they connect to the internet, even if it's only for five minutes, would they need to resync their clock? I have NTP disabled altogether on this machine, and since I've installed it, it's still within about 5 seconds of my mother's Windows machine which _does_ have ntp disabled.
The amount of drift you may see is highly dependant on your hardware. A mere 1% frequency offset will gain or lose almost two hours per week.
Arguably a system which drifts unacceptably is broken yet depending on your definition of unacceptably all of the available PC hardware is broken. And a constant frequency offset like that is trivially fixable.
My last laptop lost a minute or two per week of uncorrected operation. At the time I was travelling a lot— and ending up habitually a late for a conference calls would remind me to unwedge it. The current laptop has, fortunately, only lost 2 seconds since Friday. Two headless systems of mine with "good" clocks in a temperature controlled environment show drift of 16 and 37 ppm (0.7 and 1.6 minutes per month respectively).
A typical decent crystal oscillator simply running 10 deg C off its design temperature might be ~20 ppm off on its own.
I find that having NTP enabled in most cases for mobile systems is simply unnecessary; there is a large (I would say upwards of 95% in my most unscientific guessings) chance that these users aren't going to be doing anything which requires their clocks to be synced with any amount of precision. And if they are, they should _know_ that and be able to set up a tool (whether it is NTP or Crony) themselves.
Imo the use cases for having a constantly synced-to-the-second clock are minimal at best.
"I find that having non-root accounts enabled in most cases for mobile systems is simply unnecessary"(...)
But really— having accurate time is important for all systems: Have you never had the experience of trying to debug a networked system only to eventually discover that there was a few seconds clock skew confusing your troubleshooting?
At least in my world there are increasingly only two kinds of machines: mobile devices and headless servers, in that context what you're saying is that only servers need correct time, and I think that is quite wrong. Errors at the level of minutes are easily accumulated on common hardware and will impact human affairs. Sub-minute errors will frustrate technical troubleshooting— confusing the mutual ordering of events between systems even when the timestamps look quite different.
An inaccurate clock even reduces user privacy on the internet as it makes hosts more easily distinguishable when the client's time is available over the network.
If timekeeping really hard to fix on the lossy hardware we use I might buy an argument that fixing it wasn't worth the cost, but fortunately it is easily fixed to sub-second levels by running a simple daemon. Though, unfortunately, the NTP package will often fail to do anything useful when used on the increasingly common configurations with highly intermittent network connectivity.
Perhaps you may not care about these things— but other people do for good reason, and you ought not oppose their efforts to advance the usefulness of the system.
On Wed, May 5, 2010 at 7:35 AM, Miroslav Lichvar mlichvar@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 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.
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] 2) Where is the data that chrony actually controls the clock better? 3) How far have you/others tested it in comparison with ntpd? 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.
On 05/09/2010 01:45 PM, Stephen John Smoogen wrote:
lets go over a couple of things to help lower the grumpiness of others.
A good summary which shows care and thoughtfulness - please add also the question:
4) For servers (distinct from the desktop use case) - which would be the better choice (and why with supporting data).
Thank you for the thoughtful post SJS.
gene
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@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.
- Who are you?
- 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:
- Why chrony? Why not OpenNTPD [fill in the blank here]
I think the most important chrony features are covered in the original mail.
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.
- Where is the data that chrony actually controls the clock better?
One comparison is here: http://axion.physics.ubc.ca/chrony/chrony.html
An old test I did with a GPS reference clock (this may better demonstrate clock control abilities): http://fedorapeople.org/~mlichvar/chrony/chrony_vs_ntp.png
- 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.
- 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 conditions - 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
On So, 2010-05-09 at 11:45 -0600, Stephen John Smoogen wrote: [...]
- Why chrony? Why not OpenNTPD [fill in the blank here]
Dunno if this is important for this discussion but the portable version of OpenNTPD is stuck. The last portable version was made available in May 2006 while the OpenBSD version was released in November 2009.
-
Adam Tkac -
Chris Adams -
Genes MailLists -
Gregory Maxwell -
Jaroslav Reznik -
Kevin Kofler -
Miroslav Lichvar -
Roberto Ragusa -
Rudolf Kastl -
Ryan Rix -
Stefan Schulze Frielinghaus -
Stephen John Smoogen -
Tom Lane -
Yaakov Nemoy