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

[ Thread Index | Date Index | More 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 ______|_

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

[CAUTION: Non-UBC Email]


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

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

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.






CentOS Linux release 7.9.2009 (Core)









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


Mail converted by MHonArc 2.6.19+