cancel
Showing results for 
Search instead for 
Did you mean: 

NTP sync issue

Mahesh Acharya
Frequent Advisor

NTP sync issue

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
8 REPLIES
Frank de Vries
Respected Contributor

Re: NTP sync issue

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.
Look before you leap
Mahesh Acharya
Frequent Advisor

Re: NTP sync issue

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
Honored Contributor

Re: NTP sync issue

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

Re: NTP sync issue

>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
Honored Contributor

Re: NTP sync issue

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.

there is no rest for the wicked yet the virtuous have no pillows
Mahesh Acharya
Frequent Advisor

Re: NTP sync issue

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
Frequent Advisor

Re: NTP sync issue

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
Honored Contributor

Re: NTP sync issue

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
MK