Chroy is taking long time detect PPS signal loss

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.

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
[email protected]
pps pps0: new PPS source ptp0
pps pps1: new PPS source [email protected]
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:

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.

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?

Thanks,
Jatinder