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?

>
> 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.
>
> 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.
>
> 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)
>
> 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.

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

Upgrade, that's positively ancient. Meinberg has a freely available
binary kit with installer that makes it easy to install.

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

That means that all your clients will drift away from reality, it's not
really getting time from itself, it's just saying that it will hand out
it's time to all who ask even those it's synchronized to nothing. Why
didn't you set up your central server to get it's time from a bunch of
publicly available ntp servers?

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

You don't. You have no time accuracy at all if the central server is not
synchronized to anything.

> 1. 1st question : Is this basic configuration enough?
>

No.

> 2. The command line option in the service properties is greyed? Is there a
> way to specify any options?
>

I don't know what you mean by that. That option is always greyed when
the service is running and can be only used the one time to manually
start the service. What you need is the new version which can take
command-line options and is in the registry as part of the ImagePath in
Services.

> 3. Any recommendations regarding the remote servers? Should we peer them
> with the Central Site?
>

The first question that you need to answer is what is the need for
synchronization? If it is in order to do active directory authentication
then each site could just get its time from publicly available NTP
servers. If you need to keep the time very close to each other you need
to consider a different scheme. We don't know your real requirements so
it's hard to say.

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

Peer the server to what?

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

NTP would panic and exit. Luckily for you you can set the service to run
with the "Change the system time" privilege and not give it to anyone
else and then they couldn't do that unless they had privileges on the
system, in which case they could do what they want.

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

We no longer support that version. Heiko is preparing a stable version
for Meinberg that you can install. What do you mean by default settings?
You really need to specify what it needs in the configuration file
(Meinberg's installer helps with that too).

> 7. What is the purpose of the ntp.drift file? What is the meaning of the
> value contained in this file?

It keeps track of how far off your clock has gotten so that on restart
it can use it as a baseline on what it should use.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Alexandre Carrausse wrote:
>
> 4. Should we peer the server at the central site to keep them more on time

If you must remain completely isolated from the Internet, the only way
to improve the accuracy of your clocks is to set up a reference clock
on your main NTP server. GPS, dial-up service to a national laboratory,
or a radio clock would work, depending on your facilities, location and
budget.

Thanks a lot for your feedback.

See my comments below.


"Richard B. Gilbert" wrote in message
news:dNWdnQHRI_X9UX7ZnZ2dnUVZ_vGdnZ2d@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.

In article <44e3a848$0$896$626a54ce@news.free.fr>,
Alexandre Carrausse 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.

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

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

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.)

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

The frequency error in parts per million.

THanks for your feedback, my comments below



"Danny Mayer" wrote in message
news:44E3D24A.9020402@ntp.isc.org...
> 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
>
> Upgrade, that's positively ancient. Meinberg has a freely available
> binary kit with installer that makes it easy to install.
>
> 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.
>>
>
> That means that all your clients will drift away from reality, it's not
> really getting time from itself, it's just saying that it will hand out
> it's time to all who ask even those it's synchronized to nothing. Why
> didn't you set up your central server to get it's time from a bunch of
> publicly available ntp servers?
>
>> 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.
>>
>
> You don't. You have no time accuracy at all if the central server is not
> synchronized to anything.
>
>> 1. 1st question : Is this basic configuration enough?
>>
>
> No.


OK


>
>> 2. The command line option in the service properties is greyed? Is there
>> a
>> way to specify any options?
>>
>
> I don't know what you mean by that. That option is always greyed when
> the service is running and can be only used the one time to manually
> start the service. What you need is the new version which can take
> command-line options and is in the registry as part of the ImagePath in
> Services.
>



No tested yet, but I guess that I could change the settings in the ntp.conf
file and the daemon would use these parameters when it starts?

I can't really afford to install the new version because it would be a huge
task to migrate.

If the current version we have can provide the service by fine tuning, that
would be enough for me.

>> 3. Any recommendations regarding the remote servers? Should we peer them
>> with the Central Site?
>>
>
> The first question that you need to answer is what is the need for
> synchronization? If it is in order to do active directory authentication
> then each site could just get its time from publicly available NTP
> servers. If you need to keep the time very close to each other you need
> to consider a different scheme. We don't know your real requirements so
> it's hard to say.
>

In fact, because our system is isolated from the real world, we accept the
fact that it could drift from the real time.
However we must ensure that all the machine in the system have the same
time, and that we will never have a machine left unsynchronised with the
others.



