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?
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
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)
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.
In such situation, it would be nice to have at least another server
continuing to serve time...
If you want stability, reliability, and accuracy, it can be done but you
need to think about it a little harder. My solution would be to
purchase some Garmin GPS18LVC timing receivers. They cost about $85
each. Connect them to your primary servers as reference clocks. If you
have four of them, any single server or reference clock can fail and you
will still have accurate time and tight synchronization. There would be
no advantage to peering them since they would all be getting time from
the same satellites. With a server marching along at a rock solid one
second per second pace everybody should be able to get in step with it.
This does require that you be able to site an antenna where it will have
an unobstructed view of the sky. Other types of reference clocks could
also be used. If you are located where you can get reliable reception
of the NIST HF time broadcast (2.5, 5.0, 10.0, 15.0, 20.0 or 25.0 MHz)
you can use an HF radio receiver to pick up the signal and decode it
using a sound card and the appropriate refclock driver. If you are not
relatively close to Fort Collins, Colorado you may have problems
receiving a usable signal.
You could decide to use a single server and reference clock and accept
the fact that some day it will fail. Can you afford to fix it and go
on? If absolutely cannot tolerate failure then you need to build in
redundancy with multiple servers and refclocks.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
