topic Re: Strange NTP behaviour. in Operating System - HP-UX

Strange NTP behaviour.

Leif Halvarsson_2 — Thu, 21 Jul 2005 01:51:24 GMT

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.

Re: Strange NTP behaviour.

Florian Heigl (new acc) — Thu, 21 Jul 2005 05:08:04 GMT

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.

Re: Strange NTP behaviour.

Leif Halvarsson_2 — Thu, 21 Jul 2005 08:45:30 GMT

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 ?

Re: Strange NTP behaviour.

A. Clay Stephenson — Thu, 21 Jul 2005 09:31:08 GMT

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

Re: Strange NTP behaviour.

Devender Khatana — Thu, 21 Jul 2005 21:32:49 GMT

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

Re: Strange NTP behaviour.

Florian Heigl (new acc) — Sat, 23 Jul 2005 14:21:51 GMT

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 ;)