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

[Miroslav Lichvar]

On Wed, Oct 23, 2013 at 10:10:15AM -0700, Gary E. Miller wrote:
> 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.

That text talks about renicing gpsd, not ntpd. With KPPS the time
stamp is made in the kernel and it shouldn't matter if gpsd is delayed
before processing the time stamp and updating the SHM segment. ntpd
looks at it only once per second anyway.

> > 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.

It doesn't throw away the data, they are processed in a median filter
and the result is used to update the clock.

> > > 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.

But do you really want that fallback? If the clock was well
synchronized, letting it drift is usually a better option than
switching to a NMEA source, let alone one with purposely wrong fudge.

Also, it increases the chance that it will with another bad source
outvote a good source.

-- 
Miroslav Lichvar