>> 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)
>>
>
> Peer the server to what?


My idea was to peer 2 or 3 servers together in the main site, so if one of
the ntp service on the server drift too much the others will keep its time
correct.
(same as having one client getting its time from the server and then become
a server and provide its time to the client isnt it?)

>> 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)
>>
>
> NTP would panic and exit. Luckily for you you can set the service to run
> with the "Change the system time" privilege and not give it to anyone
> else and then they couldn't do that unless they had privileges on the
> system, in which case they could do what they want.
>

That''s a good idea. Is it possible to forbid access clock to an windows
domain administrator? I am afraid not.

What do you mean by "exit"? The daemon stops?

>> 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?
>>
>
> We no longer support that version. Heiko is preparing a stable version
> for Meinberg that you can install. What do you mean by default settings?
> You really need to specify what it needs in the configuration file
> (Meinberg's installer helps with that too).
>


I understand that this version may not be supported, but I would appreciate
if I could find some archive docs or old docs to help me configure it
nicely.


>> 7. What is the purpose of the ntp.drift file? What is the meaning of the
>> value contained in this file?
>
> It keeps track of how far off your clock has gotten so that on restart
> it can use it as a baseline on what it should use.
>
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
>

Thanks, the GPS would be an option, but in the very secure site I am working
in, I am afraid I will not even be allowed to install an antenna.

What is the approx cost of such systems?

Of course our network must remains completely isolated.


"Ry" wrote in message
news:1155822543.251413.219100@i42g2000cwa.googlegr oups.com...
> Alexandre Carrausse wrote:
>>
>> 4. Should we peer the server at the central site to keep them more on
>> time
>
> If you must remain completely isolated from the Internet, the only way
> to improve the accuracy of your clocks is to set up a reference clock
> on your main NTP server. GPS, dial-up service to a national laboratory,
> or a radio clock would work, depending on your facilities, location and
> budget.
>

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

"David Woolley" wrote in message
news:T1155848824@djwhome.demon.co.uk...
> In article <44e3a848$0$896$626a54ce@news.free.fr>,
> Alexandre Carrausse 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
0.000?


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



>
> The frequency error in parts per million.
>

Alexandre Carrausse wrote:

> Thanks a lot for your feedback.
>
> See my comments below.
>
>
> "Richard B. Gilbert" wrote in message
> news:dNWdnQHRI_X9UX7ZnZ2dnUVZ_vGdnZ2d@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?


>
>
> 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)
>>
>>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/browse...tml#networking)


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

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

Alexandre Carrausse wrote:
>
>>> 2. The command line option in the service properties is greyed? Is there
>>> a
>>> way to specify any options?
>>>
>> I don't know what you mean by that. That option is always greyed when
>> the service is running and can be only used the one time to manually
>> start the service. What you need is the new version which can take
>> command-line options and is in the registry as part of the ImagePath in
>> Services.
>>
> No tested yet, but I guess that I could change the settings in the ntp.conf
> file and the daemon would use these parameters when it starts?
>

What options do you think you need? command-line options are almost
always othogonal to configuration file options.

> I can't really afford to install the new version because it would be a huge
> task to migrate.
>

For Windows you can probably use SMS. Most of the effort just requires
copying the files to the right place and maybe updating the registry.
You're not the first to have to do this, others have already worked out
the solutions.

> If the current version we have can provide the service by fine tuning, that
> would be enough for me.
>

We are still not sure of what your needs are. You need to provide that
in order for us to figure out what you need.

>>> 3. Any recommendations regarding the remote servers? Should we peer them
>>> with the Central Site?
>>>
>> The first question that you need to answer is what is the need for
>> synchronization? If it is in order to do active directory authentication
>> then each site could just get its time from publicly available NTP
>> servers. If you need to keep the time very close to each other you need
>> to consider a different scheme. We don't know your real requirements so
>> it's hard to say.
>>
>
> In fact, because our system is isolated from the real world, we accept the
> fact that it could drift from the real time.

You mean WILL drift. Are you saying you have no access whatsoever to
the Internet?

> However we must ensure that all the machine in the system have the same
> time, and that we will never have a machine left unsynchronised with the
> others.
>

And why is it that they need to be synchronized relative to each other?

