On 2015-02-15, Paul <[email protected]> wrote: > I'm not completely convinced this is relevant to this list but I'm loath to > paraphrase, restate, summarize or condense the Ntimed notes so quoting PHK < > https://news.ycombinator.com/item?id=8781435>: > > "I'm not keen on saying too much about Chrony, I'd rather let people > without a stake in the game provide comparisons. > > But obviously: if I had throught it was just the thing, I wouldn't have > started writing Ntimed. > > I also don't expect Ntimed to out-compete Chrony, and if it did, I'd have > to start a fourth alternative myself, to keep competition healty. > > A very large part of NTPDs problem was that there were no competition, > which meant that everything got crammed into NTPD, come hell or 300KLOC. > > We saw this also with GCC, which had become a stagnated arrogant monopoly, > and suddenly LLVM forced them to care about users again. > > Having competing projects is good thing, and I hope Chrony sees things that > way too."
I agree entirely with the above. I think it is a great thing. But I also would not just like competition but also an analysis of why one or the other is better or worse, what the comparison is, and if B is better than A in some area, then C will use B's ideas rather than A's. As I have said, I believe the chrony's use of adaptive linear fitting is a better idea than ntpd's simply Markovian feedback loop-- it is both faster and more accurate. I also think ntpd's clock filter is horribly wasteful. I am not that much of a fan of chrony's crude "if the delay is bigger than x times the minimum throw it away" either, but it is sure less wasteful of precious measurements. I would love to see some new ideas there of how to protect against one way delays distorting the time signals, while still using as many of the measurements as possible to beat down the inevitable random perturbations. I like ntpd vast array of refclock drivers, and the relative ease with which they can be incorporated into ntpd. I like chrony's ease of using intermittent time sources and also its disciplining of the rtc as well as the system clock, although it is not as useful as it could be since the rtc is greatest use when the computer is shut off and cold, while the estimate of it drift rate is done while it is running and hot. Are there any ideas as to how that could be better done than it is in chrony? Those are all ideas which I would love a new system to consider, and thrash through. Are there instances where ntpd goes unstable? (The suggestion here was that it did sometimes if the temp changed too rapidly). Is chrony's fitting algorithm stable ( as it seems to be) or are there situations where it goes kablooie? Etc. The main reason why I keep pushing chrony is precisely because it is an alternative, not just in its code base, but in its whole design philosophy, and I would love to have the best of both worlds in a time discipline program. Maybe ntimed will be it. I would love to see discussion of it here, not just in some tiny little developers list. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
