Operating System - HP-UX
1829753 Members
2611 Online
109992 Solutions
New Discussion

Re: Strange NTP behaviour.

 
SOLVED
Go to solution
Leif Halvarsson_2
Honored Contributor

Strange NTP behaviour.

Hi,

We frequenly get the following messages in syslog on all our HP-UX servers.

Jul 21 08:51:46 SRV00408 xntpd[1196]: time reset (step) -0.314608 s
Jul 21 08:51:46 SRV00408 xntpd[1196]: synchronisation lost
Jul 21 08:57:06 SRV00408 xntpd[1196]: synchronized to 10.205.83.2, stratum=6
Jul 21 09:44:02 SRV00408 xntpd[1196]: time reset (step) 0.415413 s
Jul 21 09:44:02 SRV00408 xntpd[1196]: synchronisation lost
Jul 21 09:49:22 SRV00408 xntpd[1196]: synchronized to 10.205.83.2, stratum=6


Is those messages normal or does it indicate problems with NTP client configuration, NTP server or network ?

HP-UX is 11.11, NTP server is Windows 2000 AD server, stratum 6.
5 REPLIES 5
Florian Heigl (new acc)
Honored Contributor
Solution

Re: Strange NTP behaviour.

I'll try to suppress my laughing, ok?

1. Microsoft uses SNTP, which is a smaller implementation of NTP and NOT intended for the things NTP is intended for.

2. Stratum 6 is really shocking, I've never seen a stratum below 4 ;)

3. if You have access to the system You can debug the windows server's time source using the w32tm command, it's verbosity equals ntpdate -v -d, so there's nothing against it.

4. to my eyes, the cause of the error messages You see should be something like the following:

The windows DC is using a single upstratum timeserver which became unrealiable, or there's a few configured which became unavailable.

check this using
net time /querysntp
(will return the full list)
net time /setsntp:"0.pool.ntp.org,1.pool.ntp.org"would possibly fix this, after checking the connectivity (udp port 123) to them with w32tm, of course.

5. if You're not bound to use that server as Your time source: building a reliable infrastructure is about 10 minutes' work, no kidding. I'll add a small overview in a second posting, if You like

6. if You have to use it, please try to do it like the following:

- two of Your servers (think dns servers, etc)connect to him as an upstream source
- they also run a local clock fallback at stratum 16 or so, including a driftfile
- every other host has these two servers as their upstream servers
- if possible still get a GPS/DCF77 clock for each of them and offer them to the windows people as stratum 1 source, they won't say no after some time.
yesterday I stood at the edge. Today I'm one step ahead.
Leif Halvarsson_2
Honored Contributor

Re: Strange NTP behaviour.

Hi,

Thank you for your good explanation. I have also noticed that stratum 6 seems very strange. Earlier, our company had an own NTP server, syncronized from an internet stratum 1 server but for some time ago, we have to use the NTP solution from our parent company (which is out of my control).

Do you know why NTP step the time, instead of slew ? Is there any configuration parameter ?
A. Clay Stephenson
Acclaimed Contributor

Re: Strange NTP behaviour.

You have a real dog for a timeserver and it's always bad to have a single timesource. I would say the minimum is 3. In any event, you can force xntpd to always slew via the "-x" argument.

Edit /etc/rc.config.d/netdaemons and set XNTPD_ARGS="-x" then
/sbin/init.d/xntpd stop
/sbin/init.d/xntpd start

You poor box is probably going to be slewing time almost continuously.

It would be interesting to see the output of
nptp -p yourtimesource
If it ain't broke, I can fix that.
Devender Khatana
Honored Contributor

Re: Strange NTP behaviour.

Hi,

Just a little modifications for the typo is Clay's last post.


->It would be interesting to see the output of
nptp -p yourtimesource.

The command should be "ntpq -p yourtimesource"
or without yourtimesource argument to list all sources.

HTH,
Devender
Impossible itself mentions "I m possible"
Florian Heigl (new acc)
Honored Contributor

Re: Strange NTP behaviour.

If worse comes to worse, fall back to use the local clock with a driftfile at stratum 6, too, and only give additional priority to the w2k server by the 'prefer' statement.

But if the policies require You to use this upstream clock, then You should simply require it to work reliably ;)
yesterday I stood at the edge. Today I'm one step ahead.