On 12/21/2015 11:20 PM, Hal Murray wrote:
address@hidden said:
So this at least suggests that ntpd is interpreting the PPS signal, but the
offset it pretty extreme. Any strategies for addressing that?
The offset may be accurate. It could also be triggering on the wrong edge.
There is a fudge flag to flip that.
What type of GPS receiver are you using? Most low cost units are crappy for
timekeeping.
It's a Trimble Condor C2626. We are using a Diamond Systems Hercules
III that has a built-in socket for this device.
Can you setup a few external servers? (If you mark the PPS and JSON
"servers" as noselect, they won't confuse the timekeeping but will collect
all the data for ntpq and peerstats.)
That should give you time that is accurate enough to sort out the PPS
polarity. Once you get that right, the PPS will probably be more accurate
than the network servers.
Yes, that's exactly the type of practical advice I was hoping for.
# ./ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
+default-103.cal 10.215.254.254 3 u 11 64 3 7.203
5.320 6.705
GPSD_JSON(1) .GPSD. 0 l 17 64 1 0.000
-468.39 0.977
PPS(1) .PPS. 0 l 15 64 3 0.000
-1.845 3.171
*sfl-border.ilan 131.215.239.14 2 u 14 64 3 1.948
-0.353 3.714
If I am reading this correctly, this says the JSON data is arriving
468 ms late (which makes sense). The PPS offset seems to be settling
in to be comparable to sfl-border.ilan.
I am adjusting fudge time2 to tune out the JSON offset and also
adjusting the priority of gpsd and ntpd to see if that improves the
variability. My current fudge line is:
fudge 127.127.46.1 time2 0.450 flag4 1
which *should* give me clockstats, but I don't see the output,
either on the console or the logfile. The manpage suggests there is
a separate clockstats file, but I have not figured out how that is
specified. [Is it just me, or is the ntpd configuration
documentation seriously sketchy?] Oh wait, monitoring...
working on it...
|