topic Re: Time Creep in Operating System - HP-UX

Time Creep

Don Spare — Fri, 14 Sep 2001 18:05:16 GMT

I have 2 L2000 servers running HP-UX 11.0 (64 bit). Both are experiencing time creep in the range of about +1-2 minutes per month. I need a fix for this. We have a time source on an NT server. Is there any way I can sync to that? What other choices do I have to choose from?

Re: Time Creep

Santosh Nair_1 — Fri, 14 Sep 2001 18:11:31 GMT

If you have a NTP server available to you, HP can synchronize time with that...there are many NTP servers on the network. See the URL http://www.ntp.org for more details on NTP.

-Santosh

Re: Time Creep

A. Clay Stephenson — Fri, 14 Sep 2001 18:12:02 GMT

If your NT box is an NTP server you can set up
your HP boxes as NTP clients and you are fixed.
You can do everything in SAM.

If your NT box is not a real NTP server,
I would select one of your HP boxes to be an NTP server. That server in turn looks to the US Naval Observatory (navobs1.wustl.edu) as its preferred server. The other HP box is simply a client of the HP NTP server.

Re: Time Creep

Don Spare — Fri, 14 Sep 2001 18:36:11 GMT

Okay. I think I'm making some progres here(???). I have found that SAM can configure NTP that comes with HP-UX. I have enabled it and pointed it to the NT server. How long does it take to synchronize the system date/time after being enabled. There is no man page on NTP so I kind of flying blind here.

Re: Time Creep

Santosh Nair_1 — Fri, 14 Sep 2001 18:41:18 GMT

First, check if the xntpd daemon is running on your server (the HP box I mean). Then check /var/adm/syslog/syslog.log...you should see messages from xntpd.

-Santosh

Re: Time Creep

A. Clay Stephenson — Fri, 14 Sep 2001 18:43:14 GMT

Hi:

Depending on how far out your time is, it might take several tens of minutes. NTP gradually and continually adjusts the clock speed until synchronization is reached. That is the real beauty of NTP; if your box is fast by a few minutes it slows the system clock down so that 60 seconds of system time might actually be 65 seconds. There reason it is done like this is so that all file datestamps remain accurate with respect to one another.

Clay

Re: Time Creep

Don Spare — Fri, 14 Sep 2001 18:46:10 GMT

The /usr/sbin/xntpd is running.
These are the messages I found in syslog.log

Sep 14 15:33:30 dwdev001 xntpd[12017]: xntpd version 3.5f: Fri Dec 10 10:27:26 GMT 1999 PHNE_19711
Sep 14 15:33:30 dwdev001 xntpd[12017]: tickadj = 625, tick = 10000, tvu_maxslew= 61875
Sep 14 15:33:30 dwdev001 xntpd[12017]: precision = 6 usec

What's next?

Re: Time Creep

Don Spare — Fri, 14 Sep 2001 18:48:01 GMT

Clay,
My system clock is currently about 2.5 minutes ahead. So should I see a change by tomorrow morning or sooner?

Don

Re: Time Creep

A. Clay Stephenson — Fri, 14 Sep 2001 18:55:01 GMT

Much sooner than that. In fact, start comparing
about 5 minute intervals on your watch with those of your system. They should differ by a few seconds.

Re: Time Creep

Sachin Patel — Fri, 14 Sep 2001 18:56:16 GMT

Hi Don,
Yes, 2 to 3 minutes are not big difference it will be sync. within couple hours.

Sachin

Re: Time Creep

Santosh Nair_1 — Fri, 14 Sep 2001 18:57:28 GMT

Don,

It can take quite a long time to get the clocks synched. If you have the option, you can do ntpdate to synch up the time and use xntp to keep the time in sync. In order to use ntpdate, you need to take the xntpd daemons down, i.e.:

/sbin/init.d/xntpd stop
ntpdate
/sbin/init.d/xntpd start

-Santosh

Re: Time Creep

Sachin Patel — Fri, 14 Sep 2001 18:58:51 GMT

Hi Don,
#ntpq -p is good command
For more info man ntpq.

Sachin

Re: Time Creep

Bill Hassell — Fri, 14 Sep 2001 19:07:57 GMT

NTP is a very accurate and non-invasive program. Edit /etc/rc.config.d/netdameons, and set the lines:

export NTPDATE_SERVER=
XNTPD=0
export XNTPD_ARGS=

Change the first line to point to the IP-addr or hostname of your primary NTP server. Change the second line from =0 to =1 to enable xntpd on reboot. Now, every reboot will sync exactly to the NTP server. A reboot is the fastest and safest way to reset the clock. For example:

export NTPDATE_SERVER=myntpsource.mydomain.com
XNTPD=1
export XNTPD_ARGS=

However, you don't want time changing visibly on ANY server, especially a database server, so the NTP daemons will actually change the CPU clock speed (more accrately, it changes the clock divisor very slightly). This means that a 1 minute mismatch in time can take up to an hour to sync.

If you have the latest patch for NTP, there is a new option for ntpdate (-B) which will slew the clock slowly, essentially what xntpd does. Use ntpdate -B when the clock is seriously out of sync, like 20 minutes or more.

NTP is an amazingly complex and accurate protocol. It starts out with a 64 byte message each way every 64 seconds and adjusts the clock just a fraction of a second. This means that not a single 1-second tick will be missed. This keeps database programs vary happy.

Once the clock is within 128 milliseconds, the protocol backs off to once every 128 seconds, then 256 and so on, out to a maximum of about 17 minutes per check. As long as the local clock is within 128 milliseconds, it won't poll any faster.

This is why a very small computer can act as a timeserver for THOUSANDS of clients. As a rule, sysadmin must NEVER change the time of day on a Unix box that is running databases or other time-sensitive programs. You might even put a wrapper around the date command to reject any attempt to change the time (but leave the other functions alone).

Re: Time Creep

Santosh Nair_1 — Fri, 14 Sep 2001 19:13:14 GMT

Just to note, in addition to databases, DCE is VERY VERY critical of time changes. Had lots of fun with that when doing Y2K testing.

-Santosh

Re: Time Creep

John Bolene — Fri, 14 Sep 2001 19:34:38 GMT

Amen on the DCE for Y2K.

I ended up rebuilding the DCE cell for the ten machines in the test cell each time that applications wanted to test another date scenario.

I got really good at doing this since we tested the various time changes at least 20 times.