>>> 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)
>>>
>> Peer the server to what?
>
>
> My idea was to peer 2 or 3 servers together in the main site, so if one of
> the ntp service on the server drift too much the others will keep its time
> correct.
> (same as having one client getting its time from the server and then become
> a server and provide its time to the client isnt it?)
>

You certainly don't want just 2. You need at least 3 and preferably 4
and you need all of the other systems point to all of them as servers.

>>> 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)
>>>
>> NTP would panic and exit. Luckily for you you can set the service to run
>> with the "Change the system time" privilege and not give it to anyone
>> else and then they couldn't do that unless they had privileges on the
>> system, in which case they could do what they want.
>>
>
> That''s a good idea. Is it possible to forbid access clock to an windows
> domain administrator? I am afraid not.
>

Of course it's possible. Each system has it's own privilege list and you
can certainly not provide the domain administrator group with the change
system time privilege. Yes, they can add it back but then you have a
social engineering problem and not a technical problem. If you don't
trust your domain adminstrators you shouldn't let them be domain
administrators.

> What do you mean by "exit"? The daemon stops?
>

Yes, because it cannot correct the error.

>>> 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?
>>>
>> We no longer support that version. Heiko is preparing a stable version
>> for Meinberg that you can install. What do you mean by default settings?
>> You really need to specify what it needs in the configuration file
>> (Meinberg's installer helps with that too).
>>
>
>
> I understand that this version may not be supported, but I would appreciate
> if I could find some archive docs or old docs to help me configure it
> nicely.
>

You haven't said what you expect to be able to configure.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
"Alexandre Carrausse" writes:
>Thanks, the GPS would be an option, but in the very secure site I am working
>in, I am afraid I will not even be allowed to install an antenna.

Do cell phones work in your site? There are NTP boxes that get
their time from the cell phone network.


>What is the approx cost of such systems?

Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
a PC. Old ones are probably OK.

You can buy packaged commercial boxes. I haven't checked prices.
I'd expect several $K.


--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

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

Using a single system as the master seems like a reasonable approach
to me. It's simple so you can understand it. Just fixup the time
by hand when it drifts too far off.

The main source of error in most systems is the initial accuracy
of the crystal when it comes from the factory. That's a constant.
You can measure it and correct for it. After that, your systems
will keep pretty good time. (That's how we used to do it before
NTP.)

The next source of error is the shift in frequency as the temperature
changes. Is the temperature in your bunker stable? If so, that
helps a lot.

Is the load on your system stable or bursty? Self heating is important.
It might help to allocate a separate box to being your NTP server.

adjtimex is the utility to tweak the clock frequency.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote:
> In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
> "Alexandre Carrausse" writes:
>> Thanks, the GPS would be an option, but in the very secure site I am
>> working in, I am afraid I will not even be allowed to install an
>> antenna.
[]
>> What is the approx cost of such systems?
>
> Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
> a PC. Old ones are probably OK.

For example ..

http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm

... including an antenna just poking out of the window. Of course, you
probably can't open the windows either!

David

Alexandre Carrausse schrieb:

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

The ntp.drift file stores the frequency error of the local system
clock, as compared
to the True Frequency (1 second per second) as defined by reference
clock sources
or external, higher-stratum NTP servers. It's used if NTP is stopped
and
restarted for any reason, so that NTP has a good idea of what the
system clock
frequency error might be and can concentrate on correcting phase error.
The frequency error of the local system clock varies due to temperature
changes
and ageing, therefore NTP stores a new value in ntp.drift periodically
(once per
hour according to the documentation). You don't normally have to touch
it --
it all happens automatically.

Read more about this here:
http://www.eecis.udel.edu/~mills/ntp/html/debug.html.

At the moment, my five NTP servers (all Sun SPARC hardware)
have the following values in their ntp.drift files:
-93.879
-22.856
13.594
-54.257
2.227

What do you mean by 'strange values'?

A high value (modulus) means that the free-running frequency of your
system's
local clock is a long way off nominal. A high value is not necessarily
cause for worry;
a value that changes a lot is.

Statistically speaking, it's just about impossible that a real-life NTP
server that's
synchronised to an external time source (UTC) will ever have the value
0.000
in etc.drift. If you see 0.000 under those circumstances, I would bet
that NTP
is not running correctly.

However: If you are running an isolated NTP network with no refclocks
and with
no access to external NTP servers, your highest-stratum server will be
using its
own system clock to synchronize its own system clock, and obviously its
frequency error will be 0.000.

Paul

David J Taylor wrote:
> Hal Murray wrote:
>
>>In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
>>"Alexandre Carrausse" writes:
>>
>>>Thanks, the GPS would be an option, but in the very secure site I am
>>>working in, I am afraid I will not even be allowed to install an
>>>antenna.
>
> []
>
>>>What is the approx cost of such systems?
>>
>>Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
>>a PC. Old ones are probably OK.
>
>
> For example ..
>
> http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm
>
> .. including an antenna just poking out of the window. Of course, you
> probably can't open the windows either!
>
> David
>
>

If his site is really secure, he may have Windows but probably doesn't
have windows!!! His electronic equipment may have to meet the "Tempest"
criteria; e.g. any electromagnetic energy emissions do not contain
recoverable information. Add inner and outer chain link fences topped
with barbed wire, armed guards, and dogs. Your imagination can't be to
vivid!!!! ;-)

