topic Re: NTP sync issue in Operating System - HP-UX

NTP sync issue

Mahesh Acharya — Thu, 05 Feb 2009 13:10:43 GMT

We have a HPUX PARISC system which is synced with a NTP server. Rest of the systems (all PARISC) are synced with this HPUX system except for the 2 HPUX 11.23 Itanium servers (both are clustered)
Difference we found is that on the PARISC systems timezone is set as 'uae-4' whereas on IA its 'UAE-4' (caps). Are these the same?
also from the IA system, ntpdate -d shows that the reference and originate timestamp has the eyar 2036, whereas the transmit timestamp shows todays date.
ntpdate , says not suitable server found.
Please let me know how this can be resolved.
Thank you

Re: NTP sync issue

Frank de Vries — Thu, 05 Feb 2009 13:20:12 GMT

I checked our PA-RISC systems
although we are in a different TZ,
they are all in capitals nevertheless.

root@orasrv1:]/root<>>> print $TZ
MET-1METDST

I would stick to this convention
and stay consistent.

Re: NTP sync issue

Mahesh Acharya — Thu, 05 Feb 2009 13:28:55 GMT

Here is the output of ntpdate -d ium1, though date on both the system differs by only 30 seconds. Only differences are
1. ium1 is PARISC, ovo-2 is a IA
2. Timezone difference in terms of case (uae-4 Vs UAE-4)

ovo-2:/# ntpdate -d ium1
transmit()
transmit()
transmit()
transmit()
transmit()
server , port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 10:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 10:28:16.000
transmit timestamp: cd355f5e.99c10000 Thu, Feb 5 2009 16:51:42.600
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

5 Feb 16:51:43 ntpdate[22080]: no server suitable for synchronization found

Re: NTP sync issue

smatador — Thu, 05 Feb 2009 14:00:27 GMT

Hi
Do you look at Troubleshooting ntp
http://docs.hp.com/en/B2355-90685/ch07s03.html

Re: NTP sync issue

Dennis Handly — Thu, 05 Feb 2009 23:09:26 GMT

>Difference we found is that on the PA systems timezone is set as 'uae-4' whereas on IA its 'UAE-4' (caps). Are these the same?

Since neither of these is in tztab, only the -4 is important. In any case, TZ has no effect on NTP since that works on UTC.
As Frank said, it is probably better to have it in caps.

Re: NTP sync issue

rick jones — Fri, 06 Feb 2009 00:25:54 GMT

Looks like the ntpd on ium1 (?) isn't synced. If an ntpd is not synced to a time source, it will not serve time to others.

Re: NTP sync issue

Mahesh Acharya — Sat, 07 Feb 2009 07:08:07 GMT

ium1 is synced with a NTP server (strtum 4).
Other 5 servers are synced with ium1, excpt for the 2 itanium servers.
In the /etc/ntp.conf of each of the 5 servers its cpnfigured as server ium1

Other difference is that the 5 servers are located in one data center (in the same rack) whereas the other 2 servers are in a different data center.

Re: NTP sync issue

Mahesh Acharya — Sun, 08 Feb 2009 07:20:54 GMT

I am more worried about the difference shown with ntpdate -d command

reference time: 00000000.00000000 Thu, Feb 7 2036 10:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 10:28:16.000
transmit timestamp: cd355f5e.99c10000 Thu, Feb 5 2009 16:51:42.600

The reference and originate timestamp difference are totally out of place.

Re: NTP sync issue

Matti_Kurkela — Sun, 08 Feb 2009 09:23:33 GMT

The raw form of both reference and originate timestamps are all zeroes... so I guess the server gave the bare minimum response to your ntpdate client. The ntpdate command seems to understand this, as it did not calculate any delay/offset values based on that future time.

Check the configuration of ium1. Does it contain any "restrict" keywords? They might prevent ium1 from providing the full NTP service to this client.

MK