RE: [chrony-dev] PPS reference clock rejected because of high dispersion

["Hattink, Tjalling [FINT]" <T.Hattink@xxxxxxxx>]

> On Tue, May 20, 2014 at 01:51:59PM +0200, Miroslav Lichvar wrote:
> > On Tue, May 20, 2014 at 11:41:39AM +0200, Hattink, Tjalling [FINT]
> wrote:
> > > When the offset between the PPS and SHM clocks is bigger than 0.5
/
> > > rate the PPS samples are rejected. So if both refclocks disagree
> > > only the SHM will actually publish samples. This shouldn't mark
the
> > > SHM refclock as falseticker right?
> >
> > Not sure where exactly is this coming from, but with your patch I'm
> > seeing this:
> >
> > sources.c:711:(SRC_SelectSource)[20-10:58:03] Can't synchronise: no
> > majority sources.c:913:(SRC_SelectSource)[20-10:58:35] Selected
> source
> > PPS1 sources.c:711:(SRC_SelectSource)[20-11:21:50] Can't
synchronise:
> > no majority sources.c:913:(SRC_SelectSource)[20-11:22:06] Selected
> > source PPS1 sources.c:711:(SRC_SelectSource)[20-11:39:12] Can't
> > synchronise: no majority sources.c:913:(SRC_SelectSource)[20-
> 11:39:44]
> > Selected source PPS1 sources.c:711:(SRC_SelectSource)[20-11:41:37]
> > Can't synchronise: no majority
> > sources.c:913:(SRC_SelectSource)[20-11:41:53] Selected source PPS1
> 
> It seems I didn't set the delay option correctly for this test and the
> SHM source (NMEA from gpsd) didn't overlap with PPS occasionaly. So,
> your patch will work if PPS samples are dropped until chronyd selects
> SHM, but this is similar to not using the lock option except the PPS
> samples are not accepted when SHM stops.
> 

And that is exactly what I'm trying to achieve, the PPS not being
accepted until the SHM source is stable, accepted and within range of
the PPS with timestamps derived from local clock.

What I understand is that you have a slightly different meaning for the
lock directive, maybe my scenario should be a different setting than
"lock"? Maybe call it "relate"?

So "relate" will mean the PPS is only accepted when the related refclock
is accepted, but timestamps are still derived from the local clock, and
"lock" will mean the PPS timestamp are derived from the related
refclock. What do you think of this?

Best regards,

Tjalling Hattink


--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.