On 2015-02-14, Paul <tik-...@bodosom.net> wrote: > On Fri, Feb 13, 2015 at 8:48 PM, William Unruh <un...@invalid.ca> wrote: > > However you've not responded to my question regarding your deep concerns. > For years you've complained about the ntpd pll and on occasion suggested > chrony. Now a replacement is being developed. So why do you continue to > focus on what you consider to be defects in ntpd?
Because ntpd is what I know. I now run chrony exclusively (I used to use ntpd to get time from a Garmin gps but Miroslav Lichvar has done extensive work on chrony, and it now handles "refclocks" where it used not to do so). When I was testing things, I had the hope that the ntpd could incorporate the strengths of chrony into ntpd, and that one could at least have a discussion of the advantages and disadvantages of a "fitting" algorithm over a Markovian feedback loop, for example. And the possibility of using all measurements made instead of 1 in 8 as ntpd does. But there has been zero interest shown by the ntpd people in either of these. If you are saying that this is all up in the air again with the new replacement, that would be great. But I have seen no evidence thereof in discussions here. I would have expected people involved to discuss what the new design philosophy was, what they saw as the advantages and disadvantages of the various approaches, etc. I have not seen those discussion. Either they are taking place elsewhere than here, or they are not taking place, and the new is simply a repolishing of the old. Regardind the rate of convergence, clearly that will be vastly faster with a PPS refclock, which has not roundtrip time delay, vs the convergence from the net. As I recall, my tests were on the latter, not the former. I used a PPS clock to time and test the system, to get a handle on what the "true" offset of the system was. Clearly the convergence time of ntpd from the net, with its effective minpoll of 9 would be, and is, vastly longer than that from a PPS with an effective minpoll of 3. But most people use the net, not a local PPS source. To get the discussion started, lets compare some of the differences between chrony and ntpd. chrony uses a fitting algorithm to do a linear fit on the last N offset measurements to determine the current offset and drift. As such it averages over those last N measurements to reduce the uncertainty in that estimate of the offset and drift. Note that it it also compensates past measurements for current changes in the clock rate, so that those measurements are always on the basis of "If the clock had been running at the current drift when those measurements were made." It then alters the clock rate to eliminate that offset and to get the system to the correct drift rate of 1s/s. ntpd on the other hand alters the current drift to eliminate the currently measured offset. It retains no memory. It has no idea what the "correct" clock rate is. All it knows is that it must chase the current offset. chrony has an adaptive algorithm to determine N in the above. It tests the linear fit to see if the data supports the hypothesis that the drift rate of the clock has been constant over the N samples (It does so by looking at the distribution of offsets that lie above and below the line) If it feels that a linear hypothesis is not good, it reduces N until it is good. If it is good, it allows N to increase. The larger N the better the linear fit can eliminate random measurement fluctuations. ntpd has a clock filter algorithm. It remembers the past 8 measurements-- both offset and delay (roundtrip time) and choses the next useable measurement as that measuement of the past of the past 8 which has the smallest delay as a way of trying to eliminate assymetry in round trip delays. This is often silly. If round trip A is 1 microsecond longer than B on a 10ms roundtrip time, A will not be used, since B is shorter. But even if that 1 microsecond were completely one way, the harm to accuracy of the system clock to eliminating A is far larger than that harm of that "one way" delay. The advantage of statistics in reducing uncertainty outweighs the disadvantage of that tiny error in roundtrip. I suspect stongly that in most useages of ntpd, that is true. It may be that in certain situations, that clock filter helps, but I suspect they are rare. Chrony uses all measurements, except you can tell it to filter out measurements whose delay is larger than some multiple of the minimum delay over the past N measurements. It's hypothesis is that variation in the delay time is simply another random perturbation of the measurement which the linear regression can handle. The effect of those two differences is that chrony is much faster than ntpd is at noticing changes -- eg due to temperature changes. These are two of the main differences. Chrony in experiments I have done, and Lichvar has done, disciplines the clock a factor of 2 to 20 times better than does ntpd. Ie, the difference between the time on the computer's clock, and try UTC as measured by a gps pps has a fluctuation 2-3 times better, and Lichvar's simulations have found up to 20 times better discipline for chrony over ntpd. Even 2 times is huge. ntpd spends much effort (eg the clock filter algorithm or the huff and puff) to wrest much smaller improvements out of ntpd. And I suspect that one of the reasons for the better behaviour is chrony's faster response to change. It can respond to temperature cnanges (due to the computer being used hard suddenly, rather than sitting there idle overnight for example) quickly, and can thus eliminiate the difference between the computer time and true time much more quickly. Issues like this need discussion, and need research. One accusation thrown at chrony is that the stability of the system has not been thoroughly enough investigated. Are there situations in which chrony's algorithm could go unstable and deliver much worse results than ntpd? Stability of the algorithm was one of the key driving features that Mills used in designing it. I have never noticed chrony going unstable, but perhaps I have simply not used it in a situation where that instability would be triggered. Or, perhaps it is as stable, or more stable than ntpd. Research is needed, and such research should be part of any new system. Is it there? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
