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

Alexandre Carrausse alex_s_p_a_m at carrausse.com
Thu Aug 17 21:19:03 UTC 2006


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).
>>
>> All the servers are W2K server and all the workstation are W2K Pro SP4.
>>
>> It is important to note that all the links between the sites are running 
>> a 64 kbps, through a dedicated WAN.
>>
>> We are currently using NTP 4.1.72 which is running as a service  and has 
>> the minimal configuration, ie all clients getting their time from the 
>> "main central server". The server is getting its time from itself, ie 
>> 127.127.1.0.
>>
>> But we are not sure that we are having a good "state of the art" 
>> 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. ;-)


>
>>
>> 2. The command line option in the service properties is greyed? Is there 
>> a way to specify any options?
>>
>> 3. Any recommendations regarding the remote servers? Should we peer them 
>> with the Central Site?
>
> No.  I don't think there is any point.


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?



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


>>
>> 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?

In such situation, it would be nice to have at least another server 
continuing to serve time...

>>
>> 6. I have found a  lot of litteracy on 
>> http://www.eecis.udel.edu/~mills/ntp/, and nice tools on ntp.org, but 
>> where can I find any specific information about the NTP 4.1.72 for W2K 
>> software? What are the defaults settings compiled in this version?
>>



>> 7. What is the purpose of the ntp.drift file? What is the meaning of the 
>> value contained in this file?
>
> The drift file is used to store the current frequency correction to your 
> local clock.  It is updated once per hour.  In a more "normal" 
> configuration, it would help ntpd synchronize more quickly.  I wouldn't 
> attempt to guess whether it would help or hurt in your configuration. The 
> value is the frequency correction expressed in Parts per Million. 





More information about the questions mailing list