topic Re: NTP OFFSET keep increasing in Operating System - HP-UX

NTP OFFSET keep increasing

Denis F — Thu, 27 Aug 2009 10:51:06 GMT

hello

I have some probleme to understand why my NTP OFFSET is increasing.

ntpq -p is showing a OFFSET value a bit high.

ntpq -pn
remote refid st t when poll reach delay offset disp
==============================================================================
*10.198.4.50 193.49.205.17 2 u 57 64 377 14.80 783.018 109.13
139.160.254.11 10.198.8.30 6 u 154 1024 377 14.13 381.335 158.78

but ntptrace is showing a offset value reasonable.

ntptrace 10.198.4.50
pfrxntp1.fr.schneider-electric.com: stratum 2, offset 0.002824, synch distance 0.70334
xoon.curie.fr: stratum 1, offset -0.600826, synch distance 0.00032, refid 'PPS'

thanks to help me how to resolv this

Re: NTP OFFSET keep increasing

mvpel — Thu, 27 Aug 2009 11:28:31 GMT

Your dispersion numbers are extremely high. this is going to limit how well NTP is able to synchronize the clock. Under ideal circumstances, your dispersion should be far less than one millisecond, not 0.11 or 0.16 seconds as shown here.

Also, I'm puzzled by the fact that two servers with roughly the same 14ms delay are so far apart in stratum - one is a stratum 2 and the other is a stratum six. I typically try to avoid having clients chiming to anything lower than a stratum 3, or 4 in a pinch.

Can the 139.160 host peer with or become a client of the 10.198 host, or use the stratum 1 time server that it's using?

The key to good time synchronization is consistency - you need to have a very stable round-trip time between the two hosts, and very stable time on the servers. Check to be sure that a 60-second ping session to the hosts has minimum and maximum round-trip times that are very close together. The lower the difference, the lower the dispersion, and the better the time sync.

Re: NTP OFFSET keep increasing

BUPA IS — Thu, 27 Aug 2009 11:47:43 GMT

Denis,
It is possible that the link to the stratum 2 server is unreliable and when it fails it falls back to the stratum 6 one. Since these two are not telling exactly the same time then local offset does not improve. The difference in stratum should not matter.
By the way the offet to the server you are currently in sync with (*) will always look good .
It is not shown in your post Does the ntp -q show a local clock as well ?
Please post the output of
xntpdc -c sysi
xntpdc -c loopi
and a trace the to other time server.

Are ther any ntpd messages in the syslog?

Mike

Re: NTP OFFSET keep increasing

Denis F — Fri, 28 Aug 2009 11:17:37 GMT

hello,

first thanks all for your fast reply.

regarding mvpel question , I dont know if second server is client of server one or if it using the stratum 1.

for BUPA question, I dont have local clock output with ntpq -p command. and it's really strange that the stratum change randomly .

xntpdc -c sysi
system peer: pfrxntp1.fr.schneider-electric.com
system peer mode: client
leap indicator: 00
stratum: 3
precision: -17
root distance: 0.02084 s
root dispersion: 0.17859 s
reference ID: [10.198.4.50]
reference time: ce412236.42fcd000 Thu, Aug 27 2009 17:18:14.261
system flags: monitor pll stats
frequency: 0.000 ppm
stability: 92.654 ppm
broadcastdelay: 0.003906 s
authdelay: 0.000122 s

xntpdc -c loopi
offset: 0.096315 s
frequency: -210.659 ppm
poll adjust: -30
watchdog timer: 6 s

I have also trace the 2nd ntp server which is in timeout.

ntptrace -d pfrxntp2.fr.schneider-electric.com
pfrxntp2.fr.schneider-electric.com: DoTransmit(139.160.254.11)
DoTransmit to 139.160.254.11
ReceiveBuf(139.160.254.11, 139.160.254.11)
stratum 6, offset 0.174974, synch distance 0.01022
10.198.8.30: DoTransmit(10.198.8.30)
DoTransmit to 10.198.8.30
ReceiveBuf(10.198.8.30, 10.198.8.30)
stratum 5, offset 0.180321, synch distance 0.00000
78.79.86.76: DoTransmit(78.79.86.76)
DoTransmit to 78.79.86.76
timeout
DoTransmit(78.79.86.76)
DoTransmit to 78.79.86.76
timeout
DoTransmit(78.79.86.76)
DoTransmit to 78.79.86.76
timeout
DoTransmit(78.79.86.76)
DoTransmit to 78.79.86.76
timeout
DoTransmit(78.79.86.76)
DoTransmit to 78.79.86.76
timeout
*Timeout*

sorry for my understanding but i am a bit lost with this NTP protocol.

I suspect some network issue , cause by checking the ntpq -p output , the value has changed totaly

ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*pfrxntp1.fr.sch xoon.curie.fr 2 u 60 64 377 14.02 92.343 2.67
pfrxntp2.fr.sch 10.198.8.30 6 u 363 1024 377 14.34 177.643 38.77

there is also some xntpd log in the syslog

ll /var/adm/syslog/syslog.log
-rw-r--r-- 1 root root 6946316 Aug 27 17:29 /var/adm/syslog/syslog.log

cat /var/adm/syslog/syslog.log | grep "synchronisation lost" | wc -l
1734

tail -100 /var/adm/syslog/syslog.log | grep xntpd
Aug 27 16:39:15 frsapprd xntpd[26745]: synchronized to 10.198.4.50, stratum=2
Aug 27 16:48:52 frsapprd xntpd[26745]: time reset (step) 0.848997 s
Aug 27 16:48:52 frsapprd xntpd[26745]: synchronisation lost
Aug 27 16:54:12 frsapprd xntpd[26745]: synchronized to 139.160.254.11, stratum=6
Aug 27 16:59:32 frsapprd xntpd[26745]: synchronized to 10.198.4.50, stratum=2

Re: NTP OFFSET keep increasing

Rita C Workman — Fri, 28 Aug 2009 11:24:52 GMT

If your time is too far off, then ntp can't catch it up well. That is when you need to 'fix' it by manually resetting the servers clock and then allowing ntp to take back over to keep it in sync.
You have to make sure when you reset it you don't create a timestamp issue. So best if you can have apps down. If not, just remember it's okay to reset going forward, but going backwards can cause you issues.

Now....since your stratum 2 clock seems to be having issues, you might want to check on the internet site you got this clock address from. It is not uncommon for some internet-clock-IP's to get retired or oversubscribed. These conditions are often reported on the site, thus giving you the choice to move to another time-supplier.
Not long ago I found that one of the addresses I was pointed to went "offline" and I had to make the switch.

Just a thought,
Rgrds,
Rita