[ntp:questions] Re: NTP sync on a standalone network (Windows 2k)

Richard B. Gilbert rgilbert88 at comcast.net
Fri Aug 18 23:51:58 UTC 2006


Alexandre Carrausse wrote:

> "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:
>>>>
>>>>
>>>>
>>>>>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.




More information about the questions mailing list