NTP sync issue

[Mahesh Acharya]

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

[Frank de Vries]

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.

[Mahesh Acharya]

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

[smatador]

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

[Dennis Handly]

>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.

[rick jones]

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.

[Mahesh Acharya]

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.

[Mahesh Acharya]

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.

[Matti_Kurkela]

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