| Re: [chrony-users] Chroy is taking long time detect PPS signal loss |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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 Thu, 31 Aug 2023, Jatinder wrote:
[CAUTION: Non-UBC Email]Hello,
We are using Chrony for NTP and 1-pulse-per-second (1PPS) synchronisation. The system is able to
synchronize with NTP and PPS.
We observed one problem, when we remove PPS cable from the system Chrony is taking a long time to
detect it even after removal of PPS cable chronyc sources shows locked/synchronized.
Of course. You would get very upset if it were to dump PPS it for some reason
only of the pulses were lost. Your clock, corrected by chrony, is perfectly
capable to delivering very accurate time even if it misses a few pulses.
Instead of asking chrony to read your mind (I purposely disconnected it, can
chrony not read mind mind to know that) figure out what you really need, and
when you really want it to give up relying on the system clock. Remember that
chrony in default operation, will wait up to a hour between queries of the
network to keep the clock on time.
System and configuration details:
We are using
https://www.variscite.com/product/system-on-module-som/cortex-a7/dart-6ul-freescale-imx-6ul/ which
runs with Debian 10 and Kernel 4.14.170.
We are using the Kernel pps-gpio module to get a signal from a GPS receiver via GPIO pin.
Configuration in the Device-Tree:
pps@0 {
compatible = "pps-gpio";
pinctrl-0 = <&pps_mux>;
gpios = <&gpio5 9 0>;
};
pps_mux: pps_mux-1 {
fsl,pins = <MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x130B9>;
};
Startup Kernel.log shows that pps0 is mapped with ptp0 and pps1 is mapped with 1PPS input. with
/dev/pps and 1PPS is getting mapped to /dev/pps1
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@xxxxxxxx
pps pps0: new PPS source ptp0
pps pps1: new PPS source pps@0.-1
pps pps1: Registered IRQ 222 as PPS source
We have two devices pps0 and pps1 under /dev. If we run ppstest on /dev/pps0 and /dev/pps1, pps0
is not able to fetch anything but pps1 receives signal every second:
Why would you want two sources?
It sounds like you have misconfigured pps0. Maybe you should give more details
of what you are doing.
ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1693323647.999999474, sequence: 58301 - clear 0.000000000, sequence: 0
source 0 - assert 1693323648.999999022, sequence: 58302 - clear 0.000000000, sequence: 0
source 0 - assert 1693323649.999999185, sequence: 58303 - clear 0.000000000, sequence: 0
source 0 - assert 1693323650.999999395, sequence: 58304 - clear 0.000000000, sequence: 0
source 0 - assert 1693323651.999999669, sequence: 58305 - clear 0.000000000, sequence: 0
cat /etc/chrony/chrony.conf
# Private GPS-sourced NTP servers have no polling abuse concerns.
# For this reason, setting minpoll/maxpoll to 0 (1 second) is allowed.
server 10.10.10.200 minpoll 0 maxpoll 0 maxdelay 0.5 iburst trust
# Location of ID/key pairs for NTP authentication.
keyfile /etc/chrony/chrony.keys
# Store new gain/loss rate, for compensating the system clock upon restart.
driftfile /var/lib/chrony/chrony.drift
# Enable logging of clock drift.
#log tracking measurements statistics
logdir /var/log/chrony
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
# Enable kernel synchronisation (every 11 minutes) of the real-time clock.
rtcsync
# Use the real-time FIFO scheduler with the specified priority (between 0
# and 100). This results in reduced latency (extreme clock stability).
sched_priority 1
# Forcing more samples reduces noise in the estimated frequency and offset,
# but slows response to clock changes in the frequency and offset.
minsamples 32
# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3
# Enable hardware timestamping of NTP packets for all interfaces.
hwtimestamp *
# Synchronize time using the rising edge of a 1-pulse-per-second clock.
refclock PPS /dev/pps1 refid PPS1 poll 0 precision 1e-9 prefer
This is when we removed/disconnected the PPS cable.
date;chronyc sources
Mon 28 Aug 2023 09:24:36 PM UTC
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#* PPS1 0 0 377 1 +881ns[ +932ns] +/- 1000ns
^- 10.10.10.200 1 0 377 0 +28us[ +28us] +/- 1168us
This is when Chrony detected signal loss and marked PPS1 as faulty. It took around 70 seconds to
detect PPS signal loss.
So what?
date;chronyc sources
Mon 28 Aug 2023 09:25:50 PM UTC
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? PPS1 0 0 0 73 -25us[ -152ns] +/- 1399ns
^* 10.10.10.200 1 0 377 0 -5633ns[-6004ns] +/- 1207us
Questions:
Why is Chrony taking a long time to detect PPS signal loss?
Is there any way to make that signal loss detection faster?
Why?
Thanks,Jatinder