[ntp:questions] Re: ntp synchronisation lost

RichardR randjunk at gmail.com
Sat Mar 19 22:04:47 UTC 2005


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


-- 
Richard RANDRIA
CNRS/IN2P3/LPNHE Jussieu - Paris VI
IT Soft/System Engineer Researcher
--



More information about the questions mailing list