Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Gary E. Miller]

Yo Andy!

Wow.  Very complete, but I would think beyond where this howto should go.

I would limit this howto to tellthing the user to adjust his fudge until
'ntpq -p' should his local PPS in agreement with good remote chimers.

Getting better than that probably requires renting a traceable standard
time source.

On Mon, 21 Oct 2013 08:34:47 -0400
Andy Walls <address@hidden> wrote:

> 
> 
> On Mon, 2013-10-21 at 08:00 -0400, Eric S. Raymond wrote:
> > Hal Murray <address@hidden>:
> > > 
> > > address@hidden said:
> 
> > TODO: more on performance tuning and diagnostics here. 
> > 
> > This is where we need to talk about (a) adusting fudges, and (b) how
> > to check the quality of your chimers.
> 
> WRT adjusting fudges:
> 
> http://lists.ntp.org/pipermail/questions/2011-November/030951.html
> 
> I happen to use the "calibrate by hand" method mentioned in the post.
> Open-loop is easier for me to follow.
> 
> I also have this cheat-sheet lying around for examining the data from
> open-loop tests:
> 
>         http://www.eecis.udel.edu/~mills/ntp/html/monopt.html
> 
>         loopstats:
>         clock offset (s)                offset
>         freq offset (PPM)               drift compensation
>         RMS jitter (s)                  estimated error
>         RMS freq jitter (PPM)           stability (aka wander)
>         clock poll constant (log2(s))   polling interval
>         
>         peerstats:
>         clock offset (s)                offset
>         roundtrip delay (s)             delay
>         dispersion (s)                  dispersion
>         RMS jitter (s)                  skew (variance)
>         
>         Show the PPS deviation from system clock. (Keep in mind that
> PPS is probably better than the NTP adjusted system clock.)
>         
>         gnuplot> plot    "peerstats.pps" using ($2):($5) with lines 1
>         gnuplot> replot  "peerstats.pps" using ($2):($5):($8) with
>         gnuplot> yerrorbars 2
>         
>         Show the GPSD shared memory clock deviations from the system
>         clock.  (You will get the GPSD shared memory clock fudge value
>         estimate from this data when NTP has converged to your
>         satisfaction.)
>         
>         gnuplot> plot    "peerstats.shm" using ($2):($5) with lines 1
>         gnuplot> replot  "peerstats.shm" using ($2):($5):($8) with
>         gnuplot> yerrorbars 2
>         
>         Check the tracking loop convergence (phase):
>         
>         gnuplot> plot    "loopstats" using ($2):($3) with lines 1
>         gnuplot> replot  "loopstats" using ($2):($3):($5) with
>         gnuplot> yerrorbars 2
>         
>         Check the tracking loop convergence (frequency):
>         
>         gnuplot> plot    "loopstats" using ($2):($4) with lines 1
>         gnuplot> replot  "loopstats" using ($2):($4):($6) with
>         gnuplot> yerrorbars 2
> 
> Note that I had run some grep commands to separate PPS peerstats from
> SHM peerstats.  Note that I also do not feed PPS to NTP via GPSD, but
> via a /dev/pps device unrelated to the serial port of the GPS (PPS is
> wired to a GPIO).
> 
> For estimating GPIO connected PPS fudge, an experiment in measuring
> GPIO IRQ latency is needed (something like this:
> https://github.com/scottellis/overo-irqlat )
> 
> 
> Regards,
> Andy
> 
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

signature.asc
Description: PGP signature