[ntp:questions] Re: NTP sync on a standalone network (Windows 2k)
Richard B. Gilbert
rgilbert88 at comcast.net
Thu Aug 17 22:18:22 UTC 2006
Alexandre Carrausse wrote:
> Thanks a lot for your feedback.
> See my comments below.
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
> news:dNWdnQHRI_X9UX7ZnZ2dnUVZ_vGdnZ2d at comcast.com...
>>Alexandre Carrausse wrote:
>>>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)
> 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
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.
>>>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
> 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
> 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.
More information about the questions