ntp not sync'ing

[Rick Garland]

Hi all:

Got a L2000 with HPUX 11.00 OS.
Have done the setup for ntp on this system but it will not sync up with the other systems.

I have a stratum 2 server going to the outside atomic clock and it syncs fine. All other clients look to this system for their time and all but 1 system does sync fine with no problems. It would appear that the offset is the issue - 16000+ is the value. Yet when I check the time of the system relative to other systems (with the date command) it returns the correct time, to the second.

Why would the offset be so high? I believe that with the offset so high it will not do its synchronization?

Any ideas?

Many thanks!

[Jeff Schussele]

Hi Rick,

If the offset is too high you should be receiving msgs in syslog.log about this.
Anything in there RE ntp?

Rgds,
Jeff

[Stefan Farrelly]

How about setting NTPDATE_SERVER= in /etc/rc.config.d/netademons so that on next reboot the time on your troublesome server will 'jump' to the exact time on the ntp server. Then it should sync up fine.

[Patrick Wallek]

How long has NTP been running on this box? I see offsets of the 16000 variety after I initially start NTP on a machine. Once it is up and running for a while the offsets go down.

Do you have the latest NTP patch installed? PHNE_27223 is the latest NTP patch for 11.0.

[Steven E. Protter]

Will the ntpq command help with the affected box. Maybe it can help you out.

How about a look at your ntp.conf file.

SEP

[Bill Douglass]

An offset of 16000 means that ntpd cannot sync up with the specified time source. While it always starts out like this, after about 5 1/2 minutes it should lock onto the time server and start showing reasonable values (under a millisecond).

If this is lasting longer than that, you might have a reachability problem.

Try posting the results of ntpq -p and ntpdate -q .

[Rick Garland]

Going nowhere fast.

I have been trying ntpdate with -b and -B as well. Says the offset is getting closer and when it becomes 0 I stop the ntpdate and start the xntpd - which then says my offset is now +18000. I have tried to go direct to the atomic clock with this system to no avail.

I have installed the PHNE patch to no avail. I have left it alone for quite awhile to no avail. The syslog file says it is sync'ing and then right away says the sync is lost. Yet when I check the time on this system (date command) with another system that has sync'ed, there is no visual difference in the time.

Weird...

Any other ideas?

[Rick Garland]

As requested I posted the output of ntpq -p and ntpdate -q . As clarification, I can reach the atomic clocks but the result I am seeing is the same.

I have the NTPDATE_SERVER pointed to the atomic clock, the ntp.conf file has server 204.34.198.41 version 3 prefer
All other systems are sync'ing fine so my ntp.conf and NTPDATE_SERVER is OK. This is the only system that will not sync.
============================

ccitstux # ntpdate -q 204.34.198.41
server 204.34.198.41, stratum 1, offset -18.730867, delay 0.06616
28 May 15:20:02 ntpdate[12718]: step time server 204.34.198.41 offset -18.730867 sec
ccitstux # ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
204.34.198.41 .USNO. 1 u 21 64 7 41.46 -18734. 3885.60
204.34.198.40 .USNO. 1 u 20 64 7 40.28 -18746. 3886.57
ccitstux #

[Steven E. Protter]

Here is an idea.

Some system's clock is running amok?

The outside time source is atomic of course, but what if its going through a firewall and the firewall's clock is interfering.

Or, its a microsoft time source and its not running Unix compliant ntp software.

Dr. David Mills, the guru of ntp has a site that includes more information.

http://www.ntp.org/

http://www.endruntechnologies.com/drivers.htm

Dr. Mills has an email address and takes questions, at least I'm told that.

SEP

[James R. Ferguson]

Hi Rick:

I had an 11.0 server at once time that wouldn't NTP sync either. The latest 'xntpd' patch didn't fix teh problem. As I recall, what did, was correctly setting the server's timezone! Interestingly, Technical Knowledge Base document #4000056006 offers a similar case.

Regards!

...JRF...

[Bill Hassell]

NTP is VERY paranoid about making big changes to the time of day as it can really mess things up. So a large difference between local and NTP time will be ignored and nothing will be done (see syslog.log). Once the time is reasonable close (within a few minutes) then ntpdate -B can 'slew' the clock to catch up. This is a VERY slow process. 10 minutes may require 5 to 7 hours to make the change. ntpdate -b will instantly step the time of day so don't use that unless you are rebooting.

Note that: reach and dispersion are important. When xntpd is first started, reach will be low, then increase slowly towards the max 377 value. Dispersion is an indication of the reliability of the connection, also taking a long time to stabilize. Make sure your server is clean first:

ntpq -p stratum2-server

It should have at least one + in column 1 and a few * entries. Having a single NTP source is not a good idea at all.

[Rick Garland]

Correct, ntp does not like big changes and this becomes more of an issue when dealing with an oracle database - it doesn't like big changes either.

I am still able to check the time on 2 systems (date command) and when I check the times simultaneously the times are the same (near as I can tell by using the whole seconds as reported). Checking the ntpq -p output shows that the offset has increased to +29000 - appears to be getting worse! Jest checked again and it is increasing.

Checked out the Doc ID and when through the motions. Before running set_parms I checked the TZ variable and the /etc/TIMEZONE file, they are correct - EST5EDT. Ran the command anyway, won't hurt anything at this point.

Still looking for ideas...