[ntp:questions] Red Hat vote for chrony

I've been reading the migration guidance document for RHEL 7 and it seems that Chrony has replaced ntpd as their default NTP based time synchonisation package.

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-04, David Woolley wrote: > I've been reading the migration guidance document for RHEL 7 and it > seems that Chrony has replaced ntpd as their default NTP based time > synchonisation package. >

Re: [ntp:questions] Red Hat vote for chrony

On Dec 4, 2014, at 7:00 PM, William Unruh wrote: [ ... ] > Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has > done a lot of testing comparing chrony to ntpd ( which showed that > chrony controlled the clock a factor of 2 to 20 times better than ntpd > did), and is with Redh

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, Charles Swiger wrote: > On Dec 4, 2014, at 7:00 PM, William Unruh wrote: > [ ... ] >> Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has >> done a lot of testing comparing chrony to ntpd ( which showed that >> chrony controlled the clock a factor of 2 to 20 ti

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 3:42 AM, William Unruh wrote: > On 2014-12-05, Charles Swiger wrote: >> On Dec 4, 2014, at 7:00 PM, William Unruh wrote: >> [ ... ] >>> Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has >>> done a lot of testing comparing chrony to ntpd ( which showed th

Re: [ntp:questions] Red Hat vote for chrony

On 05/12/14 08:42, William Unruh wrote: Nope. ntp changes the rate of the local clock to correct offsets. That is all it does. It does not make the rate correct, and then the offset. Not true. It applies a correction for the offset, such that if that were the only error, it would be eliminat

Re: [ntp:questions] Red Hat vote for chrony

On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger wrote: > I also make sure that my > timeservers are running in temperature-controlled environments so that > such daily drifts you mention are minimized. I'm starting to think that people answering questions are unsure of the real question so they

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, Charles Swiger wrote: > On Dec 5, 2014, at 3:42 AM, William Unruh wrote: >> On 2014-12-05, Charles Swiger wrote: >>> On Dec 4, 2014, at 7:00 PM, William Unruh wrote: >>> [ ... ] Actually Miroslav Lichvar IS an expert. He is the chrony maintainer, has done a lot of testi

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, David Woolley wrote: > On 05/12/14 08:42, William Unruh wrote: > >> Nope. ntp changes the rate of the local clock to correct offsets. That >> is all it does. It does not make the rate correct, and then the offset. > > Not true. It applies a correction for the offset, such that if t

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 11:47 AM, Paul wrote: > On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger wrote: >> I also make sure that my >> timeservers are running in temperature-controlled environments so that >> such daily drifts you mention are minimized. > > I'm starting to think that people answering q

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 11:53 AM, William Unruh wrote: [ ... ] >>> It simply alters the rate at any time so as to decrease the offset, and >>> it does this measurement by measurement. It has no memory. >> >> This is obviously false. What do you think /etc/ntp.drift is? > > It is the offset from the

Re: [ntp:questions] Red Hat vote for chrony

On Fri, Dec 5, 2014 at 3:35 PM, Charles Swiger wrote: > Well, we do have time enthusiasts around who like to achieve the best > precision they can, regardless of whether there is a specific business > justification or not. :-) > Sure but that doesn't help someone that just wants a simple (-mind

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul wrote: [ ... ] >> Even back in 2002 with very inexpensive commodity hardware, FreeBSD was >> able to achieve accuracy measured to ~260 nanoseconds: > > H. So phk uses a $1,500 rubidium standard as a system oscillator and > you call it inexpensive and commodit

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul wrote: [ ... ] >> Even back in 2002 with very inexpensive commodity hardware, FreeBSD was >> able to achieve accuracy measured to ~260 nanoseconds: > > H. So phk uses a $1,500 rubidium standard as a system oscillator and > you call it inexpensive and commodit

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:55 PM, Paul wrote: [ ... ] >> Even back in 2002 with very inexpensive commodity hardware, FreeBSD was >> able to achieve accuracy measured to ~260 nanoseconds: > > H. So phk uses a $1,500 rubidium standard as a system oscillator and > you call it inexpensive and commodit

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-05, Charles Swiger wrote: > On Dec 5, 2014, at 11:53 AM, William Unruh wrote: > [ ... ] It simply alters the rate at any time so as to decrease the offset, and it does this measurement by measurement. It has no memory. >>> >>> This is obviously false. What do you think /et

Re: [ntp:questions] Red Hat vote for chrony

On Dec 5, 2014, at 5:01 PM, Paul wrote: > On Fri, Dec 5, 2014 at 7:06 PM, Charles Swiger wrote: >> No, he used a $1500 rubidium clock to accurately measure the timekeeping >> quality of a $220 Soekris computer, and concluded: >> >> "The data on this page was obtained using a setup which was desi

Re: [ntp:questions] Red Hat vote for chrony

> On Dec 5, 2014, at 8:39 PM, William Unruh wrote: > This is obviously false. What do you think /etc/ntp.drift is? >>> >>> It is the offset from the standard rate of the clock. That memory is >>> never used except on bootup. ntpd has to know how much to alter the >>> drift. >> >> Ah, so

Re: [ntp:questions] Red Hat vote for chrony

On 06/12/14 12:27, Charles Swiger wrote: But to try and stay on point: how do you measure the performance of a typical disciplined "system" (virtual) clock in a general purpose computer -- ideally without specialized hardware and software but those are okay if the results can be meaningfully

Re: [ntp:questions] Red Hat vote for chrony

On 06/12/14 12:27, Charles Swiger wrote: Some folks will be satisfied with Miroslav Lichvar's simulations but I'm not smart enough to understand them. Other's will be convinced because they can run Chrony on a Unix laptop and save power or discipline a clock with only a few minutes a day of c

Re: [ntp:questions] Red Hat vote for chrony

Charles Swiger wrote: On Dec 5, 2014, at 5:55 PM, Paul wrote: [ ... ] Even back in 2002 with very inexpensive commodity hardware, FreeBSD was able to achieve accuracy measured to ~260 nanoseconds: H. So phk uses a $1,500 rubidium standard as a system oscillator and you call it inexpensive

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-06, Charles Swiger wrote: > On Dec 5, 2014, at 5:01 PM, Paul wrote: >> On Fri, Dec 5, 2014 at 7:06 PM, Charles Swiger wrote: >>> No, he used a $1500 rubidium clock to accurately measure the timekeeping >>> quality of a $220 Soekris computer, and concluded: >>> >>> "The data on this p

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-06, Charles Swiger wrote: > >> On Dec 5, 2014, at 8:39 PM, William Unruh wrote: >> > This is obviously false. What do you think /etc/ntp.drift is? It is the offset from the standard rate of the clock. That memory is never used except on bootup. ntpd has to know ho

Re: [ntp:questions] Red Hat vote for chrony

On 06/12/14 16:33, William Unruh wrote: memory. And in normal operation, it does not even know about the current drift rate-- it is the operating system that does that. All ntpd does is That's because part of the NTP algorithm is implemented in the kernel where it can be done per tick with ne

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 7:27 AM, Charles Swiger wrote: > Um, certainly? Are you concerned about the quality of the XO which > shipped with a Soekris board? > That'd be important if you were running a stratum-2+ timeserver. > If you don't do the reading you won't understand the problems. Here's

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 11:12 AM, William Unruh wrote: > You do not understand them, but feel confident to make recommendations > despite that? While I'm not making a broader statement about who understands what I believe you're conflating my comments with those from cswi...@mac.com. ___

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 11:12 AM, William Unruh wrote: > And in my tests 10 years ago or so, I used a local gps clock to test the > ability of chrony and ntpd to discipline a computer clock networked to > another server which was disciplined by a gps. Thus the network was the > same, and the diffe

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-06, Paul wrote: > On Sat, Dec 6, 2014 at 11:12 AM, William Unruh wrote: > >> And in my tests 10 years ago or so, I used a local gps clock to test the >> ability of chrony and ntpd to discipline a computer clock networked to >> another server which was disciplined by a gps. Thus the net

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 6, 2014 at 4:57 PM, William Unruh wrote: > But then this thread was about Redhat, which is Linux. I understand that but it's not the point. This thread is about a distro defaulting to Chrony -- and why that's a bad (or good) thing. I say it's an inconvenience because I'm uninteres

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-06, Paul wrote: > On Sat, Dec 6, 2014 at 4:57 PM, William Unruh wrote: > >> But then this thread was about Redhat, which is Linux. > > > > I understand that but it's not the point. This thread is about a distro > defaulting to Chrony -- and why that's a bad (or good) thing. I say it's

Re: [ntp:questions] Red Hat vote for chrony

On Sat, 06 Dec 2014 14:27:47 +, David Woolley wrote: > On 06/12/14 12:27, Charles Swiger wrote: >>> Some folks will be satisfied with Miroslav Lichvar's simulations but >>> I'm not smart enough to understand them. Other's will be convinced >>> because they can run Chrony on a Unix laptop and

Re: [ntp:questions] Red Hat vote for chrony

On 07/12/14 09:08, detha wrote: More and more of those servers end up being virtualized. Quicker reaction to virtualization funnies, and faster convergence on VMs that are spun up/down on demand, seem to be one of the main reasons Redhat switched to chrony. Surely the right solution for that is

Re: [ntp:questions] Red Hat vote for chrony

> On Dec 6, 2014, at 11:46 AM, Paul wrote: >> On Sat, Dec 6, 2014 at 7:27 AM, Charles Swiger wrote: >> Um, certainly? Are you concerned about the quality of the XO which shipped >> with a Soekris board? >> That'd be important if you were running a stratum-2+ timeserver. > > If you don't do th

Re: [ntp:questions] Red Hat vote for chrony

On Dec 6, 2014, at 8:33 AM, William Unruh wrote: > On 2014-12-06, Charles Swiger wrote: >> >>> On Dec 5, 2014, at 8:39 PM, William Unruh wrote: [ ... ] Just like your claim whether the chrony docs recommend using maxpoll=4 across the network to a LAN timesource or not was wrong? >>>

Re: [ntp:questions] Red Hat vote for chrony

On Sun, Dec 7, 2014 at 2:42 PM, Charles Swiger wrote: > I would agree with this point if it were applicable. > In fact it is as others have tried to point out to you. ... Heck, even today's modern smartphone has an > AGPS chip and more horsepower than a ~2002-era Soekris with an embedded > CPU

Re: [ntp:questions] Red Hat vote for chrony

On Dec 7, 2014, at 12:47 PM, Paul wrote: > On Sun, Dec 7, 2014 at 2:42 PM, Charles Swiger wrote: >> ... Heck, even today's modern smartphone has an >> AGPS chip and more horsepower than a ~2002-era Soekris with an embedded CPU. > > I have no idea what you're talking about but "horsepower" is not

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-07, Charles Swiger wrote: ... >> That's why NTP can act as a thermometer. The big problem is temperature >> induced wander and that's something (back to RedHat and Chrony) Chrony >> claims to do better. > > Yes, ntpd and chrony will notice temperature changes causing a frequency > d

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-07, Charles Swiger wrote: > On Dec 6, 2014, at 8:33 AM, William Unruh wrote: >> On 2014-12-06, Charles Swiger wrote: >>> On Dec 5, 2014, at 8:39 PM, William Unruh wrote: > [ ... ] > Just like your claim whether the chrony docs recommend using maxpoll=4 > across the netw

Re: [ntp:questions] Red Hat vote for chrony

On Sun, 07 Dec 2014 09:46:35 +, David Woolley wrote: > On 07/12/14 09:08, detha wrote: >> More and more of those servers end up being virtualized. Quicker >> reaction to virtualization funnies, and faster convergence on VMs that >> are spun up/down on demand, seem to be one of the main reasons

Re: [ntp:questions] Red Hat vote for chrony

On Mon, Dec 08, 2014 at 03:27:15AM +, William Unruh wrote: > On 2014-12-07, Charles Swiger wrote: > > Yes, so chrony recommends using maxpoll=4 to the LAN, and not only to local > > refclocks. > > No, read the chrony docs. the default is maxpoll 10 minpoll 5. The default minpoll is 6 and m

Re: [ntp:questions] Red Hat vote for chrony

On Sat, Dec 06, 2014 at 03:35:10PM -0500, Paul wrote: > On Sat, Dec 6, 2014 at 11:12 AM, William Unruh wrote: > > > And in my tests 10 years ago or so, I used a local gps clock to test the > > ability of chrony and ntpd to discipline a computer clock networked to > > another server which was disc

Re: [ntp:questions] Red Hat vote for chrony

On Dec 7, 2014, at 7:19 PM, William Unruh wrote: >> I suspect most people are a bit more likely to use air conditioning to >> control ambient >> temperature changes then they are to desolder and swap out their crystals in >> the >> hopes of obtaining more precise timekeeping > > Actually ai

Re: [ntp:questions] Red Hat vote for chrony

On Dec 7, 2014, at 7:27 PM, William Unruh wrote: > On 2014-12-07, Charles Swiger wrote: >> On Dec 6, 2014, at 8:33 AM, William Unruh wrote: >>> On 2014-12-06, Charles Swiger wrote: [ ... ] >> Dude, give it a rest. You've just acknowledged that the chrony docs at the >> URL >> ending with "man

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-08, Charles Swiger wrote: > On Dec 7, 2014, at 7:19 PM, William Unruh wrote: >>> I suspect most people are a bit more likely to use air conditioning to >>> control ambient >>> temperature changes then they are to desolder and swap out their crystals >>> in the >>> hopes of obtaining

Re: [ntp:questions] Red Hat vote for chrony

On Dec 8, 2014, at 9:19 AM, William Unruh wrote: >> Data point: for a normal desktop machine I have at home, which has a >> 95W TDP i5 CPU and a 145W 970 GPU, I can see a ~12C temperature change >> on the motherboard temp sensor between idle and full load on both as the >> total system draw goes

Re: [ntp:questions] Red Hat vote for chrony

On Dec 8, 2014, at 12:04 PM, Phil W Lee wrote: >> With air-conditioning on, the temperature change shrinks to about 5C, >> which reduces the thermal wandering of the XO by a factor of 2. That >> seems to be a worthwhile improvement, not "largely irrelevant". > > Of course, server class machines

Re: [ntp:questions] Red Hat vote for chrony

On 09/12/14 07:06, Charles Swiger wrote: Yes, I also find it a bit surprising than modern desktop CPUs and GPUs are willing to run right up to their thermal trip points of ~80 C or so rather than bump up fan speed a little more to keep them more around 50 C. Cost engineering, for what is a thro

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-09, Charles Swiger wrote: ... > [ ... ] >> Of course, in an ideal system designed for clock stability, the clock >> variation with temperature would be measured, and an offset based on >> the temperature of the crystal applied directly to the output of the >> clock itself, before it was

Re: [ntp:questions] Red Hat vote for chrony

William Unruh wrote: On 2014-12-09, Charles Swiger wrote: ... [ ... ] Of course, in an ideal system designed for clock stability, the clock variation with temperature would be measured, and an offset based on the temperature of the crystal applied directly to the output of the clock itself, be

Re: [ntp:questions] Red Hat vote for chrony

to:questions-bounces+elliott.ch=comcast@lists.ntp.org] On > Behalf Of David Woolley > Sent: Tuesday, December 9, 2014 3:09 AM > To: questions@lists.ntp.org > Subject: Re: [ntp:questions] Red Hat vote for chrony > > On 09/12/14 07:06, Charles Swiger wrote: > > Yes, I als

