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

[Gary E. Miller]

Yo Miroslav!

On Wed, 23 Oct 2013 14:41:50 +0200
Miroslav Lichvar <address@hidden> wrote:

> > 2. gpsd will be unable to renice itself to a higher priority.  This
> > action helps protect it against jitter induced by variable system
> > load. It's particularly important if your NTP server is a
> > general-use computer that's also handling mail or web service or
> > development.
> 
> Does this matter with KPPS? Probably not.

Yes, it does.  Remeber we are building a Stratum 1 here.  So the speed with
which the localhost responds to requests is part of the latency seen by the 
Stratum 2's.

> Why is the message time source used when PPS is available? It works
> with PPS alone, but the extra source might improve the robustness if
> PPS goes bad. With the noselect option it might be useful for
> monitoring.

Yes, good for monitoring and good for robustness.

> > With this configuration, ntpd will read the timestamp posted by gpsd
> > every 64 seconds (16 non-root) and send it to unit 0. 
> 
> IIRC ntpd reads the SHM segment once per second (root or not). The
> minpoll and maxpoll options control how often are the collected data
> processed and used to update the clock.

A difference without distinction.  If ntpd reads SHM, and throws away the
daya, the end resuts is still the sae.

> Should there be a section on
> tweaking the minpoll and maxpoll options? The optimal poll interval
> depends on how stable is the system clock and how noisy is the time
> source.

I would call that an advanced topic and the builtin defaults auto tune
pretty well.

> > To keep ntpd from preferring NMEA time over PPS time you can add an
> > over large fudge to the NMEA time.
> 
> That sounds like a bad advice to me. If you don't want ntpd to use the
> NMEA time, don't put it in the config or add the noselect option or
> add the prefer option to the PPS source.

By using a large offset we basically tell ntpd to ignore it unless it is
the last resort.  noselect prevents that ultimate fallback.

> > You should always have at least two fallback chimers in your
> > ntpd.conf for proper ntpd operation, in case your GPS fails to
> > report time. And you'll need to adjust the offsets (fudges) in your
> > ntp.conf so the SHM(1) time is consistent with your other reference
> > clocks. We'll
> 
> Shouldn't that be SHM(0)?

No, as just discussed, we want SHM(0) to be a last resort.

> > chrony is an alternative open-source implementation of NTP service,
> > originally designed for systems with low-bandwidth or intermittent
> > TCP/IP service.  It interoperates with ntpd using the same
> > protocols,
> 
> Interoperates with gpsd?

Yes, better than ntpd in many ways.  After the ntpd is nailed down
I will work on that part of the howto.

> > gpsd can provide reference clock information to chronyd similarly to
> > the way it talks to ntpd.  The advantage to using chrony is that the
> > PPS time resolution is in nanoseconds.  This is 1,000 times more
> > precision than the microsecond time resolution provided to ntpd.
> > When gpsd supports the new ntpd protocol this difference will
> > disappear, but chronyd is still simpler to set up.
> 
> I don't think chronyd is simpler to set up, its configuration file is
> very similar to ntp.conf. But there could be other advantages and
> disadvantages of using gpsd with chronyd instead of ntpd. Link to
> http://chrony.tuxfamily.org/manual.html#Comparison-with-ntpd ?

Hold that thought.  When we get to chronyd we'll get specific.  Already
enough balls in the air for our set of volunteers.

> > Note that a chimer can be a poor performer (what the inventor of NTP
> > whimsically calls a "falseticker") for either of two reasons. It may
> > be shipping bad time, or the best routes between you and it have
> > large latency variations.  (Large but fixed latencies can be
> > compensated out using a fudge.)
> 
> A source will be marked as falseticker only if it serves bad time or
> is outvoted by multiple sources with incorrect time, not when the
> delay is large or asymmetrical, because the large delay is included in
> the intervals used in the NTP source selection algorithm.

esr specifically said he would avoid getting into the nitty gritty of ntpd 
voting.  But yes, it could be made clearer that high jitter, not high latency,
if the defect.

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