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?

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?

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)

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)

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?

Any advise greatly appreciated.

Regards,

Alex 

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.

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

> 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 a lot for your feedback.

See my comments below.


"Richard B. Gilbert" <rgilbert88@comcast.net> 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. 

THanks for your feedback, my comments below



"Danny Mayer" <mayer@ntp.isc.org> 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" <malayter@gmail.com> wrote in message 
news:1155822543.251413.219100@i42g2000cwa.googlegroups.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" <david@djwhome.demon.co.uk> wrote in message 
news:T1155848824@djwhome.demon.co.uk...
> In article <44e3a848$0$896$626a54ce@news.free.fr>,
> Alexandre Carrausse <alex_s_p_a_m@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 
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" <rgilbert88@comcast.net> 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/browsesubject.html#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" <alex_s_p_a_m@carrausse.com> 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" <alex_s_p_a_m@carrausse.com> 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/ntp/FreeBSD-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" <alex_s_p_a_m@carrausse.com> 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/ntp/FreeBSD-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" <alex_s_p_a_m@carrausse.com> 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" <rgilbert88@comcast.net> 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" <alex_s_p_a_m@carrausse.com> 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/ntp/FreeBSD-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" <alex_s_p_a_m@carrausse.com> 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" <rgilbert88@comcast.net> wrote in message 
news:wYCdnSJs15yydnnZnZ2dnUVZ_sCdnZ2d@comcast.com...
> Alexandre Carrausse wrote:
>
>> Thanks a lot for your feedback.
>>
>> See my comments below.
>>
>>
>> "Richard B. Gilbert" <rgilbert88@comcast.net> 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/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.

"Wolfgang S. Rupprecht" 
<wolfgang+gnus20060818T141853@dailyplanet.dontspam.wsrcc.com> wrote in 
message news:87mza1zqnv.fsf@bonnet.wsrcc.com...
> 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.

I agree but the link between the GPS antenna and the secure area will be 
coper, not fiber.

Are you aware of a GPS solution that would use fiber?










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

"Hal Murray" <hmurray@suespammers.org> wrote in message 
news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d@megapath.net...
> 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.

That's my plan. Today my system is 9 minutes below the real time. I can't 
add 9 minutes in one go otherwise everything would crash. But I could add 
one minute every morning during nine days and it would be fine.


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

The aircon system is good so I am quite confident that it is stable.

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


The load is stable on the main server as it is only providing the active 
directory. Not very busy (not like a db backup).

> adjtimex is the utility to tweak the clock frequency.

Seems interesting in the long run.
The only data I have found looks like code to be compiled for Unix. Anything 
ready for Windows?


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

Alexandre Carrausse wrote:

> "Richard B. Gilbert" <rgilbert88@comcast.net> 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" <alex_s_p_a_m@carrausse.com> 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/ntp/FreeBSD-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
> 

If you are not allowed ANY external reference, I suppose it's the best 
you can do.  Your cell phone has time that is correct to within a few 
microseconds.  Of course it probably only displays hours and minutes but 
the rollover of the minute should be within microseconds.   From that 
you can probably set your watch within a second or so if you have good 
reflexes.

Set the correct time on your server(s) and let them run for, say, seven 
days.  You will need to know the exact time you set and the exact error 
seven days later.  Knowing how far the servers drifted in seven days, 
you should be able to compute a frequency correction in parts per 
million.  The number you come up with should have an absolute value of 
less than 500 and probably will be less than 50.  Put this number in 
your drift file (or use it in adjtimex()or equivalent) to correct your 
freqency.  For a check, 500 PPM works out to something like 43.2 seconds 
per day.  It's hardly state-of-the-art timekeeping but I don't know what 
else you can do.

Alexandre Carrausse wrote:

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

Alexandre Carrausse wrote:

> "Wolfgang S. Rupprecht" 
> <wolfgang+gnus20060818T141853@dailyplanet.dontspam.wsrcc.com> wrote in 
> message news:87mza1zqnv.fsf@bonnet.wsrcc.com...
> 
>>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.
> 
> 
> I agree but the link between the GPS antenna and the secure area will be 
> coper, not fiber.
> 
> Are you aware of a GPS solution that would use fiber?
> 

If you are allowed to have a fiber optic link but not a copper link you 
could run NTP over the fiber link!  I'm not aware of any refclock that 
uses a fiber optic output but if you can put a fiber optic Ethernet NIC 
in a PC outside and a PC inside and connect the two. . . .  If the 
inside machine runs a firewall that only allows the NTP protocol to and 
from port 123 only. . . .  Fiber optic NIC's are rare and expensive but 
there are, or were, such things.

Richard B. Gilbert wrote:

Fiber optic NIC's are rare and expensive but
> there are, or were, such things.

