<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Just a shot in the dark, but it looks to me like an errant
overly-greedy cron job or systemd timer - perhaps something else is
polling the serial port on a schedule. If you set up hourly graphs
you might be able to correlate it with something else firing on the
server at those intervals.<br>
<br>
Unfortunately the spikes don't line up with uniformity within the
two hour intervals of the graph, so my theory could just be a
rabbit-hole.<br>
<br>
<div class="moz-cite-prefix">On 11/20/19 14:02, Richard Laager via
devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1b30271f-cbcf-ccd5-ec3e-4b2af11df003@wiktel.com">
<pre class="moz-quote-pre" wrap="">I now have a second stratum 1 server, with an independent setup. This
allows me to compare the two. Why does ntp1 have this very specific
repeating pattern of local clock offset? It's roughly +7 us, -5 us, +2
us, -4 us and then repeats again, over and over. We can also see that in
the histogram, which has three local peaks, as opposed to ntp2's which
looks like a normal distribution.
Here are the two NTPviz URLs:
<a class="moz-txt-link-freetext" href="https://ntp1.wiktel.com/day/">https://ntp1.wiktel.com/day/</a>
<a class="moz-txt-link-freetext" href="https://ntp2.wiktel.com/day/">https://ntp2.wiktel.com/day/</a>
The server hardware is the same... same chassis, same motherboard, CPUs,
etc. Both have their respective PPS connected via a motherboard serial
port. Both are running Ubuntu 18.04 with NTPsec 1.1.7.
They are in different buildings. The hand-picked network servers they
reference are slightly different, but I don't think that's relevant here.
ntp1 uses the PPS refclock with a polling interval of 3 from a telecom
GPSDO (OCXO):
server 127.127.22.0 minpoll 3 maxpoll 3 prefer
fudge 127.127.22.0 refid PPS
ntp2 uses the SHM refclock with a polling interval of 1 from a ublox 7
timing evaluation kit via gpsd:
server 127.127.28.2 minpoll 1 maxpoll 1 prefer
fudge 127.127.28.2 refid GPS
I could try fiddling around with the polling interval. Next steps might
be to try raising the polling the interval to 4 and/or lowering it to 1.
The driver_pps documentation states, "This driver incorporates a good
deal of signal processing to reduce jitter using the median filter
algorithm in the driver. As the result, performance with minpoll
configured at 4 (16 s) is generally better than the kernel PPS discipline."
Another idea might be to switch to the PPS refclock on ntp2 to see if it
behaves similarly with the ublox PPS.
Before I start blindly flailing about, does anyone have recommendations?
As a second question, if you look at the ntp2 weekly graphs, there is a
single huge transient. Any idea what that might be? I've seen these
about once or twice a week since I put this in a couple weeks ago:
<a class="moz-txt-link-freetext" href="https://ntp2.wiktel.com/week/">https://ntp2.wiktel.com/week/</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Paul Theodoropoulos
<a class="moz-txt-link-abbreviated" href="http://www.anastrophe.com">www.anastrophe.com</a></pre>
</body>
</html>