Paul G wrote:
> My question was -- given PPS clocks on the same network with ntpq offsets of:
> 0.021, 0.130, 0.064 and -0.046 -- any of which can be fudged away how do
> I determine the truth. That is how much is (consistent) hardware latency
> of any sort versus algorithmic restriction.
enable stats
statistics loopstats peerstats
If NMEA, configure the GPS(S) to only output one sentence e.g. $GPZDA
On one system at a time,
set the GPS and PSP RefClock to noselect, with time1 0 and time2 0
have several other NTP servers configured {I usually shoot for 6 to 10}
with all involved systems continuously running for more than one day;
take an average of the offsets for the last day for 127.127.20.x,
{or whichever GPS driver you are using} set the time2 for the GPS
After running for more than a day with time2 seeming ok,
take an average of the offsets for the last day for 127.127.22.x, set the
time1 for the PPS
Run for another day to see if the fudge times still seem fine,
change the Noselect(s) to Prefer and remove any excess servers that were
added.
{If the offsets / fudge times seem too large perhaps the PPS signal is
inverted?
set flag2 1, and run for more than a day (again).}
It seemed like David Taylor covered that on may 25th.
<https://groups.google.com/d/msg/comp.protocols.time.ntp/ftFngXfRtLU/MuHqVHuXJ_EJ>
--
E-Mail Sent to this address <[email protected]>
will be added to the BlackLists.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