You may search for:

1. Allied Telesyn AT-2701FX/ST or AT-2701FX/SC
2. Allied Telesyn AT-2930SX 1000BaseSX-SC, PCI, ACPI

The price is around 150 USD.

Eugen COCA wrote:

> Richard B. Gilbert wrote:
> 
> Fiber optic NIC's are rare and expensive but
> 
>>there are, or were, such things.
> 
> 
> You may search for:
> 
> 1. Allied Telesyn AT-2701FX/ST or AT-2701FX/SC
> 2. Allied Telesyn AT-2930SX 1000BaseSX-SC, PCI, ACPI
> 
> The price is around 150 USD.
> 

No thanks.  I could buy the fiber NICs but I'm afraid that the 
hub/switch would bankrupt me!!  I've seen fiber used for gigabit links 
between 10/100 switches but that's about all.

Richard B. Gilbert wrote:

> No thanks.  I could buy the fiber NICs but I'm afraid that the
> hub/switch would bankrupt me!!  I've seen fiber used for gigabit links
> between 10/100 switches but that's about all.

You may use a direct link between 2 NICs on fiber optic, without
switches. The price of the link is around 250 USD.

And, after all, you may use Ethernet to fiber converters (around 75USD
a piece) and ordinary Ethernet cards. And you'll have the same result.
We have several links like this ...

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
news:ioOdnSafmsPzzXvZnZ2dnUVZ_tSdnZ2d@comcast.com...
>>[snipped for HER pleasure]
>
> If you are not allowed ANY external reference, I suppose it's the best
> you can do.  Your cell phone has time that is correct to within a few
> microseconds.  Of course it probably only displays hours and minutes but
> the rollover of the minute should be within microseconds.   From that
> you can probably set your watch within a second or so if you have good
> reflexes.
>
Assuming, of course, that he's on a CDMA network.  GSM networks don't care
what a particular second of time is labeled, so long as it's sliced
correctly.  Around these parts, Cingular time is 16 seconds slow.


Brian Garrett

Alexandre Carrausse wrote:
> "Hal Murray" <hmurray@suespammers.org> wrote in message
[]
>> adjtimex is the utility to tweak the clock frequency.
>
> Seems interesting in the long run.
> The only data I have found looks like code to be compiled for Unix.
> Anything ready for Windows?

Not "ready", as far as I know, but in principle it can be done as Windows 
allows you to set the number of timer ticks required between each timer 
interrupt to, IIRC, a precision of about 1 part in 150,000 (about a second 
a day).  So to catch up just set that value to about 100 less than it is 
now, and catch up in a small number of days, smoothly, without any steps. 
[Please check my sums!]

See:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getsystemtimeadjustment.asp

  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/setsystemtimeadjustment.asp

A "two line" program should do the job....you may even be able to do it 
from the command-line with VB Script.

Cheers,
David 

"Alexandre Carrausse" <alex_s_p_a_m@carrausse.com> writes:
> Are you aware of a GPS solution that would use fiber?

Not out of the box, but there are fiber converters for rs-232 and ttl
levels.  They are low volume items and the price seems to be all over
the place.

       http://www.telebytedatacom.com/catalog/products/9271.htm

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

