[ntp:questions] Re: ntp synchronisation lost

Richard B. Gilbert rgilbert88 at comcast.net
Sun Mar 20 04:57:33 UTC 2005


RichardR wrote:

>My problem still occurs. Still have this lost synchronisation on my
>servers, with a frequency of every 2 or sometimes 4 hours.
>...
>18 Mar 19:28:25 ntpd[13982]: running as uid(38)/gid(38) euid(38)/egid(38).
>18 Mar 19:31:49 ntpd[13982]: kernel time discipline status change 41
>18 Mar 19:48:59 ntpd[13982]: time reset -0.382350 s
>18 Mar 19:48:59 ntpd[13982]: kernel time discipline status change 1
>18 Mar 19:48:59 ntpd[13982]: synchronisation lost
>18 Mar 21:09:24 ntpd[13982]: time reset 0.331918 s
>18 Mar 21:09:24 ntpd[13982]: synchronisation lost
>18 Mar 23:44:18 ntpd[13982]: time reset -0.206934 s
>18 Mar 23:44:18 ntpd[13982]: synchronisation lost
>19 Mar 01:39:54 ntpd[13982]: time reset -0.303490 s
>19 Mar 01:39:54 ntpd[13982]: synchronisation lost
>19 Mar 04:13:56 ntpd[13982]: time reset -0.301352 s
>19 Mar 04:13:56 ntpd[13982]: synchronisation lost
>19 Mar 07:26:14 ntpd[13982]: time reset 0.242884 s
>19 Mar 07:26:14 ntpd[13982]: synchronisation lost
>19 Mar 13:32:30 ntpd[13982]: time reset 0.182526 s
>19 Mar 13:32:30 ntpd[13982]: synchronisation lost
>19 Mar 16:07:14 ntpd[13982]: time reset 0.320246 s
>19 Mar 16:07:14 ntpd[13982]: synchronisation lost
>19 Mar 17:22:16 ntpd[13982]: time reset 0.337548 s
>19 Mar 17:22:16 ntpd[13982]: synchronisation lost
>19 Mar 19:19:51 ntpd[13982]: time reset -0.181323 s
>19 Mar 19:19:51 ntpd[13982]: synchronisation lost
>...
>[root at katy root]# ntpq -pn
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> 127.127.1.0     127.127.1.0     12 l   15   64  377    0.000    0.000   7.812
> 192.168.2.101   0.0.0.0         16 u    5   64    0    0.000    0.000 4000.00
>+192.168.12.100  .GPS.            1 u   71   64  176    7.812  -35.644   7.812
>*192.168.42.100  .GPS.            1 u   72   64  176    7.812  -34.986   7.812
>+200.10.140.2    192.5.41.40      2 u   62   64  177   69.853  -16.457  19.966
>----
>$> cat /etc/ntp.conf
>server ntpcdas  #
>server ntpll        #these 3 machines are our local ntp time server
>server ntpco     #
>server tick.nap.com.ar
>server  127.127.1.0
>fudge   127.127.1.0 stratum 12
>driftfile /etc/ntp/drift
>logfile /var/log/ntp.log
>multicastclient
>broadcastdelay  0.008
>authenticate no
>----
>[root at katy root]# more /etc/ntp/step-tickers
>ntpcdas
>ntpll
>ntpco
>tick.nap.com.ar
>----
>I have changed my ntp clients configurations to a mulitcast mode. And
>yet my servers lost synchronisation and my drift with a tickadj=10000
>always differs.
>These problems don't occur on other servers which have the same ntp config.
>Servers which occur this error, are SUN/AMD64 running under
>RHEL/WS3-kernel 2.4.21 and my other servers are PCs INTEL/PIII running
>under Mandrake/kernel-2.4.18
>
>Need some help and explication about this problem. Have I done
>something wrong in my configurations? or its more about our ntp time
>servers. But why does it work on one server and dont work on another
>with the same config! ???
>Thanks in advance
>Cheers...
>Richard
>
>On Fri, 11 Mar 2005 14:27:15 +0100, RichardR <randjunk at gmail.com> wrote:
>  
>
>>So if I understood your words, this problem could be more about the
>>time server. And this also means that our ntp clients have nothing
>>about hardware problems.
>>Thanks anyway, will to fix that up.
>>
>>On Thu, 10 Mar 2005 21:20:13 +0000, David Woolley
>><david at djwhome.demon.co.uk> wrote:
>>    
>>
>>>In article <mailman.6.1110444367.576.questions at lists.ntp.isc.org>,
>>>RichardR <randjunk at gmail.com> wrote:
>>>
>>>      
>>>
>>>> 7 Mar 13:32:16 ntpd[626]: time reset -0.225222 s
>>>> 7 Mar 13:47:26 ntpd[626]: time reset 0.248564 s
>>>> 7 Mar 14:51:07 ntpd[626]: time reset -0.232833 s
>>>> 7 Mar 15:06:22 ntpd[626]: time reset 0.271954 s
>>>> 7 Mar 15:45:11 ntpd[626]: time reset -0.239905 s
>>>>        
>>>>
>>>This pattern of matched positive and negative steps is typical of a
>>>fast, consumer, connection that occasionally suffers large assymmetric
>>>delays, typically because something is being downloaded.  The duration
>>>and sign of the steps seems to agree with an end user profile (nett
>>>consumer).
>>>
>>>If that is the case, you either need to get traffic over the bottleneck
>>>link (this could be the internal buffering in the time server) prioritised
>>>for NTP, or failing that, to use the tinker huffpuff command, or rebuild
>>>with the maximum root delay set to about 20ms (given you have a very
>>>low normal root delay).
>>>_______________________________________________
>>>questions mailing list
>>>questions at lists.ntp.isc.org
>>>https://lists.ntp.isc.org/mailman/listinfo/questions
>>>
>>>      
>>>
>>--
>>Richard RANDRIA
>>CNRS/IN2P3/LPNHE Jussieu - Paris VI
>>IT Soft/System Engineer Researcher
>>--
>>
>>    
>>
>
>
>  
>
The problem may lie with your operating system!

Linux, along with Windows, has a reputation for losing clock interrupts 
when the system is busy!

If your clock is being updated 1000 times per second, try rebuilding 
your kernel and specifying 100Hz instead of 1000Hz; this sometimes helps.



More information about the questions mailing list