| Re: [chrony-users] Strange "loss of PPS lock" |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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 |____ unruh@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.