[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:59:48 UTC 2006

Thanks again. Your comments are very interesting.
See my comments below

"David Woolley" <david at djwhome.demon.co.uk> wrote in message 
news:T1155848824 at djwhome.demon.co.uk...
> In article <44e3a848$0$896$626a54ce at news.free.fr>,
> Alexandre Carrausse <alex_s_p_a_m at carrausse.com> wrote:
>> 1. 1st question : Is this basic configuration enough?
> It is an out of specification configuration because it doesn't have
> a proper source of true time.

I agree
But the main spec for our system is only to have all the local clocks syncd 
together, and ensure there is not an incident (such as having a machine 
running 10 minutes behind the other because an admin has decided to change 
the clock to meet his watch)
The fact that the system is not "on time" with the real world is not an 
issue (or a minor issue)

>> 3. Any recommendations regarding the remote servers? Should we peer them
>> with the Central Site?
> No.  It is a bad idea to peer servers running with an undiscplined local
> clock.  Moreover, all the machines except the central server are leaf
> node, so should not have a local clock driver configured.  In cases where
> you are dealing with an intermediate node and the advantages of letting
> it be a local fall back server outweigh the disadvantages, its local
> clock should have a stratum two higher from the machine serving it and
> there should be a simple client server relationship.

I am not sure to understand. My question was only intended to clarify 
whether there is a risk that the remote pcs are not correctly syncd with the 
central because they are linked to the central computer room by a slow 
connection (64 kps wan)

>> 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)
> To what?  As noted above, peering machines with just local clock drivers
> is a bad idea.  There should be an unabiguous hierarchy.

What would be the best hierarchy ?

Central server -> 64 kbps --> Remote clients
Central servers -> 64 kbps --> Remote server -> 100 mbps --> Remote clients

Would you have several servers providing time at the Central site? And how 
to rank them?

> One of the disadvantages of using a pure local clock driver is that the
> server might have a crystal at the +500ppm limit, which would mean that
> any client with a clock with even just a very small negative error would
> be unable to synchronise.  Your case is not as bad as this, but as,
> providing you don't lose interrupts, 30 seconds a  year should be possible
> in a machine room, you should use ntp.drift to calibrate out the current,
> modest, 17.1 part per million error.  (If the people in the thread about
> PC clocks is reading this, this is quite typical for PC clocks, but even
> several 100 is not uncommon.)

We are using DELL PowerEdge SC420 servers (quite cheap), we are trying to 
the most of them ;-)

>> 7. What is the purpose of the ntp.drift file? What is the meaning of the
>> value contained in this file?
> To remember the measured frequency error to allow a fast re-acquisition.

I am still not getting the purpose of this file. Is the value inside this 
file supposed to change? Or is this value configured by someone for good. 
Should I become worried if I see some strange values in those files?
What is the meaning of a high value? Is it good or bad if the value is 

Thanks a lot. NTP seems very powerful, but not easy to handle for a newbie.

> The frequency error in parts per million.

More information about the questions mailing list