Re: [ntp:questions] Red Hat vote for chrony
On 2014-12-05, Charles Swiger cswi...@mac.com wrote: On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca 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 Redhat. The data I've seen for chrony suggests it handles broken clocks such as commonly found in VMs better than ntpd does. The tradeoff is that chrony prioritizes chasing the reference time over first trying to ensure that the local clock frequency is stable, whereas ntpd really wants to make sure that the local clock counts 3600 seconds in each hour of wall-clock time and then worries about slewing the local time to match up with the reference time. 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. 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. Chrony uses the last N measurements to make the best estimate of the rate and the offset that it can. It sets the rate to the best estimate of the true rate, and then adds a rate correction to decrease the offset. It's informative to note that the chrony docs (section 5.3.4) recommend using minpoll=2 and maxpoll=4! With those settings chrony will send 225 that is for refclocks. polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10. Assuming arguendo the claim of a factor of 20 times better is true, I still don't care to pay the price of a factor of 64 times more network polls. You may set the minpoll and maxpoll to whateever you want. But chrony does not advocate a maxpoll of 4 over the network. Read again. Furthermore-- unfortunately-- I have yet to see data on the accuracy of chrony measured against high-quality TCXO or Rb/Cs reference clocks, such as the PRS-10 that PHK used: http://www.thinksrs.com/products/PRS10.htm ...the current version of which claims to have a +/- 10 ns accuracy for the PPS signal. Instead, most of the data I've seen provided for chrony has involved comparing local clock timestamps to the reference timesource or to some other network timesource, without detailed information as to the accuracy of those references. Nope. I have done measurements on the net where I compared the net to a gps PPS source. The computer PPS has an accuracy of about 1microsec and that can be compared to the network time. I get an increase of about 2-3 times better than ntp. Lichvar got something like 20 times better using a PPS against a local high accuracy time source. The main reason seems to be that chrony is far more algile-- it catches temperature drifts much more quickly than ntpd does, for the same poll. Remember that ntpd throws out 85% of the measurements it makes, in order to try (poorly) to compensate for network up-down inequalities. Sometimes, if the network is very variably assymetric that can improve results. Usually it simply throws away valuable measurements. ntpd is also designed to act very slowly to changes in rate. It is a design philosophy Mills defends strongly, with the matra of stability. Chrony, because of its long term memory, recognizes and responds to rate variations much more quickly, with no sign of instability. It would be good to have a detailed analysis of the chrony algorithm to see if there are corner cases where chrony does worse by going unstable. ntpd is simple to analyse (if one ignores the extreme non-linearity of the jump if the offset is greater than 128ms.) If you would like to compare chrony vs ntp with your PRS10, please do so. Otherwise look at some of he numbers I have on www.theory.physics.ubc.ca/chrony Of course you're not going to see much delta between the local clock and the reference that you're polling every 16 seconds. Without measuring the local clock against some other clock or oscillator which is known to be accurate to sub-microsecond levels, one doesn't have the data needed to draw conclusions about the actual timekeeping precision. Actually not true. How do you think the standards of the various contries determine the accuracy of their clocks. They have no better time standard to compare them with. And yet they confidently will quote accuracy figures for their clocks. Study that. Regards, ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 04/12/2014 20:03, Rob wrote: [] It is not good practice to use pool on 100-1000 internal systems, presumably via NAT, to poll time from internet. Simple advice is: setup 1 NTP server when you are always monitoring, or 2 servers when you cannot always be on watch to fix the one server, and keep them mutually synchronized. That will work OK in a company. Maybe not in the head of a thought experimenter, but that is normally not what companies are after. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, and that's what we tried to set up. These were not time critical systems, though. The on-site servers would at least have pool as a backup. This was before the days of cheap GPS/PPS, though. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 04/12/2014 20:03, Rob wrote: [] It is not good practice to use pool on 100-1000 internal systems, presumably via NAT, to poll time from internet. Simple advice is: setup 1 NTP server when you are always monitoring, or 2 servers when you cannot always be on watch to fix the one server, and keep them mutually synchronized. That will work OK in a company. Maybe not in the head of a thought experimenter, but that is normally not what companies are after. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. Just two servers is more than adequate for the typical network where of course the servers are being monitored and alerts are being handled in a timely fashion. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
David Taylor wrote: On 04/12/2014 20:03, Rob wrote: [] It is not good practice to use pool on 100-1000 internal systems, presumably via NAT, to poll time from internet. Simple advice is: setup 1 NTP server when you are always monitoring, or 2 servers when you cannot always be on watch to fix the one server, and keep them mutually synchronized. That will work OK in a company. Maybe not in the head of a thought experimenter, but that is normally not what companies are after. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, and that's what we tried to set up. You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote: On 2014-12-05, Charles Swiger cswi...@mac.com wrote: On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca 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 Redhat. The data I've seen for chrony suggests it handles broken clocks such as commonly found in VMs better than ntpd does. The tradeoff is that chrony prioritizes chasing the reference time over first trying to ensure that the local clock frequency is stable, whereas ntpd really wants to make sure that the local clock counts 3600 seconds in each hour of wall-clock time and then worries about slewing the local time to match up with the reference time. 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. If you don't know what the rate of the local clock is, how can you figure out the proper slewing rate? One can obviously keep slewing the clock towards the reference time even without having a good idea of the intrinsic drift, but such an approach will tend to overshoot the ideal frequency adjustment and ring or oscillate back and forth. 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? Furthermore, I distinctly recall you complaining that ntpd's clock filter throws away 7 out of 8 polls; even though you are mis-interpreting the situation, you at least acknowledged that ntpd is keeping track of prior data. Or did someone else write Message-id: Hh0tu.8666$tr7.4...@fx22.iad? Chrony uses the last N measurements to make the best estimate of the rate and the offset that it can. It sets the rate to the best estimate of the true rate, and then adds a rate correction to decrease the offset. Yes, that's a reasonable approach. It's informative to note that the chrony docs (section 5.3.4) recommend using minpoll=2 and maxpoll=4! With those settings chrony will send 225 that is for refclocks. polls per hour, versus 3.5 polls per hour for ntpd with its maxpoll=10. Assuming arguendo the claim of a factor of 20 times better is true, I still don't care to pay the price of a factor of 64 times more network polls. You may set the minpoll and maxpoll to whateever you want. But chrony does not advocate a maxpoll of 4 over the network. Read again. I suggest following your own advice before trying to correct others. http://chrony.tuxfamily.org/manual.html#How-can-I-improve-the-accuracy-of-the-system-clock-with-NTP-sources_003f 5.3.4 How can I improve the accuracy of the system clock with NTP sources? Select NTP servers that are well synchronised, stable and close to your network. It’s better to use more than one server, three or four is usually recommended as the minimum, so chronyd can detect falsetickers and combine measurements from multiple sources. [ ... ] The optimal polling interval depends on many factors, this includes the ratio between the wander of the clock and the network jitter (sometimes expressed in NTP documents as the Allan intercept), the temperature sensitivity of the crystal oscillator and the maximum rate of change of the temperature. An example of the directive for a server located in the same LAN could be server ntp.local minpoll 2 maxpoll 4 polltarget 30 The docs aren't talking about reference clocks here, they are talking about polling another machine over the LAN. Furthermore-- unfortunately-- I have yet to see data on the accuracy of chrony measured against high-quality TCXO or Rb/Cs reference clocks, such as the PRS-10 that PHK used: http://www.thinksrs.com/products/PRS10.htm ...the current version of which claims to have a +/- 10 ns accuracy for the PPS signal. Instead, most of the data I've seen provided for chrony has involved comparing local clock timestamps to the reference timesource or to some other network timesource, without detailed information as to the accuracy of those references. Nope. I have done measurements on the net where I compared the net to a gps PPS source. The computer PPS has an accuracy of about 1microsec and that can be compared to the network time. About a microsecond is two orders of magnitude worse than ~10 nanoseconds. As I said before, I'd be happy to review data for chrony taken against that quality of reference. I get an increase of about 2-3 times better than ntp. Lichvar got something like 20 times better using a PPS against a local high accuracy time source. The main reason seems to be that chrony is far more algile-- it catches temperature drifts much more quickly than ntpd does, for the same poll. More agile is
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 eliminated exponentially with a time constant that is related to the poll rate. I believe it expects to update this correction well before it is fully applied. At the same time, it applies a correction to the long term estimate of the frequency, with a much longer time constant. much more quickly than ntpd does, for the same poll. Remember that ntpd throws out 85% of the measurements it makes, in order to try (poorly) to If the round trip variability was sufficiently low that this pre-filter were not needed, any variations in the samples it is ignoring would be largely suppressed by the loop filters, which have time constants that are significantly longer than even eight times the poll interval. ntpd is heavily oversampling, which means that the min and maxpols quoted for chrony imply an even higher excess rate. Actually not true. How do you think the standards of the various contries determine the accuracy of their clocks. They have no better time standard to compare them with. And yet they confidently will quote accuracy figures for their clocks. Study that. I presume that whatever time transfer mechanism they use has well characterised errors. NTP operates in an environment where the errors are not well characterised. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-05, Rob nom...@example.com wrote: David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 04/12/2014 20:03, Rob wrote: [] It is not good practice to use pool on 100-1000 internal systems, presumably via NAT, to poll time from internet. Simple advice is: setup 1 NTP server when you are always monitoring, or 2 servers when you cannot always be on watch to fix the one server, and keep them mutually synchronized. That will work OK in a company. Maybe not in the head of a thought experimenter, but that is normally not what companies are after. I was thinking of the general user. For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) then ntpd may well start jumping between the two, making the time on the client machines very unreliable. Use 3 making sure that they are independent (Ie one of them does not get its time from the other.) This is not too many safeguards. It simply protects against one going bad. Note that they can go bad. Say one of the servers goes down for some reason. That is fine, the other will handle things. But when the first comes up again, it has trouble with its gps pps (using an older Garmin 18x with older firmware where the nmea time could be a second out). Suddenly one of the servers gives a time one second out from the other. The poor client has no idea whichis right, and hops between them. Because of the 128ms rule, it jumps the time -- again and again. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. Just two servers is more than adequate for the typical network where of course the servers are being monitored and alerts are being handled in a timely fashion. It depends on how important time is. If you do not care if the time is days out, then do whatever you want. If you do care, use reasonable safeguards. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com 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 make a number of assumptions. If you care about sub-millisecond time then you need to say that and the question should be answered in that context. I suspect most of the questions here refer to sub-second accuracy and most of the elaboration is unneeded. If all your external clocks fail I suspect the typical user can depend on the disciplined virtual clock for days. For almost all of human history, the sun or the fixed celestial heavens have provided the most accurate time reference available. Even today, we add (or subtract, in theory) leap seconds in order to keep UTC and UT1 aligned to better than a second courtesy of IERS. Yes, the USNO, CERN, and so forth now do have sufficiently high quality atomic clocks which have better timekeeping precision than celestial observations. I think there's some confusion here. Search for BIPM paper clock or read http://www.ggos-portal.org/lang_en/GGOS-Portal/EN/Topics/Services/BIPM/BIPM.html Such a point is orthogonal to the notion of how to measure a local clock I think this is an interesting question. How does one get high resolution measurements of the error in the virtual clock maintained with NTP (or Chrony)? I thought it was done with purpose built systems. I don't expect a random version of Linux on generic hardware to be able to maintain the clock at nanosecond scale. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On 2014-12-05, Charles Swiger cswi...@mac.com wrote: On Dec 5, 2014, at 3:42 AM, William Unruh un...@invalid.ca wrote: On 2014-12-05, Charles Swiger cswi...@mac.com wrote: On Dec 4, 2014, at 7:00 PM, William Unruh un...@invalid.ca 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 Redhat. The data I've seen for chrony suggests it handles broken clocks such as commonly found in VMs better than ntpd does. The tradeoff is that chrony prioritizes chasing the reference time over first trying to ensure that the local clock frequency is stable, whereas ntpd really wants to make sure that the local clock counts 3600 seconds in each hour of wall-clock time and then worries about slewing the local time to match up with the reference time. 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. If you don't know what the rate of the local clock is, how can you figure out the proper slewing rate? ntpd does not care what the rate is. If it sees an offset, it alters the rate todecrease that offset. It keeps doing this until the offset is gone. It is designed so that the overshoot is very small (critical damping). One can obviously keep slewing the clock towards the reference time even without having a good idea of the intrinsic drift, but such an approach will tend to overshoot the ideal frequency adjustment and ring or oscillate back and forth. Not if it is properly designed (critical damping). Mills did a good job of designing a feedback system. As he says it is standard engineering practice. 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 standard rate of the clock. That memory is never used except on bootup. ntpd has to know how much to alter the drift. Furthermore, I distinctly recall you complaining that ntpd's clock filter throws away 7 out of 8 polls; even though you are mis-interpreting the situation, you at least acknowledged that ntpd is keeping track of prior data. But it does not use them. It looks at the delays, and choses the shortest delay from the last 8 offset measurements. The scheme is a simple feedback system, which remembers the current drift and measures the current offset. That by current it means the offset with the lowest delay of the last 8 measurements does not alter the design. It is a Markovian system. It does not remember what the drift or the offset was 15 measurements ago, for example. If you really want to understand ntpd, read the documentation or Mill's book. Don't try picking apart a clearly very short descritption. delta r_i= alpha (remotetime_i - localtime_i) is the equation used, where delta r_i is the change in the rate of the clock, remotetime_i is the time as measured by the ntp exchange procedure of he remote clock, and localtime_i is the time on the local clock when that remote time was measured. alpha is a constant chosed to make the feedback loop be close to critically damped. In order to make the system resistant to varying assymetric travel times, they introduced another step. The i in the above is not every measurement, but the best of 8 (ie the one with the shortest delay, under the assumption that that will be the one with least assymetry in the travel path). But it also means that 85 % of the measurements are simply discarded-- never used to determine the clock offsets or delays or anything. So, ntpd loads the network with 8 times as many queries as it actually uses. If there are large variations in the delays on the two paths, this is probably as good as you can do. If there are not, this is a very wasteful procedure and means you throw away data that you could have used to better control your clock. Chrony remembers up to 64 past offsets and rates, and uses those in a linear regression to get the best estimate of the current offset and rate. It changes how long a memory it uses by estimating whether or not the a linear fit is a good approximation to that data series, and throws away old measurements until it does feel that a linear fit is a good estimate. It does not try to do assymmetric path corrections which might be a detraction of chrony in some situations (my measurements indicate it is not on the systems I have looked at at least, but there may be situations in which it might help). BEcause of the clock selection algorithm, and the conservative choice for alpha, ntpd responds very slowly to changes in the rates due to temperature changes for example. chrony is much faster, and I believe this is one of the reasons for the better control that chrony gives.
Re: [ntp:questions] Red Hat vote for chrony
On 2014-12-05, David Woolley david@ex.djwhome.demon.invalid 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 that were the only error, it would be eliminated exponentially with a time constant that is related to the poll rate. I believe it expects to update this correction well before it is fully applied. ??? Not sure what you mean by not true. ntpd corrects offsets by changing the rate. ntp corrects rate changes by seeing the cumulative offset changes and changes the rate to correct the offsets. At the same time, it applies a correction to the long term estimate of the frequency, with a much longer time constant. much more quickly than ntpd does, for the same poll. Remember that ntpd throws out 85% of the measurements it makes, in order to try (poorly) to If the round trip variability was sufficiently low that this pre-filter were not needed, any variations in the samples it is ignoring would be largely suppressed by the loop filters, which have time constants that are significantly longer than even eight times the poll interval. ntpd is heavily oversampling, which means that the min and maxpols quoted for chrony imply an even higher excess rate. Those quotes were simply wrong. to quote from the chrony docs 3.4.2 Typical configuration files. -- To illustrate how a dial-up home computer might be configured, example configuration files are shown in this section. For the '/etc/chrony.conf' file, the following can be used as an example. server 0.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline server 1.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline server 2.pool.ntp.org minpoll 5 maxpoll 10 maxdelay 0.4 offline ... Does that look any different from what ntpd recommends? Also from the same document (chrony.txt in the docs that come with chrony) 'minpoll' Although 'chronyd' will trim the rate at which it samples the server during normal operation, the user may wish to constrain the minimum polling interval. This is always defined as a power of 2, so tt/minpoll 5/ would mean that the polling interval cannot drop below 32 seconds. The default is 6 (64 seconds). 'maxpoll' In a similar way, the user may wish to constrain the maximum polling interval. Again this is specified as a power of 2, so tt/maxpoll 9/ indicates that the polling interval must stay at or below 512 seconds. The default is 10 (1024 seconds). Actually not true. How do you think the standards of the various contries determine the accuracy of their clocks. They have no better time standard to compare them with. And yet they confidently will quote accuracy figures for their clocks. Study that. I presume that whatever time transfer mechanism they use has well characterised errors. NTP operates in an environment where the errors are not well characterised. Not true. Remember that they are operating down at the sub nanosecond level, and if you think transfer even across the room is well characterized at that level, But anyway that comment of mine was not about transfer errors. It was a reply tothe statement that the only way of characterizing the uncertainty of clocks is to have one that keeps better time than the clock one is looking at. But to get back to the chrony vs ntpd: chrony operates in an environment where the errors are not well characterised as well. IF you are in an environment where there are large (factors of 2) changes in the travel times in each direction, the clock filter of ntpd might give better results. It is something that has not AFAIK been tested. I am not sure what the answer would be. HOwever, that is not true of most situations in which ntpd or chrony are used. The dominant error is temperature fluctuations in which the clock frequency wanders around. ntpd handles that badly. chrony handles it better. So do you use a system which maybe protects you better in unusual situations, or one wich handles the typical case better? chrony could be altered to try to estimate whether or not one is in a case where there are large fluctuations in the travel times giving fluctuating assymetries in the travel time, and if so apply something like the ntpd clock filter. But it would have to be pretty bad I think before it became necessary. It would be a good master's project for someone to do the comparison. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 05/12/2014 13:15, Martin Burnicki wrote: [] You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin Yes, I can see what you mean, but it was never a problem in practice. Likely these would be just for general office PCs, where the nearest minute would be good enough, let alone the nearest second! If something better was needed more care would be taken. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 11:47 AM, Paul tik-...@bodosom.net wrote: On Fri, Dec 5, 2014 at 9:37 AM, Charles Swiger cswi...@mac.com 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 make a number of assumptions. If you care about sub-millisecond time then you need to say that and the question should be answered in that context. 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. :-) I suspect most of the questions here refer to sub-second accuracy and most of the elaboration is unneeded. True; if you just want accuracy to the nearest second, you don't need to do anything elaborate to achieve that. Absent any other requirements, I think it reasonable for folks to target ~1 millisecond level of accuracy, which is quite doable on many platforms, even using remote timeservers over the WAN. If all your external clocks fail I suspect the typical user can depend on the disciplined virtual clock for days. For real hardware, sure-- once the intrinsic frequency drift has been setup, you can free-run for days into weeks without drifting too far. Cell phone towers (especially CDMA) are a decent example of such fault-tolerant systems. For almost all of human history, the sun or the fixed celestial heavens have provided the most accurate time reference available. Even today, we add (or subtract, in theory) leap seconds in order to keep UTC and UT1 aligned to better than a second courtesy of IERS. Yes, the USNO, CERN, and so forth now do have sufficiently high quality atomic clocks which have better timekeeping precision than celestial observations. I think there's some confusion here. Search for BIPM paper clock or read http://www.ggos-portal.org/lang_en/GGOS-Portal/EN/Topics/Services/BIPM/BIPM.html What confusion? Certainly it's a decent paper to read Such a point is orthogonal to the notion of how to measure a local clock I think this is an interesting question. How does one get high resolution measurements of the error in the virtual clock maintained with NTP (or Chrony)? I thought it was done with purpose built systems. Yes, you need to compare timestamps using purpose-built systems like a TCXO, Cesium, or Rubidium clock connected ideally via fast-interrupt driven parallel, serial, or network port which hopefully also provides hardware timestamping to minimize the processing latency. I don't expect a random version of Linux on generic hardware to be able to maintain the clock at nanosecond scale. True. I don't expect any version of Linux to perform at nanosecond scale, but that has as much to do with kernel bugs and compromises in timekeeping that particular OS has chosen. Even back in 2002 with very inexpensive commodity hardware, FreeBSD was able to achieve accuracy measured to ~260 nanoseconds: http://phk.freebsd.dk/soekris/pps/ ...per a Rb-based atomic clock. This is the sort of analysis I want to see for chrony. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 11:53 AM, William Unruh un...@invalid.ca 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 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 you acknowledge that your original statement was wrong. Just like your claim whether the chrony docs recommend using maxpoll=4 across the network to a LAN timesource or not was wrong? Just like your claim about whether ntpd cares about figuring out the local clock frequency or whether it only chases the offset was wrong? Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Fri, Dec 5, 2014 at 3:35 PM, Charles Swiger cswi...@mac.com 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 (-minded) configuration to keep a few clocks in sync. If all your external clocks fail I suspect the typical user can depend on the disciplined virtual clock for days. For real hardware, sure-- once the intrinsic frequency drift has been setup, you can free-run for days into weeks without drifting too far. Cell phone towers (especially CDMA) are a decent example of such fault-tolerant systems. c While perhaps strictly correct I was talking about the common crystal in a typical computer not the Cesium, Rubidum or OCXO in a cell site and there's really no basis for comparison. What confusion? Certainly it's a decent paper to read I misquoted. This Without measuring the local clock against some other clock or oscillator suggests comparing a clock to a better frequency reference but BIPM creates a virtual clock (with better Allen deviation) and everyone steers toward that. Perhaps you meant something else. Yes, you need to compare timestamps using purpose-built systems like a TCXO, Cesium, or Rubidium clock That wasn't my point. You need a purpose built NTP server to expose its virtual clock for comparison to an external frequency reference. Of course you need a purpose built reference but only in the sense that you'd use real counter rather than one in a voltmeter. 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 commodity. He also ran a particular install of BSD and a non-standard NTP. All of those are what I was referring to when I said purpose built system to measure the variance of an NTP disciplined virtual oscillator. By the way high resolution low-latency counters in computers have become commodity items. The software to use them -- not so much. It might be nice to conduct a similar experiment with Chrony but it's all pointless. As Bill suggests you want to measure typical performance in typical environments. That's the bit I said was interesting and I don't think the published numbers make it clear what's better. Frankly I suspect even that is pointless. If someone asked me how to do NTP on the cheap I'd say buy or build some number of Laureline-like PLLs in a box with a NTP packet emulator or some NTP servers off Ebay and run SNTP/OpenNTP on the clients. If you have a larger budget then buy Meinberg, Microsemi et. al. new. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net 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 commodity. No, he used a $1500 rubidium clock to accurately measure the timekeeping quality of a $220 Soekris computer, and concluded: I have earlier complained that no good and cheap hardware were available which could timestamp a PPS signal reliably and precisely but now the Soekris computer has proven that it does indeed deliver just that: With a pricetag of approx USD220 (single unit including enclosure) this is the best hardware you can find for a stratum 1 NTP server. If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably see an accuracy of around a microsecond, perhaps a bit worse depending on the timekeeping accuracy which the GPS puck provides. That was also the level of accuracy I was seeing from generic Intel hardware running FreeBSD as a stratum 1 with a GPS source. I've used a digital frequency counter which had an onboard TCXO (or possibly a DTCXO) for measuring. Although the frequency counter supported receiving higher-quality PPS timing from an external atomic clock, I've never had a Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy with it. He also ran a particular install of BSD and a non-standard NTP. I believe he ran FreeBSD 4.x and likely the ntpd from ports. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net 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 commodity. No, he used a $1500 rubidium clock to accurately measure the timekeeping quality of a $220 Soekris computer, and concluded: I have earlier complained that no good and cheap hardware were available which could timestamp a PPS signal reliably and precisely but now the Soekris computer has proven that it does indeed deliver just that: With a pricetag of approx USD220 (single unit including enclosure) this is the best hardware you can find for a stratum 1 NTP server. If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably see an accuracy of around a microsecond, perhaps a bit worse depending on the timekeeping accuracy which the GPS puck provides. That was also the level of accuracy I was seeing from generic Intel hardware running FreeBSD as a stratum 1 with a GPS source. I've used a digital frequency counter which had an onboard TCXO (or possibly a DTCXO) for measuring. Although the frequency counter supported receiving higher-quality PPS timing from an external atomic clock, I've never had a Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy with it. He also ran a particular install of BSD and a non-standard NTP. I believe he ran FreeBSD 4.x and likely the ntpd from ports. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On Dec 5, 2014, at 5:55 PM, Paul tik-...@bodosom.net 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 commodity. No, he used a $1500 rubidium clock to accurately measure the timekeeping quality of a $220 Soekris computer, and concluded: I have earlier complained that no good and cheap hardware were available which could timestamp a PPS signal reliably and precisely but now the Soekris computer has proven that it does indeed deliver just that: With a pricetag of approx USD220 (single unit including enclosure) this is the best hardware you can find for a stratum 1 NTP server. If you wanted to drive such hardware via a ~$40 GPS puck, you'd probably see an accuracy of around a microsecond, perhaps a bit worse depending on the timekeeping accuracy which the GPS puck provides. That was also the level of accuracy I was seeing from generic Intel hardware running FreeBSD as a stratum 1 with a GPS source. I've used a digital frequency counter which had an onboard TCXO (or possibly a DTCXO) for measuring. Although the frequency counter supported receiving higher-quality PPS timing from an external atomic clock, I've never had a Cs or Rb source, so I won't claim to have measured sub-microsecond accuracy with it. He also ran a particular install of BSD and a non-standard NTP. I believe he ran FreeBSD 4.x and likely the ntpd from ports. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-05, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: For internal systems I would want four servers minimum, two on-site, and two on the company WAN, I think that is ridiculous. Introducing too many safeguards often results in more failures due to extra complexity in the system. The problem with two is that if oneof the servers goes nuts-- for some reason starts to give out the wrong time (ie, its time is not UTC time) a. that will almost never happen b. that will be caught by the monitoring (e.g. nagios) and an alert will be sent and/or the system will be shut down automatically. Would it not be nicer is the alert is sent, but the system still keeps going and not shutting down? Shutting down a system seems like a pretty heavy price to pay for not having three instead of 2 sources. Of course your monitoring might catch this, or it might not, depending on whether you had thought of this failure mode when you set it up. So the clients could do this for days or weeks. Now if you do not care if the time jumps around by a second, then this is fine. Some places however need better time control than that. The monitoring for ntpd servers shipped by default with nagios has no problem detecting this. And when it does, what happens-- the company goes out of business? Noone cares? It also sends out for coffee and doughnuts for the IT team? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-05, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 05/12/2014 13:15, Martin Burnicki wrote: [] You may run into problems if your WAN connection has asymmetric delays, and thus to 2 servers on the WAN *seem* to have the same offset which differs from the offset provided by the 2 servers on the local network. Martin Yes, I can see what you mean, but it was never a problem in practice. Likely these would be just for general office PCs, where the nearest minute would be good enough, let alone the nearest second! If something better was needed more care would be taken. If you do not care about the time, you can do anything you want. I had the idea that this was about people who do care that their systems have the correct time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Red Hat vote for chrony
On 2014-12-05, Charles Swiger cswi...@mac.com wrote: On Dec 5, 2014, at 11:53 AM, William Unruh un...@invalid.ca 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 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 you acknowledge that your original statement was wrong. Just like your claim whether the chrony docs recommend using maxpoll=4 across the network to a LAN timesource or not was wrong? I have given you the quotes from the chrony docs. Where do you get your statement from? Just like your claim about whether ntpd cares about figuring out the local clock frequency or whether it only chases the offset was wrong? ntpd does not care about figuring out the local clock frequency. It simply adjusts the frequency to minimize the offset. That is all it does. Yes, the computer (or if you have a kernel which does not allow you to adjust the computer's frequency ntpd) does have a frequency. But no memory of that is kept. ntpd does not know what the frequency was before it currently adjusted the frequency, and especially not what it was 5 adjustments ago. Regards, ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