Re: [ntp:questions] Red Hat vote for chrony

On Dec 9, 2014, at 2:41 AM, Terje Mathisen wrote: [ ... ] >>> Yes; you're describing calibrating a temperature-compensated XO, or TCXO. >> >> There are also versions of ntp which have a temp >> compensation/measurement system compiled in to apply to the clocks. It >> does tend to give much better

Re: [ntp:questions] Red Hat vote for chrony

On 2014-12-09, Charles Swiger wrote: > On Dec 9, 2014, at 2:41 AM, Terje Mathisen wrote: > [ ... ] Yes; you're describing calibrating a temperature-compensated XO, or TCXO. >>> >>> There are also versions of ntp which have a temp >>> compensation/measurement system compiled in to apply to t

Re: [ntp:questions] Red Hat vote for chrony

William Unruh wrote: On 2014-12-09, Charles Swiger wrote: On Dec 9, 2014, at 2:41 AM, Terje Mathisen wrote: [ ... ] Yes; you're describing calibrating a temperature-compensated XO, or TCXO. There are also versions of ntp which have a temp compensation/measurement system compiled in to apply

Re: [ntp:questions] Red Hat vote for chrony

On Tue, Dec 9, 2014 at 4:02 PM, David Lord wrote: > My xtal book gives either parabolic or lazy-s curves but the > real problem with cheap crystals is that the turning point or > flat sections can be way off the ambient temperature. > phk suggests that modern high-clock systems have better cryst

