2

After I configured chrony service on my CentOS 7.3 to point to the active directory, it shows below

> chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ad.myserver.com                2   6   377    17   -206us[  -92us] +/-  10.6s

According to the document, the last column "Last Sample"

This column shows the offset between the local clock and the source at the last measurement. The number in the square brackets shows the actual measured offset. ...The number following the +/- indicator shows the margin of error in the measurement. Positive offsets indicate that the local clock is fast of the source.

The offset in the square bracket seems reasonable. The source and my local clock has offset of 92us, but why the margin of error is so high with 10.6 seconds? What does the margin of error mean? What could be the possible reason?

Before I pointed them to the AD, it was using the public time server like 0.centos.pool.ntp.org. At that time, the result is posted as below. The margin of error is much lower.

> chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* minime.fdf.net                3   8   377     1  -1078us[-1110us] +/-   15ms
^- kcolford.com                  3   8   377     8   -676us[ -708us] +/-   54ms
^- pool-173-71-73-207.cmdnnj     1   8   377     8   -209us[ -241us] +/-   56ms
^+ mis.wci.com                   2   8   377    10  +2944us[+2912us] +/-   43ms
Lan
  • 121
  • 1
  • 3
  • The margin of error includes the root delay, root dispersion, peer delay and peer dispersion. The `measurements` log, which can be enabled in _chrony.conf_ contains all these values. In your case it will most likely be the root dispersion what makes most of the 10 second error. What it means is that the server is claiming its time is accurate only to about 10 seconds. As I understand it that's not unexpected with the Windows NTP server. – mlichvar Aug 25 '17 at 06:35
  • @mlichvar Thanks for the response. Your answer clarifies a few things but brings up more question. Why it is "not unexpected with Windows NTP server"? Why for Windows NTP server, it claims its time is accurate only to about 10s? The root dispersion is the maximum (worst case) difference between the local system clock and the root of the NTP tree (stratum 1 clock). If the 10s error mostly for root dispersion, why my local clock would be 10s diff from the AD clock? – Lan Aug 25 '17 at 15:20
  • @mlichvar And you are right. I turned on the measurement log and the root dispersion is 1.075e+01 when the margin of error is 10.8s. Again, the question is why root dispersion is so high when the NTP server is Window based? – Lan Aug 25 '17 at 15:25

1 Answers1

1

The PDC in your domain may simply be off by many seconds. Especially if it is drifting and not synced to anything. Check its performance with w32tm /monitor /domain: from a domain joined Windows box. For more useful commands, this previous question has a w32tm quick reference: How to find time server in a domain?

Windows Server before 2016 was not designed for sub second accuracy. Often it achieves this anyway, so I'm still suspicious your domain's time keeping given the large error.

And a tip: configure chrony.conf (or ntp.conf) with pool ad.example.org. Active Directory best practice is to have more than one DC, and they're all in DNS as the domain name. Might as well use them all, like you did for the NTP public pool.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32