topic Re: xntp strange behaviour in Operating System - HP-UX

xntp strange behaviour

Bar_2 — Mon, 29 Jun 2009 04:36:14 GMT

hey all!
after configed xntp server,but find some information on all our HP-UX server's syslog. what problem??
every HP-UX server configed:
#vi /etc/rc.config.d/netdaemons
export NTPDATE_SERVER=10.150.32.7
export XNTPD=1
#vi /etc/ntp.conf
server 10.150.32.7
fudge 127.127.1.1 statum 10
driftfile /etc/ntp.drift
broadcastclient yes

and syslog was behavior:
Jun 28 23:24:57 hp1 xntpd[7694]: time reset (step) 0.983834 s
Jun 28 23:24:57 hp1 xntpd[7694]: synchronisation lost
Jun 28 23:30:16 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 28 23:32:24 hp1 xntpd[7694]: synchronisation lost
Jun 28 23:33:28 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 00:06:36 hp1 xntpd[7694]: time reset (step) 0.988878 s
Jun 29 00:06:36 hp1 xntpd[7694]: synchronisation lost
Jun 29 00:11:54 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 00:40:46 hp1 xntpd[7694]: time reset (step) 0.982435 s
Jun 29 00:40:46 hp1 xntpd[7694]: synchronisation lost
Jun 29 00:46:04 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 01:28:29 hp1 xntpd[7694]: time reset (step) 0.979637 s
Jun 29 01:28:29 hp1 xntpd[7694]: synchronisation lost
Jun 29 01:33:47 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13

Thanks a lot!

Re: xntp strange behaviour

Bar_2 — Mon, 29 Jun 2009 04:52:46 GMT

and the ntp server was Win2003 server

Re: xntp strange behaviour

Matti_Kurkela — Mon, 29 Jun 2009 08:56:16 GMT

Note: on the "fudge" line, the word after the IP address should be "stratum", not "statum".

You've configured xntpd to use the server's internal clock as one of its time sources (fudge 127.127.1.1 stratum 10). The NTP server 10.150.32.7 gives you stratum 13 time.

Stratum 10 is better than stratum 13, so your configuration is saying that your server's internal clock is more reliable than the NTP server.

On the other hand, your configuration does not actually tell ntpd to _use_ 127.127.1.1 for anything, so the fudge line may not be important.

The stratum value depicts the server's "distance" from a reliable source of time information. Stratum 0 would be e.g. a GPS receiver or an atomic clock itself. Stratum 1 server is directly connected to a stratum 0 device. Any NTP server that gets time from a stratum 1 server becomes itself a stratum 2 server, etc.

Your HP-UX gets stratum 13 time from 10.150.32.7, which means 10.150.32.7 must be at stratum 12. That indicates the quality of 10.150.32.7's time information might not be very good. You can easily get stratum 2 or 3 from most public NTP servers on the Internet.

Because you have just one NTP server configured, your xntpd cannot determine which of the clocks is faulty: the local clock or the 10.150.32.7's clock?

With multiple NTP servers configured, xntpd can identify which time sources seem to agree with each other and ignore the outliers.

If you want to use a public NTP server, pick one that is reasonably close to you, so that the travel time of NTP data packets becomes as small as possible. You can find lists of public NTP servers here:
http://support.ntp.org/bin/view/Servers/WebHome

If you don't have access to any public NTP servers, please read the documentation about the use of the local clock, written by the author of xntpd:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/drivers/driver1.html

MK

Re: xntp strange behaviour

Steven E. Protter — Mon, 29 Jun 2009 09:27:45 GMT

Shalom,

ntpupdate -q

ntp will only update if the server is out of adjustment by less than a few hours.

I've seen some pretty unusual behavior using Windows as an ntp server, and there might be some patching required in that area.

SEP

Re: xntp strange behaviour

Bill Hassell — Mon, 29 Jun 2009 11:56:04 GMT

Windows time servers are notoriously unstable. Find out where the Windows box gets its time. If it is another NTP server, use it rather than the Windows box. Also check with your networking department -- they may have NTP already setup in your firewall so you can use the firewall as your NTP source.

Re: xntp strange behaviour

Bar_2 — Thu, 02 Jul 2009 06:38:06 GMT

very thanks all reply
so i change the config and delete 2 line
then:
#vi /etc/ntp.conf
server 10.150.32.7
driftfile /etc/ntp.drift

after monitor one day,syslog always log,and still time rest and synchronisation lost act again,just like before log.

my environment can't connected internet,can't used public NTP server.
if i set local clock,whether solve my problem?and if can how set config?like this?

#vi /etc/ntp.conf
server 10.150.32.7
driftfile /etc/ntp.drift
fudge 127.127.1.1 stratum 10

stratum level can use number less than 13?

Or can i set ntp to broadcast colock on my loacal net ?
server 10.150.32.7
driftfile /etc/ntp.drift
fudge 127.127.1.1 stratum 10
broadcast ??????

Re: xntp strange behaviour

Matti_Kurkela — Thu, 02 Jul 2009 07:59:09 GMT

To make xntpd use a local clock as a primary synchronization source in your network, configure your /etc/ntp.conf like this:

server 127.127.1.1
fudge 127.127.1.1 stratum 6
broadcastclient no

This tells your xntpd to use your local clock time as a synchronization source (the "server" line), and to assume that it is "better" than the time information from the Windows server (the "fudge" line).

Stratum 6 is still a lot "worse" than a real time source, so if you some day get a connection to a public NTP server or purchase a GPS time receiver, the xntpd will automatically prefer it over the local clock of this server.

Stratum 6 also ensures that if/when the Windows server is configured to synchronize to your HP-UX server, it will prefer the time from HP-UX server over its own local clock.

The "driftfile" line makes xntpd to maintain a correction factor for your local clock. It is used to "auto-calibrate" the local clock over time if you have better timesources. If a connection to better timesources is lost, xntpd will use the correction factor in the drift file to minimize the error of the local clock.

If you want to use broadcast (within a single network segment only), set:

broadcast

MK

Re: xntp strange behaviour

Bar_2 — Thu, 02 Jul 2009 08:54:59 GMT

Dear MK,thank your analyze

if i use local clock like your suggestions in my network,whether my hpux server time was not correct after long period of time?.

One thing was the windows server(10.150.32.7) was ntp server nowï¼ Because it was synchro with the satellite.many servers are synchro with this windowns server,OS include windows/aix/linux.This windows server was an unique timesources on my environment. mean it was only one NTP server.
now my hpux servers's time was often imprecise. so i use NTP config,and want to correct hpux server's time.But the result is time was ok,but syslog note lot of information about synchronized action usualy.