Re: Strange "loss of PPS lock"

It is almost inconceivable that either the gps or the ntp servers could drift
that far unless there were a complete cutoff. Are your sure that the ntp
sources are not really one single source (Ie all your sources are reliant on a
single source which is drifting away?-- eg they are all sources which are run
by a single company?)
It is also possible that the gps receiver or the antennas are bad, and the gps
receiver is simply free wheeling? Although I would not expect that to give
seconds of offset.

I have no idea what "its lock source goes out of lock" means for the PPS
source.


William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/

On Wed, 18 Jan 2023, Rob Janssen wrote:

> [CAUTION: Non-UBC Email]
>
> 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)?

No idea what this sentence means. The source for PPS is the array of
sattelites, which are NOT going to go out of lock unless something very very
bad has happened to the world, in which case chrony is not going to be your
biggest worry.

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

Ah, they are all one. Not good. Havint a thousand sources who all get their
time from each other does no good, they are just one, and is bad because ntp
or chrony will thing they are independent and given them far more weight. 
Get other ntp sources-- public ones from the net in there. 
>
> 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-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "unsubscribe" in the subject.
> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "help" in the subject.
> Trouble?  Email [email protected]
>
>