topic Re: ntpdate command strange corrections in Operating System - HP-UX

ntpdate command strange corrections

kenny chia — Wed, 14 Jan 2004 22:47:51 GMT

Hi
I ran the ntpdate command on server A to synchronise its time to server B. Both server A and B are a few seconds apart. But when I run the ntpdate command on server A, the time was adjusted back 16 hours.

Why the strange behaviour?

Below is the output at Server A

# ntpdate -d 192.168.24.27
15 Jan 10:39:06 ntpdate[25059]: ntpdate version=3.5f; Mon Jun 9 14:50:06 PDT 1997 (2)
transmit(192.168.24.27)
receive(192.168.24.27)
transmit(192.168.24.27)
receive(192.168.24.27)
transmit(192.168.24.27)
receive(192.168.24.27)
transmit(192.168.24.27)
receive(192.168.24.27)
transmit(192.168.24.27)
server 192.168.24.27, port 123
stratum 6, precision -17, leap 00, trust 000
refid [192.168.24.30], delay 0.02657, dispersion 0.00070
transmitted 4, in filter 4
reference time: c3b07c03.e3ccb000 Wed, Jan 14 2004 18:40:03.889
originate timestamp: c3b07c18.8c4ca000 Wed, Jan 14 2004 18:40:24.548
transmit timestamp: c3b15cca.5095e000 Thu, Jan 15 2004 10:39:06.314
filter delay: 0.03703 0.02718 0.02663 0.02657
0.00000 0.00000 0.00000 0.00000
filter offset: -57521.7 -57521.7 -57521.7 -57521.7
0.000000 0.000000 0.000000 0.000000
delay 0.02657, dispersion 0.00070
offset -57521.767354

15 Jan 10:39:06 ntpdate[25059]: step time server 192.168.24.27 offset -57521.767354 sec

Re: ntpdate command strange corrections

Bill Hassell — Wed, 14 Jan 2004 23:36:58 GMT

Normally, you would never use ntpdate on a running system because you necver want to change the time of day except during bootup. Start with both servers: look at /etc/TIMEZONE. Are they the same? (better question: are both servers in the same location or timezone?). Then look at the kernel parameter timezone and dst. They should match.

Next, verify that the NTP server is running correctly with:

ntpq -p 192.168.24.27

It should show the time sources used by the server and how reliable those sources are to that NTP server. All HP-UX systems run GMT or Zulu time internally. However, when the date command is run to set the current time, whatever you type in at the command line is translated into GMT using the current value of $TZ, so the internal time for the HP-UX server should be displayed first:

TZ=GMT date

If this value is widely different between the servers, then the internal clock was incorrectly set with the use of the wrong TZ value.

Finally, HP-UX uses xntpd to maintain sync. ntpdate should ONLY be used during bootup when no time-critical processes are running. You can use SAM or just edit 2 files:

/etc/rc.config.d/netdaemons
/etc/ntp.conf

The comments in ntp.conf can be overwhelming. Just put the names of your NTP servers in the ntp.conf file as in:

server 192.168.24.27
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10 # backup clock (internal)
driftfile /etc/ntp.drift # path for drift file

The 127.xxx entries are to allow xntpd to fallback on your internal clock if the NTP servers fail. xntpd will also prevent any time shifts by slowly changing the time between seconds (every day will always have 86400 seconds). ntpdate will lose or gain seconds which can be detrimental to cron, databases and other applications.

Re: ntpdate command strange corrections

kenny chia — Thu, 15 Jan 2004 00:29:14 GMT

I think the timezone is wrong

Server A /etc/TIMEZONE
TZ=sst+8
export TZ

Server B (192.168.24.27) /etc/TIMEZONE
TZ=SST-8
export TZ

How do I check which is correct?

Can I just change Server A /etc/TIMEZONE to
TZ=SST-8
export TZ

Re: ntpdate command strange corrections

Elmar P. Kolkman — Thu, 15 Jan 2004 01:18:22 GMT

Easy way to find which is correct: see if your east or west from Greenwich. Or:
#TZ=GMT date
and compare the result to the last post on the ITRC, which time is always reported in GMT ;-)

To set the clock right:
1) edit /etc/TIMEZONE
2) edit /etc/rc.config.d/netdaemons (fill the NTPDATE_SERVER variable with the ntpd server)
3) reboot
4) clear the NTPDATE_SERVER variable in /etc/rc.config.d/netdaemons

The final one is to prevent long timeouts if you need to reboot the server while the other server is down.

Now setup ntp.conf etc like mentioned before, and you should be fine.

The reboot is needed to inform all processes, like cron, that the timezone has changed. Otherwise strange scheduling might be the result of your actions.