[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gary E. Miller
Subject: Re: [gpsd-dev] Clarifications needed for the time-service HOWTO
Date: Wed, 23 Oct 2013 10:22:05 -0700

Yo Eric!

On Wed, 23 Oct 2013 11:40:20 -0400
"Eric S. Raymond" <address@hidden> wrote:

> > Should there be a note that the overall accuracy is affected by the
> > delay in the interrupt processing? It is very difficult to measure
> > and from some reports I've seen it's usually few microseconds.
> > Getting the synchronization stable to hundred nanoseconds doesn't
> > mean the clock will be also as accurate.
> The figure of "8 microseconds" for this has been tossed around during
> the discussion. I've debated adding language about this but am
> concerned that people might take it as a hard number rather than an
> order-of-magnitude indication.
> What do the assembled experts recommend?

Once again the absolute magniture of the delays if not important.  What is
important is the jitter.  I used to work in metrology, so I almst never
use the word accuracty.  Something is accurate only when you can compare
it to a known good source that is traceable to a national standards body.

We are just going for stability.

> > > 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.
> Gary, this sounds like reasonable criticism, especially about using
> the 'prefer' option rather than a crocky value for the fudge.  Respond
> please?

The howto already put prefer on the PPS.  I reject puytting noselect on
the NMEA time so it can be a last resoort fall;back.

> > > 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)?
> Gary, this one is for you too.

Answered in previous email.

> The assertion that chrony is easier to set up is Gary's.  Perhaps he
> will defend it.  What I will do is add a link to this comparison
> anyway; it looks very informative.

I suggest after we finish the ntpd section, we finish the crhronyd section
and then see how it falls out.

> > Similarly to ntpd, it's not necessary to use the NMEA time if PPS is
> > available.
> Gary says "Splitting these notifications allows ntpd to use its normal
> heuristics to weight them." Would you two please discuss this and
> arrive at a conclusion I can put in the HOWTO?

I think we just have two aproaches to the same problem with slightly
different priorities leading to slightly different solutions.  But
will be hapy to discuss in a single topic email.

> > The SOCK refclock is a replacement for SHM 1 as it serves only the
> > PPS data. If the time message data should be used too, the chrony
> > config should have a SHM 0 refclock line.
> Gary, would you please patch the configuration example appropriately?
> I'm afraid to get in the middle here.

Yes, but I want to finish ntpd first.  A lot of cooks in the kitcen so
let's stay focused and finish ntpd before mving to chrony.  If nothing
else I have limited test equipment and do not want to keep swapping

> I wasn't talking about large or asymmetrical but *variable*.  Are we
> really disagreeing here?

The term is 'jitter'.  Best to use a limited jargon and keep the synnyms
for just when we edfine the term.

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]