FreeBSD Security Advisory FreeBSD-SA-16:16.ntp

[Poul-Henning Kamp]

--------
In message <slrnni9e4l.27hm.naddy at lorvorc.mips.inka.de>, Christian Weisgerber w
rites:
>On 2016-04-29, Roger Marquis <marquis at 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 accuracy
>>> 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 at 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.