Dirk Langner wrote: > Hello everybody, > > We're facing a problem, that we have ntp-servers with synchronized > system time by an external clock. The ntp servers are now distributing > the (synchronized) time to all other servers. This works well at the > first time, the ntp-servers are seen as peers on most of the clients, > sanity checks are passed. But it seems that after a while the ntp > clients are going to reject all their servers due to not passing the > sanity checks, which means, that the time is not synchronized any more > on those systems. > > The paper "Using NTP to Control and Synchronize System Clocks - Part > III" by Sun blueprints Online says in NTP Algorithms/Sanity Checks, step > 6: "...that servers, which are not connected to a root time source, will > be ignored." So is this now the reason why the ntpclients are going to > reject the servers or am I missing something? And if so: is there any > chance to get the system time (which is synchronized - see below) > distributed via NTP? >
The proper source are the documents on the ntp.org web sites. > Some words to the setup: > Four ntp-servers ntpserver[1-4] are synchronized via serial lines to a > single external timesource. Why would they be synchronized to a *single* external timesource? The recommended guidelines is at least 3 and preferably 4. On these system a deamon (which does mainly > other things) adjusts the system time according to these serial signals > at least every 10 minutes. What daemon? If it's not NTP then it's all over. I can't switch to other / external ntp > servers, since I need this one and only time (broadcast environment) and > the servers are sitting on an isolated network. The external device is a > LTC timecode converted by a Miranda Littlered, the serial signals are > processed by a deamon, which is exclusively connected to the serial > port. Is this supposed to be a refclock? Does it have a refclock driver? > > ntpserver1 8# more /etc/ntp.conf > # Generic ntp.conf file > # > # See documentation for more options > # > # add as many server as required > server 127.127.1.0 > fudge 127.127.1.0 stratum 0 refid LTC1 DO NOT DO THIS. Stratum 0 is reserved for refclocks and your server is not a refclock. The local clock like this is for systems that lose their connection to a higher stratum clock. Usually this is set to 10 for a local clock. > > broadcast 192.168.58.255 ttl 2 > > driftfile /etc/ntp.drift > > # don't set local clock > disable ntp > > This last setting is necessary to disable the setting of the system > clock by ntp, the system time of the ntp-server shall exclusively set by > the deamon. > That's not necessary as it cannot set the clock anyway with this setup. > The ntp clients listen to only these servers. > ntpclient 14# more /etc/ntp.conf > # Generic ntp.conf file > # > # See documentation for more options > # > # add as many server as required > server ntpserver1 prefer Why is this one preferred over all the others? > server ntpserver2 > server ntpserver3 > server ntpserver4 > > driftfile /etc/ntp.drift > > # monitor no > # authenticate no > # > broadcastclient yes The only argument that broadcastclient takes is novolley. > # multicastclient > > Especially if the ntp deamon is started on one ntp-server, this server > is picked up as a peer (or at least a candidate). You didn't specify any peers so what do you mean by that? > ntpclient 3# ntpq > ntpq> pe > remote refid st t when poll reach delay offset > jitter > ======================================================================== > ====== > *ntpserver1 .LTC1. 1 u 20 64 377 0.502 -32.966 > 0.258 > +ntpserver2 .LTC1. 1 u 25 64 377 0.441 -32.922 > 0.155 > +ntpserver3 .LTC1. 1 u 51 64 377 0.511 -33.044 > 0.224 > -ntpserver4 .LTC1. 1 u 11 64 377 0.431 -33.129 > 0.098 > version="ntpd [EMAIL PROTECTED] Wed Jan 19 14:18:56 PST 2005 (1)", That's a little old. The latest release version is 4.2.2. > > After some time the servers are going to be rejected, although the > sanity checks are passed. The associations are going to be > What makes you think that the sanity checks are passed? What evidence do you have? All the indications are that they did not pass. > ntpclient 2# ntpq > ntpq> pe > remote refid st t when poll reach delay offset > jitter > ======================================================================== > ====== > ntpserver1 .LTC1. 1 u 44 64 377 0.033 88339.7 > 28.006 > ntpserver2 .LTC1. 1 u 48 64 377 0.064 88338.0 > 27.700 > ntpserver3 .LTC1. 1 u 59 64 377 0.059 88333.4 > 27.613 > ntpq> ass > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 60236 9034 yes yes none reject reachable 3 > 2 60237 9034 yes yes none reject reachable 3 > 3 60238 9034 yes yes none reject reachable 3 > ntpq> readvar > status=00f4 leap_none, sync_unspec, 15 events, event_peer/strat_chg, > version="ntpd [EMAIL PROTECTED] Wed Jan 19 14:18:56 PST 2005 (1)", > processor="IP35", system="IRIX646.5", leap=00, stratum=16, > precision=-18, rootdelay=0.442, rootdispersion=4115.402, peer=0, > refid=ntpserver1, > reftime=c9249b12.cc18c5c9 Sat, Dec 9 2006 3:16:50.797, poll=4, > clock=c927cc57.727e846a Mon, Dec 11 2006 13:23:51.447, state=2, > offset=0.000, frequency=-259.475, jitter=13.014, stability=213.142 > Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
