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

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

> Before chronyd could slew or step the clock to zero offset as per the
> SHM refclock, the SHM and PPS refclocks could disagree and be both
> marked as falsetickers unless a third source would agree with SHM.
> 
> The lock option is meant to take the missing second of the PPS sample
> from the last sample of the target reference clock instead of the
> system clock.

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?

> Hm, maybe it would make more sense to introduce a new maxdispersion
> refclock option to ignore filtered samples and not update the variance
> statistic when the dispersion is too large? For the PPS refclock it
> could be by default 0.1 or so to prevent the original problem with
> chronyd ignoring the raw samples completely.

I'm not sure exactly where you want to do this check. The dispersion
calculated at the beginning of RCL_AddSample and RCL_AddPulse is
actually based on the average dispersion from the filter. I don't see
how rejecting samples when the filter result is too big will help making
the average dispersion lower, as you will get in the same deadlock
situation again. Rejected samples do not update the filter, so the
average dispersion will never get lower anymore.

The check in refclock.c:415 in my patch (ref_dispersion >= 0.5 / rate)
actually does a similar thing. It makes sure that the dispersion of the
given sample is not too high. Instead of 0.5 this could be a
configurable value. And we could introduce the alignment code again in
case the maxdispersion value is higher than 0.5.

> > To conclude my response, I still prefer my solution where PPS
samples
> > are rejected when the corresponding SHM samples look like outliers
as
> > they are more than 0.5 seconds off. Even if the SHM driver is
> > temporary unstable the PPS is still stable, and its dispersion
should
> > not be affected by the SHM driver. I could add the feature that when
> > the SHM driver itself is not selectable the alignment code is
> > activated again, as I suggested earlier in this mail.
> 
> I'm not sure, that sounds fragile to me. I'd rather avoid switching
> locking to refclock and system clock like that.
> 

Ok, I'll not further explore this option to enable alignment only when
the refclock is not selectable.

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.