NTP Server Configuration

[Narendra Uttekar]

Hi,
I have configured the Windows Domain Controller NTP server as time sync for HP-UX servers as NTP client. And it is working good.
The configuration of /etc/ntp.conf file as below,
server 10.0.25.91 prefer
server 10.0.25.92
driftfile /etc/ntp.drift

And the /etc/rc.config.d/netdaemons
export NTPDATE_SERVER=10.0.25.91
export XNTPD=1
export XNTPD_ARGS=

And the output of ntpq -p is as below,
server:[/]# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*server02.domain server06.domain 4 u 29 64 377 77.91 -5.932 5.80
+server05.domain server06.domain 4 u 28 64 377 77.56 -26.088 11.67

Please let me know whether this configuration is good or do i need to make any changes in configuration files. Becuase i want to configure this time sync settings on Production system. And later i should not have any problem with time sync? The question is if Windows NTP server is unavailable for 4 hours what will be the impact on HP-UX servers which is configured as NTP client to sync time from Windows DC NTP server.
Or else what will be the best NTP client configuration for HP-UX system? I can't directly sync the time through Internet or any external device.
Please let me know the real production environment configuration for time sync for HP-UX systems.

Thanks,
Narendra

[TTr]

This setup is fine for most client environments. If the ntp server is unavailable, the client will maintain decent time for hours, even a couple of days. Most ntp clients if they lose connection to the ntp server will lose 1-2 seconds in a 24hr period. Of course there may be exceptions where the clock of a server is so bad it will drift some more.

[Hakki Aydin Ucar]

I believe /etc/rc.config.d/netdaemons seems OK.

You can use this link to get answers:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1350247

[Michal Kapalka (mikap)]

hi,

the configuration is ok.

mikap

[Michael Steele_2]

HI

"...The question is if Windows NTP server is unavailable for 4 hours what will be the impact on HP-UX servers which is configured as NTP client to sync time from Windows DC NTP server..."

Probably none. And if there is then there should be an automatic sync up. Worse case, like, one in a thousand, reset the time with the date or set_parms command.

NTP will drift out of sync and then attempt a resync every 30 seconds or so. This is a configuration parameter. But if it gets more than, say, 3 minutes out of sync, it will fail for some reason. NTP works best when it not more than, say, a minute or two out of sync.

[Bill Hassell]

NTP is a very tolerant package and will handle outages for days. Once xntpd has been running for a while, the ntp.drift file will have a value that indicates how much the local system drifts between updates. So complete loss of all NTP servers will only be noticed if you write a script to check syslog or ntpq -p to see if sync is failing. Most HP boxes will drift less than a couple of minutes per day but xntpd will continue adjusting the clock every hour using the ntp.drift value, thus compensating for the known drift. If temperature at the server remains constant, you could run for weeks without drifting more than a couple of minutes.

xntpd will slew the time (slowly) once an NTP server is found so there will be no loss or gain of seconds per day (one or two minutes off will require a couple of hours to resync). If the adjustment is more than about 10 minutes, xntpd cannot make the adjustment fast enough to complete in 24 hours and will report errors in syslog. Meanwhile, your system will continue to keep time but without syncing to the NTP servers. A reboot will restore the time if the NTP servers are working. You can manually jump the time but this is never recommended while any applications and especially databases are running. The same warning applies to root using the date command to set the time -- don't do it unless all apps and DBs are stopped.

[mvpel]

A reboot is way too dramatic to correct a simple time discrepancy. Most applications aren't so sensitive that a time jump of several minutes by "ntpdate" will affect them adversely.

If you're running Kerberos, the typical time skew limit is 5 minutes, but if your system is ten minutes out of sync already Kerberos won't be working anyway.

If do you have an unusually sensitive application that will break if the time jumps too far (we have one here that needs microsecond precision), and you're worried about large discrepancies, you can set the "slewalways yes" option, and increase the "slewthreshold" value from its default of 0.128 seconds, so that the NTP service won't jump the clock except under more significant discrepancies.

Or better yet, install a PCI-SyncClock32 card from Brandywine and plug in a GPS antenna, and make your system a Stratum 0 server, like we do.

By default, the NTP service won't start if it can't find a server within 1,000 seconds of the current system time. You can change that with the "ignorebigtimestep" option.

After NTP has been running a while, it will figure out how fast the system clock is drifting, and adjust things accordingly so that the system won't drift out of alignment too far during an NTP outage of a few hours. That information is stored in the file specified by the "driftfile" option, usually /etc/ntp.drift.

[Narendra Uttekar]

Hi,
I want to understand what exactly the values are in /etc/ntp.drift file or else what exactly it indicates. And also i have noticed the values in /etc/ntp.drift file on my system is changing what does it means?
Server:[/]# cat /etc/ntp.drift
-44.126 0
What this value exactly means?

Thanks,
Narendra

[BUPA IS · Accepted solution]

hello
The drift file records the rate in parts per million at which the system clock has to be adjusted to keep it in step with your time servers. A new file is created every hour and the old one removed. (so NTP needs write permissons to the drift directory). NTP uses this number with its sign to keep trying to adjust the clock in the event of losing contact with the time servers, and most usefully in the event of system restart it uses it to line up the clock grooming algorithim in a few hours rather than a couple of days compared to a start without one.
One other thing if you have time offset of more than 1000 seconds ntp gives up since its assumes something is seriously wrong .

Mike

[mvpel]

Speaking of the 1,000 second ntpd sync limit - I found a system clock yesterday that was set to some date in 2030 - the ntpdate syslog entry had so many seconds in its clock-step report (about 6.6 billion) that it overflowed the variable and displayed garbage.

I suspect someone didn't get the syntax of the "date" command quite right, and put 8:30pm in the year columns.