Re: "good enough" ntp configuration - NTP

This is a discussion on Re: "good enough" ntp configuration - NTP ; Mark, What are these "Campus Systems" currently running for their OS and time synchronization, and how many machines are we talking about? If we are talking about single or double digit *nix machines, then of course you would want to ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: "good enough" ntp configuration

  1. Re: "good enough" ntp configuration

    Mark,

    What are these "Campus Systems" currently running for their OS and time
    synchronization, and how many machines are we talking about?

    If we are talking about single or double digit *nix machines, then of course
    you would want to go with NTP for their time sync. But if you are talking
    about thousands of Windows machines, then it might be easier just to use the
    built-in windows time sync but have it point to your local source and sync
    more often than the default settings. It all boils down to how accurate you
    want the time to be vs how much work you want to do.

    As others have pointed out, if you want to do the proper NTP hierarchy &
    failover, it would be good practice to have a couple servers act as
    stratum-2 machines and sync via internet to some other stratum-1 sources,
    then use the combination of those 4 machines for your NTP clients.

    Also when using NTP to set the prefer flag to your GPS source as that would
    probably be the most accurate time and prevent NTP from hopping around
    sources or choosing the wrong one.

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


  2. Re: "good enough" ntp configuration

    On Sat, 9 Jun 2007 19:34:51 GMT, jason@extremeoverclocking.com (Jason Rabel) wrote
    for the entire planet to see:

    >Also when using NTP to set the prefer flag to your GPS source as that would
    >probably be the most accurate time and prevent NTP from hopping around
    >sources or choosing the wrong one.


    I can't agree with that statement. The PREFER keyword can improve sync and reduce
    clock-hopping, but it causes unfortunate side effects when the PREFERed clock has
    problems.

    It reduces reliability and redundancy in the entire NTP hierarchy that uses that
    server and can lead to all your machines becomming unsynchronized from the One True
    Time. PREFER should be avoided if you are interested in high availability rather
    than sub-millisecond accuracy.

    - Eric


+ Reply to Thread