I have a server using the SHM driver for which pool.ntp.org always shows a negative offset of around -3 to -8 ms.
Based on that information, should I use a time1 fudge factor on the SHM driver to try to center that offset spread around 0 on pool.ntp.org? Alternately, is it expected that “healthy” servers can have a nonzero average offset reported by pool.ntp.org, and that attempting to force a time1 offset would actually decrease the accuracy of time provided by my server?
I’m asking because there’s talk (e.g. this thread) about fudging SHM0 but I’m talking about fudging the SHM1 pps unit, which seems dangerous.
In short, I’d prefer to have all the green dots clustered around the x-axis on the offset graph, but I don’t want to make my server’s time worse to achieve that. Hope that makes sense. Thanks!
You mean negative offset like this? (Forget the score; tw pool drops to < 4 IPv4 servers recently so I cannot avoid being overloaded.)
I don’t think you should fudge SHM1. Where is your server? Network condition from monitoring node to your server may add to the offset, which is normal. And you cannot make sure that the monitoring node is more accurate than GPS signal.
Calibrating SHM0 against a number of high-quality time sources, and then offsetting based on the average difference, is not only quite normal - it’s essential. Both SHM1 and SHM0 are in scope, but I would indeed expect the SHM0 offset value to be very minimal, so I’m not sure what’s going on there.
Instead of fudging, you should be looking at the “time1” parameter. See the performance section of the GPSD timeservice HOWTO for one approach.
There are two key concepts:
Temporarily limit your peers to a few high-quality (stratum 1) sources, and
Get enough samples over time to get a solid average (like a day)
Once you calculate your local offset, you use the time1 parameter to apply it. Here is an example, my own SHM0 configuration line, for a Pi with a Uputronics hat (and yes, that really was the calculated offset):
I would have provided a link the howto (that part was written mostly by Gary Miller / GEM of some time-nuts renown), but apparently someone (or an automated process) thought it was advertising something and flagged it. Here’s the snippet of awk that can be used to calculate the average from the peerstats file:
awk '
/127\.127\.28\.0/ { sum += $5 * 1000; cnt++; }
END { print sum / cnt; }
' </var/log/ntpstats/peerstats
You’d have to have peerstats logging enabled and adjust the script to match wherever your logs go, of course.
Thanks, Tycho! The offset is indeed minimal … the graph above shows what pool.ntp sees, and on average my non-gps peers consistently report small offsets in one direction as well. I just wanted to start this thread as a sanity check on whether trying to adjust that is reasonable.
Your quotes bring up some other things though. First of all, I think SHM1 is the more precise PPS unit, right? You mention SHM0 above, which I have some comments about not needing after gpsd v2.95 or so.
