Alexandre Carrausse wrote:
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Alexandre Carrausse wrote:
Thanks a lot for your feedback.
See my comments below.
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Alexandre Carrausse wrote:
Hello,
I want to keep the time sync'd on about 90 machines spreaded on 11
different sites (one central site with the main servers and 10 remote
sites with secondary domain controlers and workstations).
configuration and we are unsure about the time accuracy on our
system.
1. 1st question : Is this basic configuration enough?
That is a question that only you can answer! Does it meet your needs
for accuracy, and tightness of synchronization?
I am not sure that the current conf meet our needs because I have no
means to check it. Maybe Time Server Monitor (which I will test soon)
will help me to find the answer. ;-)
If you can't tell if the clocks are synchronized or not, why do you care?
What problem are you trying to solve here?
I have used the tool NTPmonitor V5.0.6.28 - from David Taylor and I can
confirm that everything is synchronised, so at least my main goal is
reached.
If you think there is more I could do (within my constraints), I am open to
learn.
But providing the fact that the remote clients will sync with the main
time server at the central site, over a 64 kbps network, is it reliable?
It's your net network! You should be in a far better position than I to
say if it's reliable or not. You also need to specify what degree of
reliability you need. If you cannot afford the failure of a network, you
need redundant network connections
Let me ask the question in a different way : is the NTP protocol running
without any problem over a 64 kbps, or is there any configuration to think
about, that would tell the remote "hold on mate, don't be too impatient
because I am sending my packets over a 64 kbps line". I have seen somewhere
that it could be necessary to implement the huff'n'puff option. Is it true?
4. Should we peer the server at the central site to keep them more on
time (9 minutes drift in one year, but the outside world time is not
very important for us)
Suit yourself.
I feel there is a risk of too much drift is my solution is based on only
one server providing the time to all the others... because this network
is isolated from the real world (let's say it's a bunker). If the main
server drift, all the rest of the system will drift.
My thought was that by peering the servers, that would minimise the
drift. If one drift, the others would tell hom : "hold on mate, you're
drifting too far"
If you don't really care about accuracy, why should you care if the whole
network follows a drifting server? Turning a single drifting server into
a committee of drifting servers is unlikely to improve either accuracy,
stability, or reliability. (There is a Sun White Paper that suggests that
unsynchronized peering servers will converge to a common time but I would
not want to count on it. See "Using NTP to Control and Synchronize System
Clocks - Parts I, II, & III.
http://www.sun.com/blueprints/browsesubject.html#networking)
In fact my application which is based on clusters of servers, is running
over DCE Encina (IBM). In order to run, the servers must be very well
synchronised between them, and the time difference must never exceed 180 s.
If the time diff exceeds the threshold, everything will crash and will be
corrupted....
I agree that my solution is not acurate, but it is quite stable (based on
the spec above), and for the reliability, I may have not to rely only on
one time server, but several...
5. What would happen if a silly user change the time by adding lets say
one hour to the main server... would this mistake be cascaded on all the
system? Is there any safety options? (our application would crash if the
time between 2 servers is more than 3 minutes)
NTPD will panic and exit if the error is more than 1024 seconds (about 17
minutes)
What do you mean by exit? He will refuse the clock change? Or the clock
will change but he will refuse to serve possibly wrong time to the
others... Any message logged?
I mean that the ntpd program will stop executing; fold up its tent and go
away!! This is the usual meaning of "exit". No more time synchronization.
OK. So it means that if someone change the time on the main server (+/-1000s
ie approx 20 mins) the NTP daemon will stop to provide time, and all the
machine on the network will start to drift appart?... until someone realise
that the NTPDaemon is not started.
A sixty-four KBPS link is slow but if it's not carrying a lot of other
traffic it should work. Problems will show up if the transmission
delays are not symmetric; e.g. if it take 1.1 milliseconds to go from
point A to point B and 1.2 milliseconds to go from point B to point A
that asymmetry is going to show up as an error in your time. If the
link is loaded so that you can hardly slip a packet in edgewise, it's
not going to work very well for NTP.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
