NTP to sync clocks on an Isolated Local Network (UTC not relevant) - NTP

This is a discussion on NTP to sync clocks on an Isolated Local Network (UTC not relevant) - NTP ; Hello, I would like people to comment on my proposed NTP set-up. Are the ntp.conf files correct? My requirement is to synchronise several linux (ubuntu) boxes that are connected together but not to the wider internet. I am ONLY interested ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

  1. NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    Hello,

    I would like people to comment on my proposed NTP set-up. Are the
    ntp.conf files correct?

    My requirement is to synchronise several linux (ubuntu) boxes that are
    connected together but not to the wider internet. I am ONLY interested
    in synchronisation and NOT the accuracy of the network time relative to
    UTC.

    Assuming all the linux boxes are identical, I just pick one box's Local
    clock to be the master clock.

    I use NTP in the Undisciplined Local Clock mode with the chosen linux
    box acting as a server broadcasting it's Local clock's time. The other
    boxes act as clients in broadcastclient mode.

    My server ntp.conf will NOT mention a driftfile as it would be
    irrelevant (?).
    Is the client's ntp.conf line - "disable auth" necessary?
    Any errors/omissions?

    server's ntp.conf file :-
    ***************************
    server 127.127.1.0 prefer # use the local system clock as the
    reference clock
    fudge 127.127.1.0 stratum 10 # 10 seems to be a standard choice for
    this but I think it is
    # irrelevant on an
    isolated network (?)
    broadcast 192.168.123.255 # broadcast time to local subnet


    clients' ntp.conf files :-
    **************************
    disable auth # is this correct ?
    broadcastclient


  2. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)


    > Assuming all the linux boxes are identical, I just pick one box's Local
    > clock to be the master clock.


    The superior strategy would be to configure the local clocks on all
    machines and let ntp figure it all out by itself. That's what it was
    made for.

    This will give you so much better stability and it also eliminates the
    dependency on a single machine.

    N

  3. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    Nero,

    Thanks for the prompt reply.

    My application will be safety critical so if any microprocessor fails
    then the whole system has to move to a safe state/reset/shut down.
    Therefore I can't see any advantage in using more than one clock as the
    reference clock. I don't mind depending on a single machine!

    Would the synchronisation be improved? Remember I'm not worried about
    the "stability".

    Assuming I did follow your advice, how is that achieved? Do I need
    peer commands or something?

    Do my conf files look OK if I wanted to stay with my original set-up?


  4. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    duncan.perrett@elekta.com wrote:
    > Nero,
    >
    > Thanks for the prompt reply.
    >
    > My application will be safety critical so if any microprocessor fails
    > then the whole system has to move to a safe state/reset/shut down.
    > Therefore I can't see any advantage in using more than one clock as the
    > reference clock. I don't mind depending on a single machine!
    >
    > Would the synchronisation be improved? Remember I'm not worried about
    > the "stability".
    >
    > Assuming I did follow your advice, how is that achieved? Do I need
    > peer commands or something?
    >
    > Do my conf files look OK if I wanted to stay with my original set-up?
    >


    Given that there is no good setup for NTP in the absence of any
    precision clocks, your original proposal is about the best you
    can do. Configuring all systems to use their local clocks is
    precisely the wrong thing to do. They will form little cliques
    among themselves, each with a different time. If any redundancy
    were required, configure at most 3 such servers with strata
    incrementing by 2 (e.g., 8, 10, 12) and configure the rest as
    simple clients. I would configure drift files everywhere except
    on the single server in your originally proposed broadcast
    configuration.

    Note also that many, if not most, users who claim to be concerned
    only about having the same time and not about having the correct
    time on a group of systems are shocked to learn a few weeks later
    that their clocks are running fast or slow and have drifted by
    several minutes or several hours off "real" time. Clocks running at
    the wrong speed is a direct, and possibly more important, consequence
    of not having a precision clock anywhere.

    -Tom

  5. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    I'm glad someone (mostly) agrees with me! I'll remember that the clock
    can drift significantly over long periods (weeks/months).
    So I just need to add a drift file line to my client ntp.conf files?
    Do I need to actually physically delete any drift files in the unix
    filesystem?


  6. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    Tom Smith wrote:
    > duncan.perrett@elekta.com wrote:
    >
    > can do. Configuring all systems to use their local clocks is
    > precisely the wrong thing to do. They will form little cliques
    > among themselves, each with a different time.


    Arrrrr... right.
    I stand corrected.

    N

  7. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    In article <1157113808.669366.222710@74g2000cwt.googlegroups.c om>,
    duncan.perrett@elekta.com writes:
    >My application will be safety critical so if any microprocessor fails
    >then the whole system has to move to a safe state/reset/shut down.
    >Therefore I can't see any advantage in using more than one clock as the
    >reference clock. I don't mind depending on a single machine!


    Esp. for a safety system, aren't you worried about correlating events
    logged to real time? Why can't you use a GPS? Then you have accurate
    time without an internet connection.

    --
    Chris Richmond | I don't speak for Intel & vise versa


  8. Re: NTP to sync clocks on an Isolated Local Network (UTC not relevant)

    >>> In article <1157112288.931694.6980@i3g2000cwc.googlegroups.com>, duncan.perrett@elekta.com writes:

    duncan> are connected together but not to the wider internet. I am ONLY
    duncan> interested in synchronisation and NOT the accuracy of the network
    duncan> time relative to UTC.

    You may soon discover that this assumption is wrong.

    duncan> Assuming all the linux boxes are identical, I just pick one box's
    duncan> Local clock to be the master clock.

    Be sure to pick the right box. ntpd can handle 500ppm of "difference", and
    if the machine you pick is 300ppm slow and your other machines are 300ppm
    fast, ntpd will not be able to handle it.

    You will also need to be Careful that you are not losing clock interrupts.

    Please see http://ntp.isc.org/bin/view/Support/TroubleshootingNTP, at least
    the first two entrise (known HW and OS issues).

    duncan> I use NTP in the Undisciplined Local Clock mode with the chosen
    duncan> linux box acting as a server broadcasting its Local clock's time.
    duncan> The other boxes act as clients in broadcastclient mode.

    I recommend a chain of servers at least 3 deep, increasing the stratum of
    each server by 2. Let all of your machines peer with each other.

    duncan> My server ntp.conf will NOT mention a driftfile as it would be
    duncan> irrelevant (?).

    Possibly not a good idea - the driftfile is what lets machines sync up
    faster after a restart.

    duncan> Is the client's ntp.conf line - "disable auth"
    duncan> necessary? Any errors/omissions?

    duncan> server's ntp.conf file :- *************************** server
    duncan> 127.127.1.0 prefer # use the local system clock as the reference

    I'm not certain that 'prefer' is the way to go here. The driver1.html page
    has more information on this.

    If your "primary master" is at a good enough stratum, it will be picked and
    followed without the 'prefer' keyword.

    duncan> clock fudge 127.127.1.0 stratum 10 # 10 seems to be a standard
    duncan> choice for this but I think it is # irrelevant on an isolated
    duncan> network (?)

    If you are going to go with 3 masters, you may want to use 9, 11, and 13 as
    the stratum numbers. Using 10, 12, and 14 may caue trouble if the first 2
    fail, as you would find all of your other machines at s15 with nowhere to go
    below that.

    duncan> broadcast 192.168.123.255 # broadcast time to local
    duncan> subnet

    I recommend you use peer lines to your machines, not broadcast.

    duncan> clients' ntp.conf files :- ************************** disable auth #
    duncan> is this correct ? broadcastclient

    See the previous comment.

    H

+ Reply to Thread