Re: [chrony-users] Strange "loss of PPS lock"

[Rob Janssen <chrony-users@xxxxxxxxx>]

Miroslav,

No the PPS for sure did not lose lock.  These are either professional GPSDO
sources or we have that extra lock source, and it happens in both cases.
What SURE could happen is that those NTP sources collectively drift to
some offset relative to the PPS due to asymmetric network delay, but
in that case the PPS still is the correct reference.

How it should work: on powerup or upon total loss of lock, it should first
lock in on the NTP sources to get the system clock accurate to within
a few hundred milliseconds, so that the PPS is unambiguous.  Then, it
should lock to the PPS and remain locked unless its "lock" source goes
out of lock, in which case the NTP sources can be used as a backup.

When a PPS source is marked as "trust" but its lock source is not locked,
is it still trusted or will other sources then take over (they should)?

All NTP sources are systems similar to this (locked to PPS + NTP sources),
it is a network of co-channel transmitters that require precise timing
and they use each other for the startup reference.

Rob

On 1/18/23 14:41, Miroslav Lichvar wrote:
> On Wed, Jan 18, 2023 at 02:14:26PM +0100, Rob Janssen wrote:
>> refclock    PPS /dev/pps0 refid PPS prefer
>>
>> and a couple (3-4) external NTP servers as absolute time reference.
>> What can be the cause of this?  The jitter value displayed in chronyc sources
>> remains within 5-20us all the time.  But the offset to PPS can go as high as 2ms
>> during this.  It may be that the combined offsets of the NTP servers as seen by
>> chrony are closer to another than the PPS source is, but still I don't want them to
>> get selected as long as the PPS can be locked and tracked.
> chronyd doesn't cluster sources by their offset. If the PPS source is
> marked as x, it doesn't agree with the NTP soures. Are those NTP
> sources close in term of root distance? You could use the trust option
> to force the selection of the PPS source if you are sure it's correct
> and those NTP servers are wrong, but I think it's more likely your PPS
> refclock is drifting for some reason, e.g. lost GPS signal. You could
> specify a delay of few milliseconds with delay option to ensure an
> overlap with the NTP soures.
>


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