Re: [chrony-users] Poor synchronization to local NTP server

First of all, there doesn't seem to be anything wrong from the data you sent. NIST servers are notoriously bad time sources compared to most pool sources in my experience.

I’m interpreting the “estimated error” of (say) 109ms to my local server as significantly worse than 27ms to time.nist.gov. Also the “source state” column indicates that I’m syncing with time.nist.gov and not using the local time server at all.

In “the field” this host will not be able to reach time.nist.gov, and I just want to match the local time server as closely as I can. 100+ ms of error seems excessive if I can get 200 round-trip pings to that server in the same time.

I can understand if chrony is able to figure out that the local server is just adding extra servers between my device and the Stratum 0 device as Dan suggests, and therefore prefers to choose a shorter path. But my main concern is synchronizing the clocks of these two hosts.

Second, you are showing data from about three minutes of chrony activity. It may be too soon to say.

It has now been about an hour and it’s roughly the same. But I can keep an eye on it.

Third, try adding two or three other pool servers. You can't tell if asdfasdfa is off or something like asymmetry is causing the pool server to seem off.

Ok, I switched from time.nist.gov to {0,1,2,3}.pool.ntp.org. Chrony decided to sync to time.cloudfare.com which has the best “estimated error” value, about 9ms. My local server is 3rd worst.

Fourth, what does ntpq tell you on the ntpd server? How accurate does it think it is?

ntpq> peers
remote     refid   st t when poll reach   delay   offset  jitter
==============================================================================
LOCAL(0)   .LOCL.   10 l  95m   64   0   0.000   +0.000   0.000
198.51.100.1   .STEP.   16 u   - 1024   0   0.000   +0.000   0.000
*12.167.151.1   66.85.78.80   3 u   14   64  377   18.227  +30.128   3.218

On Mar 16, 2021, at 3:40 PM, Frank Wayne <fwayne@xxxxxxxxxxxxxx> wrote:

Way, way too little information.

First of all, there doesn't seem to be anything wrong from the data you sent. NIST servers are notoriously bad time sources compared to most pool sources in my experience.

Second, you are showing data from about three minutes of chrony activity. It may be too soon to say.

Third, try adding two or three other pool servers. You can't tell if asdfasdfa is off or something like asymmetry is causing the pool server to seem off.

Fourth, what does ntpq tell you on the ntpd server? How accurate does it think it is?

________________________________________
From: Ryan Govostes [rgovostes@xxxxxxxx]
Sent: Tuesday, March 16, 2021 14:10
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: [chrony-users] Poor synchronization to local NTP server

I am running ntpd on a local server. That server syncs its clock to pool.ntp.org.

Now I want another device, running chrony, to sync its clock to the local server, so I configured chrony with `server asdfasdfa iburst`. For comparison I also added `server time.nist.gov iburst`.

I’m not sure I’m interpreting the output of chronyc correctly but it seems that it is getting a much better fix to the remote NIST server than to the local server which is on the same subnet and responds to ping in < 0.5 ms.

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- asdfasdfa                     4   6     7     2    +39ms[ -669us] +/- 109ms
^* time-d-b.nist.gov             1   6     7     2    -16us[ -40ms] +/-   27ms

Name/IP Address            NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
asdfasdfa                   8   4   265     -1.772      4.203    +39ms   191us
time-d-b.nist.gov           8   6   265     -2.494      9.770    -61us   442us

What could I start looking into to diagnose the issue? Is it likely to be chrony or the ntp server at fault?

Thanks,
Ryan