Yo Richard! On Sat, 23 Nov 2019 23:08:06 -0600 Richard Laager via devel <devel@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 g...@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
pgp6ydEnWwoM_.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel