XNTPD synchronisation lost

[RiclyLeRoy]

I'm obtaining this message about every 20 minutes on my server; my log shows:

20 May 14:38:20 xntpd[19386]: synchronized to LOCAL(1), stratum=10
20 May 14:39:23 xntpd[19386]: synchronized to 10.2.3.5, stratum=2
20 May 14:54:18 xntpd[19386]: time reset (step) -1.014343 s
20 May 14:54:18 xntpd[19386]: synchronisation lost
20 May 14:58:35 xntpd[19386]: synchronized to LOCAL(1), stratum=10
20 May 14:59:38 xntpd[19386]: synchronized to 10.2.3.5, stratum=2
20 May 15:14:33 xntpd[19386]: time reset (step) -1.010761 s
20 May 15:14:33 xntpd[19386]: synchronisation lost
20 May 15:16:08 xntpd[13208]: logging to file /var/adm/syslog/ntp.log
20 May 15:16:08 xntpd[13208]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
20 May 15:16:08 xntpd[13208]: precision = 6 usec
20 May 15:17:29 xntpd[14031]: logging to file /var/adm/syslog/ntp.log
20 May 15:17:29 xntpd[14031]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
20 May 15:17:29 xntpd[14031]: precision = 10 usec
20 May 15:21:46 xntpd[14031]: synchronized to 10.2.3.5, stratum=2
20 May 15:21:46 xntpd[14031]: time reset (step) -0.216182 s
20 May 15:21:46 xntpd[14031]: synchronisation lost
20 May 15:26:03 xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May 15:27:06 xntpd[14031]: synchronized to 10.2.3.5, stratum=2
20 May 15:42:01 xntpd[14031]: time reset (step) -1.005840 s
20 May 15:42:01 xntpd[14031]: synchronisation lost
20 May 15:46:18 xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May 15:47:21 xntpd[14031]: synchronized to 10.2.3.5, stratum=2
20 May 16:02:16 xntpd[14031]: time reset (step) -1.009925 s
20 May 16:02:16 xntpd[14031]: synchronisation lost
20 May 16:06:33 xntpd[14031]: synchronized to LOCAL(1), stratum=10
20 May 16:07:36 xntpd[14031]: synchronized to 10.2.3.5, stratum=2

nptd -qn  shows:

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
 10.2.3.5     193.204.114.232  2 u   16   64    7     1.92  -158.96 3927.72
 127.127.1.1     127.127.1.1     10 l   15   64   17     0.00    0.000 1885.01

My time source server is ok (10.2.3.5) and I can exclude problems into my lan.

     remote           local      st poll reach  delay   offset    disp
=======================================================================
=ntp1.nl.uu.net  10.2.3.5    1 1024  377 0.04411 -0.003625 0.12183
=ntp1.inrim.it   10.2.3.5    1 1024  377 0.01971 -0.000409 0.12172
*ntp2.inrim.it   10.2.3.5    1 1024  377 0.01923 -0.000046 0.12175
=LOCAL(0)        127.0.0.1       10   64  377 0.00000  0.000000 0.03072
=ntp1.rrze.uni-e 10.2.3.5    1 1024  377 0.05191 -0.009084 0.12178

Can you indicate suggestions please ? The problem is Offset bigger 128 ms ?!?! Offset is increasing until to 700-800 ms.

I run ntpdate to update immediately clock and I can see small offset but after few minutes grows again until to exceed 128 ms.

How can I solve it ?

[Bill Hassell]

What type of server is your local NTP stratum? Windows has a very crude implementation for NTP.  In many data centers, a firewall will provide a stable stratum between outside NTP servers and internal clients. And most flavors of Unix (Linux, HP-UX, etc) can provide stable sources.

[Matti_Kurkela]

Your dispersion (the "disp" field) value is huge: 3927.72.

In other words, the average offset is -158.96 ms, but the actual offset value varies wildly from one poll to the next.

This might indicate a very congested network between you and the time server, so some packets get delayed for a long time, and others don't.

Although you seem to have a rather huge dispersion value with the local clock (127.127.1.1) too. (How is that even possible???)

Is this system a a virtual machine (an Integrity VM) guest by any chance?

Or maybe this particular system just has a very bad timekeeping clock. What hardware model is it? Is it up to date with firmware and kernel patches?

[RiclyLeRoy]

My local NTP (used from clients) is s blade HP BL860c with 2 CPU, where each one is DualCore Intel Itanium 2 - 1666 MHz

OS is OS is HP-UX B.11.31 U ia64

xntpd daemon is running from anout one year but now I saw problem, drift file contains 855 as value

[RiclyLeRoy]

it's pshisical machine and I run again 'ntpq -pn'

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*10.2.3.5    193.204.114.233  2 u   59   64  377     0.38  -477.22  102.58
 127.127.1.1     127.127.1.1     10 l   58   64  377     0.00    0.000   10.01

I have to verify firmware and kernel patches

[Matti_Kurkela]

Now it's in sync with the 10.2.3.5 time server, and the values look much more reasonable.

Although the dispersion is still rather high. For xntpd to keep reliably in sync, it should stay below 100.

Unless this system is also acting as a NTP server, you should probably remove the local clock entry (127.127.1.1): since the delay/offset/dispersion values are all calculated using the local clock as a baseline, the local clock will always seem to be very good, even if it is not correct.

And if you have just two timeserver entries (including the local clock entry), the system has no way to know which one is correct. If the difference between the local system clock and the time server value is too great, your system may pick the 127.127.1.1 "timesource" instead (because it is always very much in agreement with the local system clock). Once it does that, your system clock is effectively not regulated by NTP any more, and is free to drift even further away from the true time. Xntpd will be happy: it has one perfectly good timeserver 127.127.1.1, and the difference between it and 10.2.3.5 is so great that 10.2.3.5 must be ignored, no matter what the stratum value says...

You should only use timesource 127.127.1.1 if your system acts as a NTP server to other servers at your site.

(If xntpd has no reachable timesource to sync with, it won't provide NTP service to other hosts.)

Even if you use 127.127.1.1, you should configure at least two other timesources, so that the local clock can be "voted out" by other timesources if it is grossly wrong.