ntpd not working - drift file always 0.000

[Matthias Kretschmer]

Hello,
We have two DL580 G7 with Asianux Server 3 SP2 (Linux based on RedHat) running as an Oracle RAC.

I configured the ntpd as follow:

# cat /etc/ntp.conf
server 192.168.7.23 iburst
server 192.168.7.21 iburst

driftfile /var/log/ntp/drift
logfile /var/log/ntp/ntp.log

statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable

When I do a manual sync to my ntpservers it is working:

# ntpdate -u 192.168.7.21
30 Mar 19:32:20 ntpdate[18161]: adjust time server 192.168.7.21 offset 0.061062 sec
# ntpdate -u 192.168.7.23
30 Mar 19:32:36 ntpdate[18175]: adjust time server 192.168.7.23 offset 0.054118 sec

About this, I think my ntp servers are OK.

I start the daemon and everything looks fine:

# /sbin/service ntpd start
ntpd: Synchronizing with time server:                      [  OK  ]
Starting ntpd:    

                                         [  OK ]

But now, my boxes stop time syncing.
The time will differ around 3 sec per day.

The strange thing I already figured out is that the drift file is always 0.000

# ll /var/log/ntp/drift
-rw-r--r-- 1 ntp ntp 6 Mar 30 19:02 /var/log/ntp/drift
# cat /var/log/ntp/drift
0.000

The output from /var/log/messages since I started ntpd:

# cat /var/log/messages | grep ntp
Mar 30 19:34:32 nkgrac1 ntpdate[18703]: step time server 192.168.7.21 offset -0.033342 sec
Mar 30 19:34:32 nkgrac1 ntpd:  succeeded
Mar 30 19:34:32 nkgrac1 ntpd[18707]: ntpd 4.2.2p1@1.1570-o Tue Feb  3 10:01:47 UTC 2009 (1)
Mar 30 19:34:32 nkgrac1 ntpd[18707]: Attemping to register mDNS
Mar 30 19:34:32 nkgrac1 ntpd[18707]: Unable to register mDNS
Mar 30 19:34:32 nkgrac1 ntpd: ntpd startup succeeded
Mar 30 19:34:32 nkgrac1 ntpd[18709]: precision = 1.000 usec
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface wildcard, ::#123 Disabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface lo, ::1#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0, fe80::461e:a1ff:fe4c:29a4#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond1, fe80::461e:a1ff:fe4c:29a5#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface lo, 127.0.0.1#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0, 192.168.7.41#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0:1, 192.168.7.47#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0:3, 192.168.7.53#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0:4, 192.168.7.52#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond0:2, 192.168.7.40#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond1, 192.168.16.41#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: Listening on interface bond1:1, 169.254.153.205#123 Enabled
Mar 30 19:34:32 nkgrac1 ntpd[18709]: kernel time sync status 0040
Mar 30 19:34:32 nkgrac1 ntpd[18709]: frequency initialized 0.000 PPM from /var/log/ntp/drift

Could you give me a hint, where to look for the problem?
Can I enable something like a debug mode for the ntpd?

Thank you very much in advance!

BR
Matthias

[Matti_Kurkela]

When troubleshooting ntpd, the first step should usually be to start ntpd and let ntpd run for a few minutes, then run:

ntpq -p

 It should display some statistics on your NTP servers and the quality of your network connection to them.

The "delay" column is the round-trip time of a NTP message from your server to the NTP server and back, measured in milliseconds.

The "offset" values should be less than 128 when the ntpd has properly synchronized with the NTP server.

The last column ("jitter" in modern ntpd versions, "disp" in old ones) describes the variation in the "delay" value - if it is more than 100, it means the network is causing so unpredictable delays to NTP messages that the NTP server will be practically unusable to ntpd. It might mean that the network is too congested, or that you're trying to use a NTP server that is located physically too far away from you.

Also, you have 2 NTP servers configured. There is a saying: "a man with a clock will know the time - a man with two clocks will be uncertain." If both servers have equal stratum values but they are not in sync with each other, ntpd might have problems deciding which one to believe. With just one server, ntpd would have to simply trust it; with three or more servers, ntpd could follow the majority rule and ignore one server that has a different idea of the current time than the others.

[Matthias Kretschmer]

Hello Matti,

Thank you for your response.

The output of ntpq -p

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nkgadm000.emsna 192.168.7.21     2 u    3   64  377    0.148  7219.12   6.675
 nkgdcs000.emsna .LOCL.           1 u   53   64  377    0.210  7205.51   6.516

From this I think my network is not the problem.

The delay looks good and the jitter as well.

As you see my offset is already above 7 sec, but I forced the sync last Friday.

My both ntp servers are MS Servers 2008 R2 in an active directory and getting synchronized by the AD.

I have the same structure here on my test site and it works pretty good, but I can not see any configuration difference (beside the IP addresses, of cause)

The only different is, that we are using two DL380 instead of DL580.

Any other suggestions?

Thank you in advance.

BR

Matthias

[Matthias Kretschmer]

Hello,

I investigated a little bit more.

# ntpq
ntpq> as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 41286  9014   yes   yes  none    reject  reachable  1
  2 41287  9014   yes   yes  none    reject  reachable  1
ntpq> rv 41286
assID=41286 status=9014 reach, conf, 1 event, event_reach,
srcadr=nkgadm000.emsnanjing.net, srcport=123, dstadr=192.168.7.41,
dstport=123, leap=00, stratum=2, precision=-6, rootdelay=31.250,
rootdispersion=10238.876, refid=192.168.7.21, reach=001, unreach=1,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=9.020, delay=0.118, dispersion=15.651, jitter=0.649,
reftime=d32e7ac1.0f2c3a1a  Tue, Apr 10 2012 17:24:17.059,
org=d32e7df6.8f6dc351  Tue, Apr 10 2012 17:37:58.560,
rec=d32e7df6.8d05f04a  Tue, Apr 10 2012 17:37:58.550,
xmt=d32e7df6.8cfdd154  Tue, Apr 10 2012 17:37:58.550,
filtdelay=     0.12    0.13    0.15    0.12    0.13    0.15    0.13    0.13,
filtoffset=    9.46    8.99    8.49    9.02    8.50    8.00    8.52    8.06,
filtdisp=     15.63   15.66   15.69   15.72   15.75   15.78   15.81   15.84

 Why is the client rejecting the server time?

In another forum I found:

It is possible to use W32Time as a source for NTP, although, before 
Windows 2003, it violates the NTP specification to do so.  It is almost 
never a good thing to do.  The W32Time instance must be synchronised to 
some proper source of time for this to work - a W32Time root with no 
upstream sources won't work.

Is this true? My both domain controllers do not have a time server. They server their local time.

Thank you.

Matthias