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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Mon, May 19, 2014 at 09:47:03AM +0200, Hattink, Tjalling [FINT] wrote:
> > I think the alignment code is necessary to allow offsets larger than 1
> > second, if the code is removed the PPS offset could be off by a whole
> > number of seconds and chronyd will not be able to correct a large
> > initial offset on start. Also, I'm not sure if we want to allow
> locking
> > to a source if the two dispersion together are larger than 0.5, the
> > offset could be again off by a number of seconds.
> 
> The PPS clock will indeed not correct a large offset, but the refclock
> (which is also listed as a valid source in the configuration) that is
> locked to the PPS will be accepted and correct any initial large offset.
> After that has happened the PPS clock should be within half a second of
> the refclock and will be accepted. So I don't think the alignment code
> is needed for this situation.

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.

> I tried the scenario where the PPS is locked to the system clock. When I
> generate SHM outliers the root dispersion of the system clock increases
> a lot, and although the PPS is still accepted it will probably take
> hours before the root dispersion is lowered again to the dispersion of
> the PPS. So even though the PPS is very stable (20 us dispersion), the
> root dispersion published to other NTP clients is high (100 ms
> sometimes). When PPS is locked to the SHM clock the root dispersion
> published is much closer to the PPS dispersion, which I think is a more
> close to the truth.

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.

> When outliers are inserted in the variance statistics filter, are those
> rejected or always accepted by the filter? If they would be rejected the
> filter would jump that much in the beginning and publishing a high
> dispersion for such a long time.

They are always accepted in the current code. The maxdispersion option
would prevent that.

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

-- 
Miroslav Lichvar

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