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@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@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 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
> wrote:
> > In article ,
> > RichardR 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@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
-- |