NTP Performance

[Richard Laager]

On 11/23/19 8:19 PM, Gary E. Miller via devel wrote:
> There is a gpsd program in the contrib/ directory.  It tests your
> CPU granularity.  On a Raspberry Pi that is about 52 ns.  Worse
> on an Intel chip.

It looks like you're talking about clock_test.c. I grabbed the version
from gpsd git:
https://gitlab.com/gpsd/gpsd/blob/master/contrib/clock_test.c

Below are ten runs from ntp1. They all start with this, of course, so I
have stripped the duplication for easier comparison:
samples 101, delay 10000000 ns

min 39 ns, max 120 ns, mean 89 ns, median 96 ns, StdDev 18 ns
min 50 ns, max 111 ns, mean 88 ns, median 90 ns, StdDev 13 ns
min 33 ns, max 105 ns, mean 65 ns, median 63 ns, StdDev 11 ns
min 36 ns, max 111 ns, mean 88 ns, median 90 ns, StdDev 14 ns
min 54 ns, max 126 ns, mean 99 ns, median 102 ns, StdDev 12 ns
min 54 ns, max 117 ns, mean 85 ns, median 93 ns, StdDev 17 ns
min 42 ns, max 105 ns, mean 65 ns, median 66 ns, StdDev 9 ns
min 45 ns, max 120 ns, mean 97 ns, median 96 ns, StdDev 10 ns
min 45 ns, max 111 ns, mean 89 ns, median 93 ns, StdDev 14 ns
min 42 ns, max 111 ns, mean 93 ns, median 96 ns, StdDev 13 ns

and ntp2:
min 30 ns, max 111 ns, mean 58 ns, median 60 ns, StdDev 11 ns
min 33 ns, max 117 ns, mean 78 ns, median 87 ns, StdDev 18 ns
min 51 ns, max 120 ns, mean 84 ns, median 88 ns, StdDev 14 ns
min 57 ns, max 111 ns, mean 94 ns, median 93 ns, StdDev 10 ns
min 36 ns, max 117 ns, mean 79 ns, median 72 ns, StdDev 20 ns
min 42 ns, max 111 ns, mean 86 ns, median 93 ns, StdDev 16 ns
min 50 ns, max 108 ns, mean 90 ns, median 92 ns, StdDev 10 ns
min 30 ns, max 114 ns, mean 78 ns, median 87 ns, StdDev 17 ns
min 45 ns, max 117 ns, mean 88 ns, median 93 ns, StdDev 14 ns
min 48 ns, max 111 ns, mean 86 ns, median 87 ns, StdDev 11 ns

These both have the following CPU (which is older):
Intel(R) Xeon(R) CPU           X5460  @ 3.16GHz

>> Now, if the computer is more accurate
>> for short durations,
> 
> Never gonna happen with current CPUs.
> 
> The tradeoff is between time and frequency.  Short poll leads to more
> "accurate" time.  Long poll leads to more "accurate" frequency.

Makes sense. To me, it seems obvious that I should care about time, not
frequency. Am I missing something? What is the counter argument about
why I should care about frequency? This might be a question for Achim,
who seemed to suggest I should use a longer pollling interval?

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20191123/73188f1b/attachment.bin>