Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Has anyone got any experience syncing Linux (specifically Red Hat) to a Windows NTP server? Currently our Windows server is syncing to an stratum 1 server on the internet but the Linux boxes refuse to acknowledge it as a good time source.

Having done a bit of research it seems our problem is the Root Dispersion value is possibly too high. Here's the output from ntpq -

ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
ntp1.ourdomain       4 u   20  128  377    0.376  1397.10  22.800

ntpq> ass

ind assID status  conf reach auth condition  last_event cnt
  1 30939  90b4   yes   yes  none    reject   reachable 11
ntpq> rv 30939
assID=30939 status=90b4 reach, conf, 11 events, event_reach,
srcadr=ntp1.ourdomain.com, srcport=123, dstadr=,
dstport=123, leap=00, stratum=4, precision=-6, rootdelay=93.750,
rootdispersion=2333.466, refid=, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=7, ppoll=7, flash=400 peer_dist, keyid=0, ttl=0,
offset=1369.793, delay=0.000, dispersion=21.915, jitter=15.387,
reftime=d7493cd7.fd3528d6  Mon, Jun 16 2014 10:52:23.989,
org=d74944eb.b857f9bc  Mon, Jun 16 2014 11:26:51.720,
rec=d74944ea.5709a581  Mon, Jun 16 2014 11:26:50.339,
xmt=d74944ea.56ea01a7  Mon, Jun 16 2014 11:26:50.339,
filtdelay=     0.48    0.51    0.00    0.43    0.50    0.44    0.40    0.55,
filtoffset= 1380.34 1376.38 1369.79 1362.68 1360.75 1353.16 1349.80 1343.46,
filtdisp=     15.63   17.58   19.48   21.42   23.37   25.30   27.25   29.20

What I'm trying to understand is why this value is so high and is there anything we can configure on the Windows server to change it.


Here's some information from our Windows NTP server -

c:\Windows\System32>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 2 (secondary reference - syncd by (S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0312500s
Root Dispersion: 1.2097655s
ReferenceId: 0x9E2BC042 (source IP:
Last Successful Sync Time: 18/06/2014 04:41:16
Source: ntp2.pipex.net
Poll Interval: 15 (32768s)

c:\Windows\System32>w32tm /query /peers
#Peers: 2

Peer: ntp1.pipex.net
State: Active
Time Remaining: 6264.1144284s
Mode: 1 (Symmetric Active)
Stratum: 2 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 15 (32768s)
HostPoll Interval: 15 (32768s)

Peer: ntp2.pipex.net
State: Active
Time Remaining: 6264.1144284s
Mode: 1 (Symmetric Active)
Stratum: 1 (primary reference - syncd by radio clock)
PeerPoll Interval: 15 (32768s)
HostPoll Interval: 15 (32768s)
share|improve this question
Root Dispersion only tells you the highest recorded time difference. Look here and search for 'Root Dispersion' –  Daniel Jun 18 '14 at 9:48
Thanks Dan. I understand what the value means but what would cause it to be so high, and why would Linux consider the server untrustworthy? –  Chris Edgington Jun 18 '14 at 10:14
I don't know what the problem is, but I can confirm that I've synced hundreds of Linux servers using Windows DCs as NTP servers for many years without issue. –  ThatGraemeGuy Jun 18 '14 at 11:41

1 Answer 1

up vote 1 down vote accepted

ntpd will reject clocks if it concludes that something is wrong with the remote clock because of a large offset. Your linux boxes are most likely rejecting the Windows TS because the offset is higher than the panic threshold. Assuming that the Windows time server is working properly you should look into adding the -g flag to ntpd invocation:

-g Normally, ntpd exits with a message to the system log if
   the offset exceeds the panic threshold, which is 1000 s by
   default.  This option allows the time to be set to any value
   without restriction; however, this can happen only once.  If the
   threshold is exceeded after that, ntpd will exit with a message
   to the system log.  This option can be used with the -q and -x

Or setting the panic value to something much higher or to zero:

panic panic
    Specifies the panic threshold in seconds with default 1000 s. If set to
    zero, the panic sanity check is disabled and a clock offset of any value
    will be accepted.

FYI: It is not entirely clear if your windows time installation is working correctly and/or is configured the way you describe. You mention that the Windows server is syncing to a stratum 1 machine on the internet. However your peers billboard says that ntp1.ourdomain is at stratum four:

Stratum  Machine description
1        ntp ref clock on internet
2        ?????????
3        ?????????
4        ntp1.ourdomain
5        linux boxes

The jitter value is also remarkably high for a machine with such a low delay, which I am assuming is indicative of a machine on the same local network.

share|improve this answer
We've now changed the source of our remote clock to the ntp.org pool which seems to have resolved the problem. As you correctly pointed out it seems something could have been wrong with our remote source. –  Chris Edgington Jun 20 '14 at 7:40
Also I should clarify that there are 2 additional NTP servers in the 'chain' which I didn't mention just to keep things simple. We have the same issue when pointed directly at the stratum 2 server. The logs I posted just happened to be from the servers pointing to the stratum 4. –  Chris Edgington Jun 20 '14 at 7:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.