[ntp:questions] PHK on Ntimed and Chrony

William Unruh unruh at invalid.ca
Sun Feb 15 18:37:53 UTC 2015


On 2015-02-15, Paul <tik-tok at bodosom.net> 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.





More information about the questions mailing list