Hal,

An EndRun C.ntp CDMA NTP server showed up on my desk one day. It works
anywhere where a CDMA cell phone works. I have in the basement with the
small cell antenna at grade level. Works very well.

If you can borrow a telephone line and modem about once every 36 hours,
the ACTS and USNO drivers perform quite well.

Dave

Hal Murray wrote:
> In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
> "Alexandre Carrausse" writes:
>
>>Thanks, the GPS would be an option, but in the very secure site I am working
>>in, I am afraid I will not even be allowed to install an antenna.
>
>
> Do cell phones work in your site? There are NTP boxes that get
> their time from the cell phone network.
>
>
>
>>What is the approx cost of such systems?
>
>
> Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
> a PC. Old ones are probably OK.
>
> You can buy packaged commercial boxes. I haven't checked prices.
> I'd expect several $K.
>
>

"Richard B. Gilbert" wrote in message
news:cPKdndwstPMAM3jZnZ2dnUVZ_oydnZ2d@comcast.com. ..
> David J Taylor wrote:
>> Hal Murray wrote:
>>
>>>In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
>>>"Alexandre Carrausse" writes:
>>>
>>>>Thanks, the GPS would be an option, but in the very secure site I am
>>>>working in, I am afraid I will not even be allowed to install an
>>>>antenna.
>>
>> []
>>
>>>>What is the approx cost of such systems?
>>>
>>>Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
>>>a PC. Old ones are probably OK.
>>
>>
>> For example ..
>>
>> http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm
>>
>> .. including an antenna just poking out of the window. Of course, you
>> probably can't open the windows either!
>>
>> David
>
> If his site is really secure, he may have Windows but probably doesn't
> have windows!!! His electronic equipment may have to meet the "Tempest"
> criteria; e.g. any electromagnetic energy emissions do not contain
> recoverable information. Add inner and outer chain link fences topped
> with barbed wire, armed guards, and dogs. Your imagination can't be to
> vivid!!!! ;-)

It is not fort knox but almost ;-)
No windows and no telecommunication devices are allowed in the computer
room, no gsm, no antenna, no copper.

Thank your for your help. Today I have tested some monitoring tools, and
overall the situation is good.
Our system is 9 minutes below the real time (my wristwatch:-)

Here is how looks our client tcp.conf file file :

server serverA

As suggested, I am thinking about improving it to have

server serverA
server serverB
server serverC
server serverD
server serverE

On serverA, I am thinking about having the following conf

peer serverB
peer serverC
peer serverD
peer serverE

and so on for BCDE.

Does this make sense?

Alex

"Alexandre Carrausse" writes:
> It is not fort knox but almost ;-)
> No windows and no telecommunication devices are allowed in the computer
> room, no gsm, no antenna, no copper.

If you are allowed to have fiber-optical signals go into the room (but
not out) you might be able to run a GPS in some not quite so secure
area and send only the NMEA and/or PPS into the secure area.

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

"Richard B. Gilbert" wrote in message
news:wYCdnSJs15yydnnZnZ2dnUVZ_sCdnZ2d@comcast.com. ..
> Alexandre Carrausse wrote:
>
>> Thanks a lot for your feedback.
>>
>> See my comments below.
>>
>>
>> "Richard B. Gilbert" wrote in message
>> news:dNWdnQHRI_X9UX7ZnZ2dnUVZ_vGdnZ2d@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/browse...tml#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.