See www.meinberg.de (http://www.meinberg.de/english/products/goal.htm) 
- they can put a fiber link between the antenna unit and the actual receiver.

Frank

In article <v9ydnV8UkcY2yHvZnZ2dnUVZ_qqdnZ2d@comcast.com>,
Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Alexandre Carrausse wrote:

> > I agree but the link between the GPS antenna and the secure area will be 
> >  coper, not fiber.

No.  The copper would terminate on the GPS receiver, which would be outside
the secure area.  The fibre would carry the baseband NMEA signal.
 
> If you are allowed to have a fiber optic link but not a copper link you 
> could run NTP over the fiber link!  I'm not aware of any refclock that 

There are two likely reasons for restricting to fibre: one is EMP 
protection, the other is security.  If security is the case, and
you operate a bidirectional protocol like NTP, the electronics at the
remote end of the link would almost certainly also be considered 
part of the secure area and subject to the same restrictions as the 
main area, unless the data was encrypted and they were not the final
end point of the transmission.  (Google "covert channels" for more.)

He might be allowed to operate a link that was uni-directional, which
would allow him to have the complete receiver in an insecure area,
and transmit the data optically (phototdiodes aren't very good light
sources, so there is little risk of information leaking the other way).

I don't believe that ntpd needs to be able to talk to NMEA time sources,
although it may try to configure them.

In article <44e63895$0$32471$626a54ce@news.free.fr>,
Alexandre Carrausse <alex_s_p_a_m@carrausse.com> wrote:
> "Hal Murray" <hmurray@suespammers.org> wrote in message 
> news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d@megapath.net...
> > 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

Definitely.  Peering was never intended to be use for unsychronised
networks.  It was not designed for creating a consensus time out of
nothing.  For a start, local clocks are normally clocks of last
resort, so you would have to prefer them, but even then, the whole
system would almost certainly wander in frequency and could end up
with some machines exceeding the 500ppm maximum correctable frequency
offset.

> > by hand when it drifts too far off.

> That's my plan. Today my system is 9 minutes below the real time. I can't 
> add 9 minutes in one go otherwise everything would crash. But I could add 
> one minute every morning during nine days and it would be fine.

The smoothest way of doing this is to stop the master server's ntpd
temporarily, load a large number in the correct sense into its ntp.drift
and restart it.  When it intersects true time, repeat the process,
but put the measured static frequency error into ntp.drift.

The large number should be less than 500.0 and it should also be less than
500 minus the largest value in ntp.drift, of the same sign, for any of
the other clients.  This ensures that no machine will need to exceed a
500ppm correction to retain lock.  I'd suggest using 450, rather than 500.
If you can get away with less, it will be even better.

Assuming that the NT port supports remote configuration, I would suggest
enabling that when you first stop the master server.  You can then fudge
the correction, to trim the frequency, without having to stop the server
again.

> > adjtimex is the utility to tweak the clock frequency.

> Seems interesting in the long run.
> The only data I have found looks like code to be compiled for Unix. Anything 
> ready for Windows?

You can achieve the same by setting ntp.drift manually and restarting,
or by fudging the local clock frequency, remotely.

"Alexandre Carrausse" <alex_s_p_a_m@carrausse.com> wrote in message
news:44e62aba$0$32476$626a54ce@news.free.fr...
[...]
> 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?

Probably not. Peering does not in any way average the time from
several servers. It just creates an association that may work
either way (but not both).

It's useful when both servers have (disjoint) references, and
may independently lose their connection with those. Then either
server can fall back on the other. If both servers have the
same sources, you gain nothing.

If you have only one source, just build a simple tree. Doing better
requires rather careful fault scenario analysis.

Groetjes,
Maarten Wiltink

"Maarten Wiltink" <maarten@kittensandcats.net> wrote in message
news:44e6f442$0$4527$e4fe514c@news.xs4all.nl...
[...]
> <Peering>'s useful when both servers have (disjoint) references, and
> may independently lose their connection with those. Then either
> server can fall back on the other. If both servers have the
> same sources, you gain nothing.

Sorry. If both servers have the same _connection_, you gain nothing.

Groetjes,
Maarten Wiltink

in article <44e634ea$0$32462$626a54ce@news.free.fr>,
Alexandre Carrausse <alex_s_p_a_m@carrausse.com> wrote:

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

33k is quite possible.  In fact slow links can be more reliable, because, if
they overload, the round trip time goes so high that ntpd ignores the
updates until the overload goes away.

The main problem happens on systems with medium fast connections and consumer
type traffic profiles (i.e. most traffic is extracting information from the
web, and it tends to peak drastically at lunch times).  It will also depend
on how heavily utilised your link is.

In your case, I might be more worried that the encryption may be introducing
delays and uncertainties.

You can tell if you have a problem by monitoring the delay value in the 
peers subcommand of ntpq.  The best solution is to configure the routers
to give priority to NTP traffic.  This is an option that you probably have
but people dependant on an ISP generally don't have.

> 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 

As others have said, this is really a social engineering problem.

However, the master server will continue to provide time, because
the effect of using the local clock is that their time always seems
to be perfectly correct.  It is the clients that will commit suicide.
If you are lucky, NT will still retain the last frequency correction,
and you should have an error which could be as low as 30 seconds a year.
(This is what happens on modern Unix-like systems, with kernel support
for NTP and I think that the NT time adjustment mechanism would require
ntpd to explicitly cancel its adjustment for that not to happen.)

> machine on the network will start to drift appart?... until someone realise 
> that the NTPDaemon is not started.

Given that you say that the application will crash if there is an error
of more than 3 minutes, it seems to me that it won't take long for them
to discover that one of the machines (the master) is out by more than
20 minutes.  More generally, if you cannot realise and correct this
quickly, I think you ought to look into that, rather than whether or not
the remote systems will start to free run and may fail a some time in the
future .  Similarly, if the operators are allowed to make such a mistake
and correct it, without logging the fact, you have a discipline problem.

Eugen COCA wrote:

> Richard B. Gilbert wrote:
> 
> 
>>No thanks.  I could buy the fiber NICs but I'm afraid that the
>>hub/switch would bankrupt me!!  I've seen fiber used for gigabit links
>>between 10/100 switches but that's about all.
> 
> 
> You may use a direct link between 2 NICs on fiber optic, without
> switches. The price of the link is around 250 USD.
> 
> And, after all, you may use Ethernet to fiber converters (around 75USD
> a piece) and ordinary Ethernet cards. And you'll have the same result.
> We have several links like this ...
> 

I had my home wired (cat-5e) a few years ago.  I don't see any advantage 
  in going to fiber at this time; certainly not enough to justify the 
expense.

It's very easy to monitor your machines if they all peer with each other.

H

Alexandre Carrausse wrote:
> 
> The load is stable on the main server as it is only providing the active 
> directory. Not very busy (not like a db backup).
> 

Okay, just remember that Active Directory uses Kerberos so the clients
need to be within 5 minutes of the Active Directory Controller to work
properly, which you are apparently doing with your setup.

>> adjtimex is the utility to tweak the clock frequency.
> 
> Seems interesting in the long run.
> The only data I have found looks like code to be compiled for Unix. Anything 
> ready for Windows?
> 

No, we've never had an occasion to build it. I don't think it's
necessary if you are running ntpd and just synching to the master.

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

Alexandre Carrausse wrote:
> 
> 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.
> 

Meinberg also has a pretty good tool for monitoring and can look at
multiple systems.

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

It should. NTP was originally designed in the days when networks were
not only unreliable but also over slow, by today's standards, networks.
You also have a closed environment so the worst you will likely get is a
switch outage or similar.

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

Yes, DCE needs time accuracy, but only relative to the other nodes so I
don't think that's a real concern.

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

If someone does that on the main server then the leaf nodes are likely
to decide that it's crazy and not take time from it. Be warned however
that if it's really acting as a domain controller, those nodes will be
unable to verify things like passwords. As usual a domain controller
needs to be secured against unauthorized access and in a secure
environment like yours should be standard procedure.

Because of your environment I wouldn't bother with all of these schemes
to synchronize one system to the outside world. Just go with the scheme
you already have in place, though do consider upgrading your ntpd
software if you can.

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

David Woolley wrote:
> In article <44e63895$0$32471$626a54ce@news.free.fr>,
> Alexandre Carrausse <alex_s_p_a_m@carrausse.com> wrote:
>> "Hal Murray" <hmurray@suespammers.org> wrote in message 
>> news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d@megapath.net...
>>> 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
> 
> Definitely.  Peering was never intended to be use for unsychronised
> networks.  It was not designed for creating a consensus time out of
> nothing.  For a start, local clocks are normally clocks of last
> resort, so you would have to prefer them, but even then, the whole
> system would almost certainly wander in frequency and could end up
> with some machines exceeding the 500ppm maximum correctable frequency
> offset.
> 

Dave's new schemes allow this to work very well. It requires manycasting
but it also needs the newer code.

> Assuming that the NT port supports remote configuration, I would suggest
> enabling that when you first stop the master server.  You can then fudge
> the correction, to trim the frequency, without having to stop the server
> again.
> 

I does in the same way as Unix versions but that's going away in the future.

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

>>> adjtimex is the utility to tweak the clock frequency.
>> 
>> Seems interesting in the long run.
>> The only data I have found looks like code to be compiled for Unix. Anything 
>> ready for Windows?
>> 
>
>No, we've never had an occasion to build it. I don't think it's
>necessary if you are running ntpd and just synching to the master.

The idea was to tweak the local clock parameters so that it didn't drift much.

You can do that by editing the drift file and restarting ntpd.

I think my suggestion of adjtimex was probably a wild goose chase.

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

Hi Alex,


Alexandre Carrausse schrieb:
> "Wolfgang S. Rupprecht" 
> <wolfgang+gnus20060818T141853@dailyplanet.dontspam.wsrcc.com> wrote in 
> message news:87mza1zqnv.fsf@bonnet.wsrcc.com...
>> 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.
> 
> I agree but the link between the GPS antenna and the secure area will be 
> coper, not fiber.
> 
> Are you aware of a GPS solution that would use fiber?

Just take a look at this:
http://www.meinberg.de/english/products/goal.htm

You can use it with out LANTIME/GPS time servers for example. Or hook up 
one of our GPS receivers and connect that to one of your servers. 
Another possibility would be to use a Meinberg PCI card in your master 
server.

The GOAL system can be combined with any Meinberg GPS receiver, examples 
are:
http://www.meinberg.de/english/products/lantime.htm
http://www.meinberg.de/english/products/gps167.htm
http://www.meinberg.de/english/products/gps170pci.htm

Best regards,
Heiko


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


-- 
Meinberg radio clocks: 25 years of accurate time worldwide

MEINBERG Radio Clocks
www.meinberg.de

Stand alone ntp time servers and radio clocks based on GPS, DCF77 and 
IRIG. Rackmount and desktop versions and PCI slot cards.