[email protected] (Rob Neal) writes: >On Fri, 20 Mar 2009, Unruh wrote:
>> [email protected] (Rob Neal) writes: >> >>>> >>>> It almost seems like a religious group. Most people try to convert >>>> the world to Mills' NTPD, and then there is the dissident who tries >>>> to push Chrony in every thread. >>> Chrony has an impulse response that is ill-advised in >>> a network of NTP servers. It's really rather crude, IMHO. >> >> An interesting claim. What is it about the chrony impulse response that you >> do not like and why is it "ill-advised" in a network of ntp servers? I >> really am interested in the answer. I would think it is far less crude than >> is ntpd, but would love to understand your reasons. > The slew rate. NTP limits the slew rate to 500 PPM, > for purposes of error bound analysis and conformance > to common software constraints. It is, in the end, > a PLL. > Chrony does not appear to have either such analysis > of errors, nor a bound on the slew rate. > If you have no bound on the slew rate, then > you cannot make mathematical statements about > the response to transient inputs - such as the time > to amortize an offset. > If one cannot bound, via mathematics, the transient > response, then how can one constrain the loop > stability? > And if one cannot bound or define the loop stability, > then its use in a large network of like performers > becomes problematic. How does one bound the > oscillation between partners, under these conditions? > It may be that these questions have practical answers, > disjunct from the analysis, that are perfectly adequate > in practice. I have seen no such demonstration, so I > prefer the bounds within NTP. These have been supported > by extensive analysis, and practical deployment. > Perhaps not perfect for all purposes, but usable. > I would expect that for leaf nodes, Chrony would be > a totally acceptable solution, with characteristics > that would make it attractive to a large number of > system administrators. > Does this answer address your concerns? > Regards, > Rob Thank you. It certainly explains your thinking. I do not believe it is a problem, but I have been trying to squeeze in such an analysis of chrony. First, I think getting some sort of refclock support into chrony, even if just shm is a more important step, and have not found the time for it. When one is changing a program written by someone else, there is a lot of puzzling one has to do before making changes. NOte that ntp will far more often hit the 500PPM bound than does chrony because of its very poor (Ie, slow) transient response to rate transients. Chrony can go above 500PPM for large offset transients, but offset transients are rare because the temperature affects the rate not the offset. (Also for large offset transients >128ms, ntp goes to an infinite rate model. It simply resets the clock, or stops altogether, a far more drastic behaviour than chrony ever displays). The response to multiple servers and jumping between them is an interesting question. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
