"David J Taylor" <david-tay...@blueyonder.not-this-bit.nor-this.co.uk.invalid> writes:
>"Unruh" <unruh-s...@physics.ubc.ca> wrote in message >news:qg_gm.50009$db2.46...@edtnps83... >> "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? >The one I quoted: >"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." >On consumer-grade circuits the assumption about equal round trip is >unlikely to be valid. As I said, chrony does a linear regression on the last n offsets. If those n offsets are all displaced by 1 sec because the outbound packets all suffer a 1 sec delay while the inbound ones do not, then the absolute time will be out by 1 sec. This is true for chrony and for ntp, and there is nothing that can be done about it. If the packets occasionally suffer a 1 sec delay but usually are the same as an inbound, then ntp will probably eliminate those via the clockfilter. Chrony can also be setup to eliminate packets whose roundtrip times are x times the lowest value found for the roundtrip, where x is settable in /etc/chrony.conf. which will also eliminate those 1 second guys. (ntp's algorithm is stupid because it eliminates 80 % of the packets, even if the excess delays are say 10% of the total delay, and keeps them even if the delay is 100 times the minimum if all of the last 8 have been in that boat. chrony's algorithm uses the minimum value of the delay over long time scales, so that if random symmetric delay noise increases many valid packets can also be thrown out. ) Asymmetric delays are something that all time systems have trouble with, and at some level there is nothing that can be done about it. Given that problem, one then needs to look at chrony and ntp's use of the data that is actually collected and ask which makes the best use of that data to estimate the rate and offset of the local clock. I think that it is clear that chrony does a far better job. Whether there are situations in which it does a worse job, I do not know, but have not been able to think of any, but that may say more about me than about chrony or ntp. ntp has had the advantage of a long history of testing in a very wide variety of situations. chrony has been out there for about 10 years, but has not been as extensively tested in adverse situations. It used to be that chrony also had the disadvantage that it did not handle leap seconds. (Ie once very few years, it would suddenly find itself out by a second and have to slew the clock for the next hour or less to correct that-- if not warned by the leapsecond flag, ntp would either step the clock (with the concomitant problems for filesystem timing), quit entirely, or take many many hours to correct the problem by slewing. ie the uncorrected leapsecond was far less of a problem for chrony than for ntp) It also did not handle any refclocks. Both of these problems have now been corrected by M Lichvar in the git repository. (chrony.tuxfamily.org) The other problem is that chrony runs only on Linux or BSD. It does NOT run on Windows. That would require a pretty extensive rewriting. Curnow got started on this ( and kept chrony very modular to try to make this easy) but it is still a big task. >I hope that David Lord can make some tests, and I await the results with >interest. >Cheers, >David _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
