NTP Performance

[Gary E. Miller]

Yo Richard!

On Sat, 23 Nov 2019 23:08:06 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> It looks like you're talking about clock_test.c.
> Below are ten runs from ntp1. 

> min 39 ns, max 120 ns, mean 89 ns, median 96 ns, StdDev 18 ns

A min/max spread of almost 100 ns.  Now you see why I say the
NEO-M8T is a waste in this application.

KPPS will, of course, give better performance setting the system clock,
but cannot help when reading it.

It also shows why getting a PPS that is 5, 10 or 15ns better is lost
in the noise.

> and ntp2:
> min 30 ns, max 111 ns, mean 58 ns, median 60 ns, StdDev 11 ns

Similar.

> > 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.

I agree, for you.

> What is the counter argument
> about why I should care about frequency?

Radio operators do not care so much about the time, but they really care
that they are on the proper frequency.

Another way to look at it: More accurate time means you are jumping your
CPU time around to chase the PPS time.

So if you were measuring some critical short time duration, then you want
to favor stable frequency (seconds) and not time reference to USNO.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20191124/6e75bd9a/attachment.bin>