[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
configurations.
> 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.
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
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, (continued)
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/24
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Hal Murray, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/23
- Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Beat Bolli, 2013/10/23
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Miroslav Lichvar, 2013/10/23
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Hal Murray, 2013/10/23
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/24
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/24
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Eric S. Raymond, 2013/10/24
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Gary E. Miller, 2013/10/24
Re: [gpsd-dev] Clarifications needed for the time-service HOWTO, Harlan Stenn, 2013/10/24