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

[Gary E. Miller]

Yo Miroslav!

On Thu, 24 Oct 2013 11:43:24 +0200
Miroslav Lichvar <address@hidden> wrote:

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

The sample commmand line does start ntpd nice'd.

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

Yes, but the NMEA must be decoded by the CPU and those delays also
are minimized by being nice'd

> ntpd looks at it only once per second anyway.

No, nptd looks at it once per minpoll.

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

More often than minpoll?  That is not what the man page says.
>
> > > > 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.

In practice I find that being 20mSec off is much less than the NMEA
jitter.  So it is only used as a last resort.  YMMV.

I changed the document last night to mention both strategies.  I have
found mine works best in the real world for me.

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

Never had that happen.  The high jitter makes is a last resot choice.

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