[ntp:questions] Offset is always increasing

Brian Utterback brian.utterback at oracle.com
Tue May 21 13:02:55 UTC 2013


FORCLIENTS clock has a huge frequency problem, way beyond what NTP can 
correct.

Do this. Disable NTP on FORCLIENTS, then run ntpdate every minute (cron 
would be good here) with "-q" and "-s". You will probably see an 
increasing offset. Check to see if it is monotonically increasing. If it 
occasionally resets or goes backward, then you probably have resync to 
TOD chip and that may be part of the problem. Otherwise, take the offset 
at the end and subtract the offset at the beginning then divide by the 
time between the start and the end. That will give you the drift rate. 
If that rate is larger than 500 parts per million, then NTP cannot 
correct the clock.

On 05/21/13 07:57, Riccardo Castellani wrote:
> I'm using n. 1 ntp server (XNTPD daemon on HP-UX, called FORCLIENTS,
>
> 192.168.1.240) for my clients and I'm obtaining the message
> "synchronization
> lost" about every 20 minutes.
> Source time is another server (MASTER) on my lan
> which updates its time
> directly from Internet servers.
>
>
> MASTER is OK
>
> FORCLIENTS has a high offset !
>
>
> ntp.conf of FORCLIENTS (192.168.1.240):
>
>
> restrict default ignore
> server 10.2.3.5
> driftfile /etc/ntp.drift
> restrict
> 127.0.0.1
> restrict 127.127.1.1
> restrict 10.2.3.5
> restrict 192.168.1.240
>
> restrict 192.168.0.0 mask 255.255.0.0 nomodify noquery
> server 127.127.1.1
> fudge
> 127.127.1.1 stratum 10 # show poor quality
>
>
>
> ntp.conf of MASTER (10.2.3.5):
>
>
> restrict default ignore
> restrict 127.0.0.1
> restrict 192.168.1.240 mask
> 255.255.255.255 nomodify
> restrict ntp1.inrim.it mask 255.255.255.255 nomodify
> noquery notrap nopeer
> restrict ntp2.inrim.it mask 255.255.255.255 nomodify
> noquery notrap nopeer
> restrict ntp1.fau.de mask 255.255.255.255 nomodify
> noquery notrap nopeer
> restrict ntp2.nl.net mask 255.255.255.255 nomodify
> noquery notrap nopeer
> restrict 127.127.1.0 mask 255.255.255.255
> server ntp1.
> inrim.it
> server ntp2.inrim.it
> server ntp1.fau.de
> server ntp2.nl.net
> server
> 127.127.1.0
> fudge 127.127.1.0
> driftfile /var/lib/ntp/drift
>
>
>
>
>
>
>
> My server 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 ?
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


-- 
blu

Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterback at oracle.com



More information about the questions mailing list