Date: Sat, 30 Apr 2016 14:27:17 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Christian Weisgerber <naddy@mips.inka.de> Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Message-ID: <46858.1462026437@critter.freebsd.dk> In-Reply-To: <slrnni9e4l.27hm.naddy@lorvorc.mips.inka.de> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <CINIP100NTSBSRqf69a0000002a@cinip100ntsbs.irtnog.net> <BABF8C57A778F04791343E5601659908237051@cinip100ntsbs.irtnog.net> <201604300015.u3U0FB3k058050@lorvorc.mips.inka.de> <slrnni9e4l.27hm.naddy@lorvorc.mips.inka.de>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <slrnni9e4l.27hm.naddy@lorvorc.mips.inka.de>, Christian Weisger= ber w rites: >On 2016-04-29, Roger Marquis <marquis@roble.com> wrote: > >>> While I cannot speak for anyone other than myself, the two simply aren= 't >>> equivalent. As a conscious design choice, OpenNTPD trades off accurac= y >>> for code simplicity. >> >> IIRC openntpd is accurate down to ~100ms. > >I have no idea where you get that absurd number from. OpenNTPD is >accurate at least down to 1 ms. I don't have better time sources. Uhm.... So I hate to be pedantic, but "accurate to 1msec" means: Clock is UTC+/- 1msec = The "accuracy" you claim, and the numbers you report to back it up means: Clock is within 1 msec of half the filtered RTT the chosen peer. By pure chance your clock might be accurate to 1msec, but you have no way of knowing from the numbers you report, and it is virtually impossible to prove without a GPS or similar non-network time source. If the numbers you report always look like that, it would be correct to claim that it "can track to within 1msec". But don't worry: Accuracy is not the important part of timekeeping anyway. Stability is far more valuable than accuracy, because you can compensate inaccuracy with any desired precision, but there is only the genuine article when it comes to stability. If your peer-offset is always less than a millisecond, chances are good that you are yanking your clock around to track changes in network delay which ruins both stability and accuracy. The best explanation of all this is John R. Vig's Quartz Tutorial which is freely available on the web - highly recommended: http://www.am1.us/Local_Papers/U11625%20VIG-TUTORIAL.pdf Poul-Henning -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46858.1462026437>