NTP sync on a standalone network (Windows 2k) - NTP

This is a discussion on NTP sync on a standalone network (Windows 2k) - NTP ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 44

Thread: NTP sync on a standalone network (Windows 2k)

  1. NTP sync on a standalone network (Windows 2k)

    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



  2. Re: NTP sync on a standalone network (Windows 2k)

    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.

  3. Re: NTP sync on a standalone network (Windows 2k)

    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


  4. Re: NTP sync on a standalone network (Windows 2k)

    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.


  5. Re: NTP sync on a standalone network (Windows 2k)

    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.




  6. Re: NTP sync on a standalone network (Windows 2k)

    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.


  7. Re: NTP sync on a standalone network (Windows 2k)

    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
    >




  8. Re: NTP sync on a standalone network (Windows 2k)

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




  9. Re: NTP sync on a standalone network (Windows 2k)

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




  10. Re: NTP sync on a standalone network (Windows 2k)

    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.

  11. Re: NTP sync on a standalone network (Windows 2k)

    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


  12. Re: NTP sync on a standalone network (Windows 2k)

    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.


  13. Re: NTP sync on a standalone network (Windows 2k)


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


  14. Re: NTP sync on a standalone network (Windows 2k)

    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



  15. Re: NTP sync on a standalone network (Windows 2k)

    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


  16. Re: NTP sync on a standalone network (Windows 2k)

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

  17. Re: NTP sync on a standalone network (Windows 2k)

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


  18. Re: NTP sync on a standalone network (Windows 2k)


    "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









  19. Re: NTP sync on a standalone network (Windows 2k)


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

  20. Re: NTP sync on a standalone network (Windows 2k)


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





+ Reply to Thread
Page 1 of 3 1 2 3 LastLast