Re: [ntp:questions] Red Hat vote for chrony

On Dec 9, 2014, at 11:38 AM, William Unruh wrote: >> Well, yes. You can get a PCI(e) card with a TCXO or OCXO and an >> optional GPS module like the Beagle ClockCard or a SpectraCom TSync >> for a few hundred bucks. >> >> That's quite a bit more than a $40 GPS puck, but these will also >> freewh

Re: [ntp:questions] Red Hat vote for chrony

Charles Swiger wrote: >> The correct solution is of course to not depend on $0.10 crystals as the >> time base for dedicated NTP servers. :-) > > Well, yes. You can get a PCI(e) card with a TCXO or OCXO and an > optional GPS module like the Beagle ClockCard or a SpectraCom TSync > for a few hund

Re: [ntp:questions] Red Hat vote for chrony

On Tue, Dec 09, 2014 at 07:38:06PM +, William Unruh wrote: > On 2014-12-09, Charles Swiger wrote: > > Well, yes. You can get a PCI(e) card with a TCXO or OCXO and an > > optional GPS module like the Beagle ClockCard or a SpectraCom TSync > > for a few hundred bucks. > > > > That's quite a bit

Re: [ntp:questions] Red Hat vote for chrony

On Wed, Dec 10, 2014 at 5:04 AM, Miroslav Lichvar wrote: > > See also the following post, apparently the BBB can use a separate HW > timer to timestamp PPS, reducing the error and jitter significantly. > > http://blog.dan.drown.org/beaglebone-black-timer-capture-driver/ > > It looks like this cou

Re: [ntp:questions] Red Hat vote for chrony

On Mon, 8 Dec 2014, Phil W Lee wrote: > In theory, this wouldn't be expensive if done at the mass production > stage, but clock stability isn't high enough on the design priorities > for designers to put it into mass market machines. It's been awhile since I've heard this whine on c.p.t.n. Compla