"David J Taylor" <david-tay...@blueyonder.not-this-bit.nor-this.co.uk.invalid> writes:
>"David J Taylor" ><david-tay...@blueyonder.not-this-bit.nor-this.co.uk.invalid> wrote in >message news:%xqgm.126$ym4...@text.news.virginmedia.com... >> "Unruh" <> wrote in message news:34jgm.50898$ph1.36...@edtnps82... >> [] >>> Note that chrony will give you a factor of 2 or three improvement over >>> ntp in the errors, assuming that the roundtrip is equally split on >>> Linux or BSD. >> >> For those without wide-bandwidth academic connections - those folks on >> cable or ADSL - how good is an "equal split round trip" assumption? >> >> David >Thanks, David, David and Jan. A few milliseconds is what I had expected, >so if you are on a consumer line, what implications does that have for >unruh's comment? >Cheers, >David Which comment? chrony still seems to do better, in this case it seems because it uses more data to estimate the slope and offset. Essentially ntp only uses about two or three data to do the estimate (It throws away 80% of the measurments in the clock filter algorithm in an attempt to mitigate the round-trip split problem), and has a time constant-- averaging time-- then only a few times larger than the effective interdata time. chrony uses up to 60 data points ( if things are very stable other than random fluctuations) and down to 3 (if the rate is changing rapidly). The two programs have very different design philosophies. Chrony has a relatively complex algorithm while ntp has a very simple second order feedback loop algorithm at its heart. chrony saves n past measurements and uses them to estimate the slope and offset of the current time. Those n measurements of offset are corrected for any change in rate or time of the clock. That of the number of data points, n, also breathes, with n being made small if the linear fit to the data gives evidence of being bad ( it uses the number of sign changes in the residuals to determine if the fit is within expected of the statistical noise or not). This allows it to adjust rapidly to rate changes, while still given much better statistical averaging than ntp when the clock is stable. All of these things result in significantly improved performance of chrony over ntp. Of course for most people, An improvement from 50us accuracy to 20usec is irrelevant, since all they want is their clock to be accurate to a few seconds. And if the line really results in large assymmetries in the transit time, then neither can get a good estimate. (chrony can be tuned to reject delays x times larger than a minimum delay, to act like ntp's clock filter if you have trouble with occasional large asymmetric delays, while not throwing out perfectly good data points which just happen to be 1 microsecond slower than the lowest recent delay.) _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
