[ntp:questions] Re: NTP sync on a standalone network (Windows 2k)
alex_s_p_a_m at carrausse.com
Fri Aug 18 21:44:12 UTC 2006
"Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
news:wYCdnSJs15yydnnZnZ2dnUVZ_sCdnZ2d at comcast.com...
> 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
>>>>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 V18.104.22.168 - from David Taylor and I can
confirm that everything is synchronised, so at least my main goal is
If you think there is more I could do (within my constraints), I am open to
>> 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)
>> 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.
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
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
>> 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.
More information about the questions