Re: Chroy is taking long time detect PPS signal loss

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 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 [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:  

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