paul at anastrophe.com
Wed Nov 20 22:33:43 UTC 2019
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.
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.
On 11/20/19 14:02, Richard Laager via devel wrote:
> 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:
> 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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel