[chrony-users] Chrony 3.1 refuses to sync with ntp server

[Assaf Vainsencher]

We recently updated from RHEL 7.3 to RHEL 7.4 which updated chrony to version 3.1 and we can't get it to sync properly with NTP server running on windows server 2008R2 - chronyc sources reports ^? Status for any of the windows 2008 NTP servers we try. Version 2.1.1 in RHEL 7.3 syncs fine. One of our software engineers tried compiling and installing version chrony 3.2 and it still didn't work. Downgrading chrony fixes the issue. Is there a suggested fix for this that we can try with our chrony configuration or is this a known incompatibility issue?

We also found this post on stackexchange with someone experiencing a similar, if not the same, issue:

https://unix.stackexchange.com/questions/404046/chrony-3-1-refuses-to-sync-with-ntp-server


Assaf Vainsencher
Raytheon IIS
22110 Pacific Blvd, Dulles
w. 571-250-3824
c. 571-294-8082

[Miroslav Lichvar]

Post by Assaf Vainsencher
We recently updated from RHEL 7.3 to RHEL 7.4 which updated chrony to version 3.1 and we can't get it to sync properly with NTP server running on windows server 2008R2 - chronyc sources reports ^? Status for any of the windows 2008 NTP servers we try. Version 2.1.1 in RHEL 7.3 syncs fine. One of our software engineers tried compiling and installing version chrony 3.2 and it still didn't work. Downgrading chrony fixes the issue. Is there a suggested fix for this that we can try with our chrony configuration or is this a known incompatibility issue?
https://unix.stackexchange.com/questions/404046/chrony-3-1-refuses-to-sync-with-ntp-server

The debug output attached there shows that the NTP server has a root
dispersion which is too large to pass the source selection in the
default configuration. As I understand it, this is a common issue with
the Windows NTP server if it uses a long polling interval. If you run
"chronyc ntpdata", it should print the value from the last response.

There is a hardcoded limit of 16 seconds for the root distance, which
includes the root dispersion, but since chrony-2.2 there is an
additional requirement applied in the source selection. By default it
is 3 seconds. If your server has a larger dispersion (and distance),
you will need to increase the maximum distance with "maxdistance XX"
in chrony.conf.

[Assaf Vainsencher]

Thank you. I confirmed that using maxdistance 16 fixed the issue we're seeing. Looks like our root dispersion is just over 10 which is why we were seeing the issue with the default setting in version 3.1.

-----Original Message-----
From: Miroslav Lichvar [mailto:***@redhat.com]
Sent: Tuesday, November 28, 2017 1:52 PM
To: chrony-***@chrony.tuxfamily.org
Subject: [External] Re: [chrony-users] Chrony 3.1 refuses to sync with ntp server

Post by Assaf Vainsencher
We recently updated from RHEL 7.3 to RHEL 7.4 which updated chrony to version 3.1 and we can't get it to sync properly with NTP server running on windows server 2008R2 - chronyc sources reports ^? Status for any of the windows 2008 NTP servers we try. Version 2.1.1 in RHEL 7.3 syncs fine. One of our software engineers tried compiling and installing version chrony 3.2 and it still didn't work. Downgrading chrony fixes the issue. Is there a suggested fix for this that we can try with our chrony configuration or is this a known incompatibility issue?
https://unix.stackexchange.com/questions/404046/chrony-3-1-refuses-to-
sync-with-ntp-server

The debug output attached there shows that the NTP server has a root dispersion which is too large to pass the source selection in the default configuration. As I understand it, this is a common issue with the Windows NTP server if it uses a long polling interval. If you run "chronyc ntpdata", it should print the value from the last response.

There is a hardcoded limit of 16 seconds for the root distance, which includes the root dispersion, but since chrony-2.2 there is an additional requirement applied in the source selection. By default it is 3 seconds. If your server has a larger dispersion (and distance), you will need to increase the maximum distance with "maxdistance XX"
in chrony.conf.

--
Miroslav Lichvar

--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.

[Bill Unruh]

Post by Assaf Vainsencher
Thank you. I confirmed that using maxdistance 16 fixed the issue we're seeing. Looks like our root dispersion is just over 10 which is why we were seeing the issue with the default setting in version 3.1.

Off topic, but I am really surprized by such a huge root dispersion. Are the
ntp packets being delivered by sneakernet?

Why would one want to use a timesource with such a huge dispersion/delay?

[Assaf Vainsencher]

I'm not really sure but I think as long as chrony syncs with the NTP server that it's acceptable for our needs. That being said, could it be that both the NTP server (windows 2008R2) and the clients are on Vmware virtual machines? If is there a setting for the vmware VM or chrony to improve the dispersion? What's the downside of high dispersion?

Assaf Vainsencher
Raytheon IIS
22110 Pacific Blvd, Dulles
w. 571-250-3824
c. 571-294-8082


-----Original Message-----
From: Bill Unruh [mailto:***@physics.ubc.ca]
Sent: Tuesday, November 28, 2017 9:14 PM
To: chrony-***@chrony.tuxfamily.org
Subject: [External] RE: Re: [chrony-users] Chrony 3.1 refuses to sync with ntp server

Post by Assaf Vainsencher
Thank you. I confirmed that using maxdistance 16 fixed the issue we're seeing. Looks like our root dispersion is just over 10 which is why we were seeing the issue with the default setting in version 3.1.

Off topic, but I am really surprized by such a huge root dispersion. Are the ntp packets being delivered by sneakernet?

Why would one want to use a timesource with such a huge dispersion/delay?

--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.

[Bill Unruh]

Post by Assaf Vainsencher
I'm not really sure but I think as long as chrony syncs with the NTP server that it's acceptable for our needs. That being said, could it be that both the NTP server (windows 2008R2) and the clients are on Vmware virtual machines? If is there a setting for the vmware VM or chrony to improve the dispersion? What's the downside of high dispersion?

The downside is potentialy bad time. If the roundtrip for example is 5 sec and
has a 2 sec asymmetry (1.5 sec up and 3.5 down) then your time will be off by
a second, etc.(Your sneakernet deliverer stolls one way and runs the other).
A better idea is to get a cheap Linux machine or bsd machine (eg a Raspberry
Pi) and use it as your time delivery machine instead of bad Windows machines.

Post by Assaf Vainsencher
Asasaf Vainsencher
Raytheon IIS
22110 Pacific Blvd, Dulles
w. 571-250-3824
c. 571-294-8082
-----Original Message-----
Sent: Tuesday, November 28, 2017 9:14 PM
Subject: [External] RE: Re: [chrony-users] Chrony 3.1 refuses to sync with ntp server

Post by Assaf Vainsencher
Thank you. I confirmed that using maxdistance 16 fixed the issue we're seeing. Looks like our root dispersion is just over 10 which is why we were seeing the issue with the default setting in version 3.1.

Off topic, but I am really surprized by such a huge root dispersion. Are the ntp packets being delivered by sneakernet?
Why would one want to use a timesource with such a huge dispersion/delay?
--
with "unsubscribe" in the subject.
with "help" in the subject.
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Miroslav Lichvar]

Post by Bill Unruh

Post by Assaf Vainsencher
I'm not really sure but I think as long as chrony syncs with the NTP server that it's acceptable for our needs. That being said, could it be that both the NTP server (windows 2008R2) and the clients are on Vmware virtual machines? If is there a setting for the vmware VM or chrony to improve the dispersion? What's the downside of high dispersion?

The downside is potentialy bad time. If the roundtrip for example is 5 sec and
has a 2 sec asymmetry (1.5 sec up and 3.5 down) then your time will be off by
a second, etc.(Your sneakernet deliverer stolls one way and runs the other).
A better idea is to get a cheap Linux machine or bsd machine (eg a Raspberry
Pi) and use it as your time delivery machine instead of bad Windows machines.

In this case it seems it was the root dispersion what caused the
source to be ignored, so rather than NTP messages spending too much
time in the network, the server (or its servers) has an unstable clock
or its update interval is too long.