Re: [chrony-users] need help with large delays reported in ntpdata

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

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 ______|_ www.theory.physics.ubc.ca/

On Sat, 3 Apr 2021, Charbonneau, André wrote:

> [CAUTION: Non-UBC Email]
>
> Hi,
>
> I currently have a Linux server getting its time from a 1pps source (atomic clock) and 2 stratum
> 1 servers (for time of day).  My Linux server and stratum 1 servers are connected to the same
> switch.  The 1pps is from a Rb synchronized to UTC.
>
>  
>
> I’m seeing some weird peer delay and peer dispersion values in the output of chronyc ntpdata
> command:
.......
> NTP tests       : 111 111 1101

This says that the source i failing the "delay dev ration" 
The explanation would seem to be

maxdelaydevratio ratio
If a measurement has a ratio of the increase in the round-trip delay from the minimum delay amongst the previous measurements to the standard deviation of the previous measurements that is greater than the specified ratio, it will be rejected. The default is 10.0.

 You could try increasing this max to see if that helps.

 It is not entirely clear to me what this means however. And you sources says
 that the system  has a reach of 377, which means taht the the last 8 contacts
 with the source have been successful.
 Of course this does not say why they have been successfull if they have been
 rejected.

> Interleaved     : No
>
> Authenticated   : No
>
> TX timestamping : Kernel
>
> RX timestamping : Kernel
>
> Total TX        : 108
>
> Total RX        : 108
>
> Total valid RX  : 108
>
>  
>
> These peer delay and peer dispersion values are quite large (being connected to the same switch)
> and constant over time (they don’t change).  I was looking at the chrony code and this looks like
> this could be due because of large estimated error?
>
>  
>
> Here is the output of chronyc sources:
>
>  
>
> $ chronyc sources
>
> 210 Number of sources = 3
>
> MS Name/IP address         Stratum Poll Reach LastRx Last sample              
>
> ===============================================================================
>
> #* PPS                           0   4   377    11   +120ns[ +189ns] +/-   66ns
>
> ^- ***.***.52.204                1   5   377   38m  +2040ns[ +347ns] +/-   62us (this seems very
> large…  I’ve seen this jump to 47ms)
>
> ^- ***.***.52.242                1   5   377   39m  +1913ns[ +232ns] +/-   62us
>
>  
>
> The LastRX values for the 2 stratum 1 servers is very large, even though the maxpoll is set to 5.
>
>  
>
> So this seems to indicate that there is a NTP test that fails constantly for these 2 entries.
>
>  
>
> I’m not sure where to look next to try to figure out what is the root cause of this problem.  Any
> information about what might explain these constant large delays reported by the ntpdata command
> and large LastRX values would be much appreciated.
>
>  
>
> Thanks,
>
>   Andre
>
>  
>
>  
>
> CentOS Linux release 7.9.2009 (Core)
>
>  
>
> chronyd (chrony) version 3.4 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS
> +SECHASH +IPV6
>
> +DEBUG)
>
>  
>
>  
>
>  
>
>  
>
> --
>
> Andre Charbonneau
>
>  
>
> Frequency & Time
>
> Metrology Research Centre
>
> National Research Council Canada / Government of Canada
>
> andre.charbonneau@xxxxxxxxxxxxxx / 613-993-3129
>
>  
>
> Fréquence et temps
>
> Centre de recherche en métrologie
>
> Conseil national de recherches Canada / Gouvernement du Canada
>
> andre.charbonneau@xxxxxxxxxxxxxx / 613-993-3129
>
>