Architecture / best practice for small/medium company setups - NTP

This is a discussion on Architecture / best practice for small/medium company setups - NTP ; Hello, I would like to pose a few questions on architecture / best practice on NTP setups for small and medium companies. I read the documentation and the Wiki, I also googled, but didn't find a satisfying answer. I'm willing ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Architecture / best practice for small/medium company setups

  1. Architecture / best practice for small/medium company setups

    Hello,

    I would like to pose a few questions on architecture / best practice
    on NTP setups for small and medium companies. I read the documentation
    and the Wiki, I also googled, but didn't find a satisfying answer. I'm
    willing to update the NTP Wiki with an HOW-TO text that results from
    this discussion.

    The situation:

    -- Let's assume a company with 10 to max. 100 computer systems.
    Forthermore, let's just talk about Unix systems, for now, and
    let's assume that at least five of them are available.

    -- There is only one site. All computers are on the same LAN.

    -- The company has only one Internet connection, with a typical SLA of
    97.5% availability over the year. (For example, that's the SLA of
    T-Com for their basic CompanyConnect product here in Germany.) The
    worst-case outage of 9 days can be ignored, but we have to cope
    for outages of several hours length.

    -- The company has no requirements for extremely accurate
    time-synchronization. They run the usual bunch of applications:
    Databases, ERP systems, Office systems, and other applications
    that access time with a granularity of one second.

    I think this is a context that is common to many installations. (Well,
    I have seen many such environments. :-) My personal experience is only
    in big installations with 1000s of systems and redundant Internet
    connections; but I have been asked about such situations a few times
    in the past. (The last inquiry was a few days ago, and triggered this
    posting.)

    The first few questions are about selection of time servers:
    How many, and what is their peer structure?

    -- I assume that the company should use the NTP server pool, as it's
    not a large company with 1000s of computers.

    -- How many timeservers on the LAN that are accessed by clients?
    Looking at the available documentation, I would recommend four
    servers. (This might mean that many of the Unix systems suddenly
    are timeservers.) Or would three be sufficient? One server is
    surely not sufficient, as an outage of that server would endager
    the whole time synchronization.

    I.e., is peering between three servers sufficient to handle outage
    of one server until the repair is done, or does one need four servers
    to do that properly.
    (An answer may depend on the connection of the timeservers to the
    pool, as asked in the next question.) The Wiki recommends four
    servers, but I have seen several places where three servers are
    deemed sufficient. What's best practice?

    -- Connection to the NTP pool:
    -- Either all company timeservers access the pool,
    -- or one of the timeserver accesses the pool, and the others
    synchronizes to it,
    -- or there is an additional timeserver that accesses the pool
    and the company timeserver synchronize to this special server.
    The clients don't use this special server.
    Since there is only one Internet connection, and since there are
    no separate network paths to the pool servers, I have to ask if
    it's still reasonable to have several timeservers synchronizing to
    the pool. OTOH, if there is only one pool-connected system, what
    to do in case of an outage of that system? (Probably promote one of
    the other servers to be the Internet-facing systems.)

    I have no idea about further advantages or disadvantages of these
    three design possibilities. I assume that this has to be answered
    in conjunction with my next question, on peering. (I bar firewall
    and DMZ considerations for the moment, that might recommend the
    third solution.)

    -- Peering: Which servers peer to each other?
    -- If all company timeservers access the pool, I think they are
    all peers.
    -- But if only one system accesses the pool, does this system
    also peers with the others who synchronize to it? That hasn't
    been clear from the documentation. On the Wiki, it says that
    one shold peer all timeservers; but also ones that are
    different in the stratum hierarchy?

    -- Internet connection outages: Just let them happen, or use
    undisciplined local clock on stratum 10 as backup on the
    timeservers?
    AFAIK, undisciplined local clocks can cause havroc when the time
    strays too far away from the reference time source. Googling that
    question got several potential answers, therefore: is it best
    practice to use 127.127.1.0 as a backup for the case that no outside
    source of synchronized time is available?

    Is there a design decision for the server setup that I missed?

    -- Client configuration: Specific servers, or multicast?
    Now we have a bunch of timeservers in the company. What is best
    practice: That clients are configured to use these servers
    specifically, or that multicast mode is used?
    Or should one try a manycast configuration?
    If one uses multicast or manycast, does this imply that one needs
    to establish key-based authentication between servers and clients?
    Such small companies usually have no PKI in place, so this might
    mean to distribute shared secret keys during setup, or?
    Or use Autokey, as explained in the Wiki?

    Sorry for the long post. I hope to get some answers, and maybe we can add those
    answers to http://ntp.isc.org/bin/view/Support/...YourNTPNetwork. (Or make
    a different page, with specific step-wise explanation for small/medium company
    setups.) I think that page is already very good, but would be further improved
    with such information.

    Best,
    Joachim

    --
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Joachim Schrod Email: jschrod@acm.org
    Roedermark, Germany

  2. Re: Architecture / best practice for small/medium company setups

    "Joachim Schrod" wrote in message
    news:4ghq23F1nbttsU1@individual.net...
    [...]
    > The situation:
    >
    > -- Let's assume a company with 10 to max. 100 computer systems. ...
    > -- There is only one site. All computers are on the same LAN.
    > -- The company has only one Internet connection, with a typical SLA
    > of 97.5% availability over the year. ...
    > -- The company has no requirements for extremely accurate
    > time-synchronization. ...

    [...]
    > The first few questions are about selection of time servers:
    > How many, and what is their peer structure?


    Two. One on the Internet gateway ('primary'), and one backup ('backup').

    Primary has the external servers, and its local clock configured at
    stratum 10. Backup has the primary as its sole server, and its local
    clock at stratum 12.

    All other computers are leaf nodes and have primary and backup as
    their servers.

    Backup should be far enough away from primary that they're unlikely to
    be out at the same time (meaning, for the same reason).

    People are going to scream bloody murder that there aren't four
    servers in this scenario. People are going to be ripping body parts
    over there being _two_ servers. In brute fact, there aren't - there's
    only one. Backup only serves to keep the herd together if primary
    fails altogether. That's the only time anybody will listen to it.

    Should there be four servers? Your choice. It may be overkill, and
    the next step down is one server. If it goes insane, well, tough.
    That's what you defend against with four servers. However, consider
    that with four servers, they should really _all_ have _all_ different
    external associations.


    > -- I assume that the company should use the NTP server pool, as it's
    > not a large company with 1000s of computers.


    Ideally, your ISP should provide four independent NTP servers for you
    to use. Mine _almost_ does - there are four NTP servers but they all
    have the same upstream servers. This only serves to reduce the load
    on those.

    [...]
    > -- Client configuration: Specific servers, or multicast?


    Good question. I almost missed it. Did you consider broadcast?

    Well-behaved unicast clients never send more than one packet per second.
    After stabilising, it becomes one in a thousand seconds. Not much of a
    problem. The configuration file is the same for all clients either
    way. Unicast and iburst might speed up initial convergence slightly.

    Groetjes,
    Maarten Wiltink



  3. Re: Architecture / best practice for small/medium company setups

    Maarten Wiltink wrote:

    > People are going to scream bloody murder that there aren't four
    > servers in this scenario. People are going to be ripping body parts
    > over there being _two_ servers.


    Interesting. My first reaction was as you predicted. Then after thinking
    about it, I started to warm to the idea. Then thinking some more, I
    started to dislike it again.


    > In brute fact, there aren't - there's
    > only one. Backup only serves to keep the herd together if primary
    > fails altogether. That's the only time anybody will listen to it.


    This isn't true. They will listen to it, all the time. And some will
    sync with it. Consider: The local clock settings are utterly irrelevant
    in the scenario proposed. The local clock will not be used until the
    dispersion of the regular servers becomes too large. This typically
    takes 24 hours. Since the scenario stipulated that the Internet
    servers would never be unavailable for more than a few hours, their
    dispersions will never grow large and the local refclock will never
    be used.

    So, in the normal case, we have two servers, which all of the leaf
    nodes have configured. These servers will be one stratum apart.
    So, by an large, all the leaf nodes will sync with the main server,
    as planned. However, fairly often, some will sync with the backup,
    due to transient errors, dropped packets, whatever.

    Now the backup will be generally in sync with the primary, since
    it is its only source of time. But just like a kite with only
    a single string, it will tend to flutter around the right time.
    Having only a single source of time eliminates many of the
    algorithms NTP uses to filter out transient errors.

    So, much of the time the backup will have a different time setting
    than the primary and much of the time some of the leaves will be
    in sync with the backup, so there will be clock hopping.

    So, I still think that at least three servers would be a good idea.
    I am thinking that if you pick three servers, and configure each
    of them with three independent Internet servers and have them peer
    with each other, that you will have a pretty robust system with
    a minimum of administrative overhead. This assumes that the choice
    of pool servers will be independent between them.

    I still like 4 servers minimum, though. Four seems to be the number
    that eliminates a whole class of problems. But three does pretty
    well, and might be good enough for your requirements.

    Also, it is a good idea to configure local refclocks as Martin
    described. I know that the scenario was for only a few hours, but there
    was that 9 day anomaly, wasn't there?

    --
    blu

    Roses are #FF0000, Violets are #0000FF. All my base are belong to you.
    ----------------------------------------------------------------------
    Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  4. Re: Architecture / best practice for small/medium company setups

    "Brian Utterback" wrote in message
    news:44A3D4DF.2050808@sun.removeme.com...
    > Maarten Wiltink wrote:


    [...]
    >> In brute fact, there aren't - there's
    >> only one. Backup only serves to keep the herd together if primary
    >> fails altogether. That's the only time anybody will listen to it.

    >
    > This isn't true. They will listen to it, all the time. And some will
    > sync with it.


    I meant sync to it, of course.


    [...]
    > So, by an large, all the leaf nodes will sync with the main server,
    > as planned. However, fairly often, some will sync with the backup,
    > due to transient errors, dropped packets, whatever.


    In my experience, they won't. (I have this configuration at home, with
    six leaf nodes. I'm not claiming proof, but it's a _lot_ of anecdotal
    evidence.)

    The backup is normally synced to the primary. So its stratum is one
    higher, its root dispersion is higher, it's less attractive in many
    respects. Perhaps the leaf nodes even recognise that one server is
    in the other's sync path and disqualify the latter for it.


    > [...] it is a good idea to configure local refclocks as Martin described.


    Who?

    Groetjes,
    Maarten Wiltink



  5. Re: Architecture / best practice for small/medium company setups

    Joachim Schrod wrote:

    > Hello,
    >
    > I would like to pose a few questions on architecture / best practice
    > on NTP setups for small and medium companies. I read the documentation
    > and the Wiki, I also googled, but didn't find a satisfying answer. I'm
    > willing to update the NTP Wiki with an HOW-TO text that results from
    > this discussion.
    >
    > The situation:
    >
    > -- Let's assume a company with 10 to max. 100 computer systems.
    > Forthermore, let's just talk about Unix systems, for now, and
    > let's assume that at least five of them are available.
    >
    > -- There is only one site. All computers are on the same LAN.
    >
    > -- The company has only one Internet connection, with a typical SLA of
    > 97.5% availability over the year. (For example, that's the SLA of
    > T-Com for their basic CompanyConnect product here in Germany.) The
    > worst-case outage of 9 days can be ignored, but we have to cope
    > for outages of several hours length.
    >
    > -- The company has no requirements for extremely accurate
    > time-synchronization. They run the usual bunch of applications:
    > Databases, ERP systems, Office systems, and other applications
    > that access time with a granularity of one second.
    >
    > I think this is a context that is common to many installations. (Well,
    > I have seen many such environments. :-) My personal experience is only
    > in big installations with 1000s of systems and redundant Internet
    > connections; but I have been asked about such situations a few times
    > in the past. (The last inquiry was a few days ago, and triggered this
    > posting.)
    >
    > The first few questions are about selection of time servers:
    > How many, and what is their peer structure?
    >
    > -- I assume that the company should use the NTP server pool, as it's
    > not a large company with 1000s of computers.


    You can use pool servers but I would not use them exclusively.

    >
    > -- How many timeservers on the LAN that are accessed by clients?
    > Looking at the available documentation, I would recommend four
    > servers. (This might mean that many of the Unix systems suddenly
    > are timeservers.) Or would three be sufficient? One server is
    > surely not sufficient, as an outage of that server would endager
    > the whole time synchronization.
    >
    > I.e., is peering between three servers sufficient to handle outage
    > of one server until the repair is done, or does one need four servers
    > to do that properly.
    > (An answer may depend on the connection of the timeservers to the
    > pool, as asked in the next question.) The Wiki recommends four
    > servers, but I have seen several places where three servers are
    > deemed sufficient. What's best practice?


    Ideally, each client should configure four servers.
    a. With a single server the client must follow it, right or wrong.
    b. Two servers is the worst possible configuration.
    c. Three servers degenerates too easily to the two server case.
    d. Four servers protect you from the failure of any one server.
    >
    > -- Connection to the NTP pool:
    > -- Either all company timeservers access the pool,
    > -- or one of the timeserver accesses the pool, and the others
    > synchronizes to it,
    > -- or there is an additional timeserver that accesses the pool
    > and the company timeserver synchronize to this special server.
    > The clients don't use this special server.
    > Since there is only one Internet connection, and since there are
    > no separate network paths to the pool servers, I have to ask if
    > it's still reasonable to have several timeservers synchronizing to
    > the pool. OTOH, if there is only one pool-connected system, what
    > to do in case of an outage of that system? (Probably promote one of
    > the other servers to be the Internet-facing systems.)
    >
    > I have no idea about further advantages or disadvantages of these
    > three design possibilities. I assume that this has to be answered
    > in conjunction with my next question, on peering. (I bar firewall
    > and DMZ considerations for the moment, that might recommend the
    > third solution.)
    >
    > -- Peering: Which servers peer to each other?
    > -- If all company timeservers access the pool, I think they are
    > all peers.


    Ideally, each server in a peer group should have at least one unique
    source of time! Thus four peering servers would need a total of seven
    upstream servers.


    > -- But if only one system accesses the pool, does this system
    > also peers with the others who synchronize to it? That hasn't
    > been clear from the documentation. On the Wiki, it says that
    > one shold peer all timeservers; but also ones that are
    > different in the stratum hierarchy?
    >
    > -- Internet connection outages: Just let them happen, or use
    > undisciplined local clock on stratum 10 as backup on the
    > timeservers?
    > AFAIK, undisciplined local clocks can cause havroc when the time
    > strays too far away from the reference time source. Googling that
    > question got several potential answers, therefore: is it best
    > practice to use 127.127.1.0 as a backup for the case that no outside
    > source of synchronized time is available?
    >
    > Is there a design decision for the server setup that I missed?
    >

    I'm not certain that you need multiple peering servers. For short
    outages a server can serve its local clock as "the clock of last
    resort". It will drift but should be usable for several hours. Can you
    tolerate an error of, say, 100 milliseconds? Everybody would be in
    synch but could differ from UTC by up to 100 milliseconds.

    It's possible to have a configuration that will survive anything but a
    direct hit with a nuclear weapon. Very few organizations need this
    level of reliability. I'd be inclined to start small and learn from
    experience.

    > -- Client configuration: Specific servers, or multicast?
    > Now we have a bunch of timeservers in the company. What is best
    > practice: That clients are configured to use these servers
    > specifically, or that multicast mode is used?
    > Or should one try a manycast configuration?
    > If one uses multicast or manycast, does this imply that one needs
    > to establish key-based authentication between servers and clients?
    > Such small companies usually have no PKI in place, so this might
    > mean to distribute shared secret keys during setup, or?
    > Or use Autokey, as explained in the Wiki?


    I believe that authentication is not an absolute requirement. All
    authentication does is to attempt to guarantee that the servers really
    are who they claim to be. If traceability to some standard is a
    requirement then you probably need it. If you see no need to guard
    against somebody pretending to be someone he's not, you can probably
    live without authentication.

    Broadcast or multicast will cut down on some of the network chatter.
    AFAIK that's the only advantage. The load on the server is not really
    significant; a server can handle a thousand clients without working too
    hard.

    >
    > Sorry for the long post. I hope to get some answers, and maybe we can
    > add those answers to
    > http://ntp.isc.org/bin/view/Support/...YourNTPNetwork. (Or make a
    > different page, with specific step-wise explanation for small/medium
    > company setups.) I think that page is already very good, but would be
    > further improved with such information.
    >
    > Best,
    > Joachim
    >


  6. Re: Architecture / best practice for small/medium company setups

    Brian Utterback wrote:
    >
    > So, I still think that at least three servers would be a good idea.
    > I am thinking that if you pick three servers, and configure each
    > of them with three independent Internet servers and have them peer
    > with each other, that you will have a pretty robust system with
    > a minimum of administrative overhead. This assumes that the choice
    > of pool servers will be independent between them.


    That's interesting. Lurking on this group I had always the impression that using
    stratum 1 servers for small companies is frowned upon. But now both your answer
    and the answer by Richard point into a different directions, namely to use them
    as well: If I have three different independent Internet servers for three
    internal servers, I need nine Internet servers. (In the case of four x four
    servers, I need 16 Internet servers.)

    The pool delivers only three servers per region (with multiple IP numbers, but
    that is for load balancing, as far as I understand). That means that one either
    has to use another national pool which is often not as near net-wise. Or one
    selects 6 or 13 other Internet servers. When I look at the public stratum 2
    servers at http://ntp.isc.org/bin/view/Servers/...TwoTimeServers, I'm hard
    pressed to find 6 or 13 servers in Germany or nearby Europe. That means I have
    to resort to stratum 1 servers.

    Is this really the recommendation that I should formulate for the NTP Support
    Wiki? That's why I asked how many company servers should sync to Internet servers.

    > Also, it is a good idea to configure local refclocks as Martin
    > described. I know that the scenario was for only a few hours, but there
    > was that 9 day anomaly, wasn't there?


    Yes, the rationale goes as this: 97.5% SLA over the year means a maximum outage
    of 9.something days. But usually Internet outages are below one day, just a few
    hours. Outages that are really longer most often happen during very hard weather
    storms, or similar conditions. Therefore I regard them as major outages and
    think they should not be handled by normal operational precautions, but by
    disaster recovery. Typically, one has much more problems in case of a major
    outage than an unsynchronized timeserver. (Email comes to mind, that is
    mission-critical, even for small to medium companies.)

    Best,
    Joachim

    --
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Joachim Schrod Email: jschrod@acm.org
    Roedermark, Germany

  7. Re: Architecture / best practice for small/medium company setups

    Joachim Schrod wrote:

    > Brian Utterback wrote:
    >
    >>
    >> So, I still think that at least three servers would be a good idea.
    >> I am thinking that if you pick three servers, and configure each
    >> of them with three independent Internet servers and have them peer
    >> with each other, that you will have a pretty robust system with
    >> a minimum of administrative overhead. This assumes that the choice
    >> of pool servers will be independent between them.

    >
    >
    > That's interesting. Lurking on this group I had always the impression
    > that using stratum 1 servers for small companies is frowned upon. But
    > now both your answer and the answer by Richard point into a different
    > directions, namely to use them as well: If I have three different
    > independent Internet servers for three internal servers, I need nine
    > Internet servers. (In the case of four x four servers, I need 16
    > Internet servers.)


    Not quite so! If you are serving time to 100 clients, you can justify
    using a stratum 1 server. There are, however, too many people using
    stratum 1 servers with no justification whatever except that they can!
    Nobody can stop you from using the NIST servers but you can probably do
    better elsewhere unless you happen to be right next door to one.

    Pick some nearby servers from the stratum two list and try them out.
    Keep testing stratum two servers until you find some that work well for
    you. You should look for low values of delay and jitter or dispersion.

    If you want a stratum one server you can be one for a mere $200 US and
    some effort on your part. I operate two stratum one servers in my home;
    one synchronizes to a GPS receiver and the other to a WWV receiver. The
    GPS works much better but both are technically stratum 1. All you need
    is a GPS receiver and the ability to locate an antenna where it will
    have an unobstructed view of the sky. My GPS synchronized server
    maintains an accuracy of about +/- 2 microseconds. YMMV.

    >
    > The pool delivers only three servers per region (with multiple IP
    > numbers, but that is for load balancing, as far as I understand). That
    > means that one either has to use another national pool which is often
    > not as near net-wise. Or one selects 6 or 13 other Internet servers.
    > When I look at the public stratum 2 servers at
    > http://ntp.isc.org/bin/view/Servers/...TwoTimeServers, I'm hard
    > pressed to find 6 or 13 servers in Germany or nearby Europe. That means
    > I have to resort to stratum 1 servers.


    If you want to use four peered servers you need a minimum of seven
    upstream servers to do it right; one unique server for each of your
    servers and three others to be shared by all. Do you REALLY need four
    peered servers? How about two servers, one with a GPS refclock and one
    with a DCF77 refclock? Peer the two with each other.

    >
    > Is this really the recommendation that I should formulate for the NTP
    > Support Wiki? That's why I asked how many company servers should sync to
    > Internet servers.
    >


    When you get a configuration that works for you, then you can consider
    writing an article for the Wiki. If you have done something really
    unique and clever you should definitely write about it.



  8. Re: Architecture / best practice for small/medium company setups

    Maarten Wiltink wrote:
    > "Brian Utterback" wrote in message
    >> [...] it is a good idea to configure local refclocks as Martin described.

    >
    > Who?
    >
    > Groetjes,
    > Maarten Wiltink
    >
    >


    Sorry. That's what the voice in my head said. If it had written it
    down, I might have done better 8-)


    --
    blu

    Roses are #FF0000, Violets are #0000FF. All my base are belong to you.
    ----------------------------------------------------------------------
    Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  9. Re: Architecture / best practice for small/medium company setups

    Maarten Wiltink wrote:
    > "Brian Utterback" wrote in message
    > news:44A3D4DF.2050808@sun.removeme.com...
    >> Maarten Wiltink wrote:


    >> So, by an large, all the leaf nodes will sync with the main server,
    >> as planned. However, fairly often, some will sync with the backup,
    >> due to transient errors, dropped packets, whatever.

    >
    > In my experience, they won't. (I have this configuration at home, with
    > six leaf nodes. I'm not claiming proof, but it's a _lot_ of anecdotal
    > evidence.)


    I contend that that is smallest amount of anecdotal evidence you
    can have. You are going by the behavior in a single environment.
    My experience is both the same and opposite of yours. Yes, in
    most cases, the leaf nodes will sync with primary server. However,
    my experience is also that NTP will sync to the other server, and
    unless you look with a microscope, you can't tell why.

    Everyday I deal with customers that have NTP setups that they think
    should work, that you would guess should work, but something weird is
    going on and the wrong server is used, or there is a large offset,
    or the clock steps, or whatever.

    I tell them to configure by the four server rule, and the problem
    goes away. Almost always. I never get calls from customers that
    have already used the four server rule. Granted, that is
    anecdotal as well.

    --
    blu

    Roses are #FF0000, Violets are #0000FF. All my base are belong to you.
    ----------------------------------------------------------------------
    Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
    Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

  10. Re: Architecture / best practice for small/medium company setups

    Here's what I like.

    Find your 2 or 3 best timekeepers.

    Make your best one the "master" for your network. You have 2 choices to
    make:

    - assign its local refclock stratum to 2 "worse" than the worst you ever
    expect to see from the servers it listens to
    - tell it to never advertise itself as better than S8 (assuming you have
    its local refclock at S10)

    Take your 2nd best server and have it sync to your master and whatever other
    machines you like, and assign its local refclock to a stratum 2 worse than
    your master.

    If you have a 3rd best server, assign its local refclock a stratum 2 worse
    than your #2 server.

    The reason for this is that if there is an upstream problem your primary
    server will drop 1 lower and then everybody will sync to this one box.

    If this box has problems, there will be a bit of a dance and everybody will
    sync to the #2 box.

    If you use S10 for the 1st box and S12 for your 2nd box, you will be as s14
    for your 3rd box, which means your 3rd box will advertise itself at S15 and
    you are already a bottom-feeder at that point. This also means that if you
    are ordinarily listening to S1 or S2 servers that there is a Long Dance as
    folks "wind down" the stratum chain to your S10 and that gives plenty of
    opportunity for "cliques" to form, and it can get ugly as the cliques start
    to disagree on the time.

    By using this "worse by 2" you minimize/avoid these cliques.

    I like to have all my ntpd's sync with one another, mostly because 'ntpq -p'
    will show me any problems.

    Unless you are very sure of how an S1 is set up, I recommend syncing to S2
    boxes only as they are generally much better about talking to multiple S1/S2
    boxes and exhibit much better behavior when things "go wrong".

    H

  11. Re: Architecture / best practice for small/medium company setups

    Brian Utterback wrote:
    > This isn't true. They will listen to it, all the time. And some will
    > sync with it. Consider: The local clock settings are utterly irrelevant
    > in the scenario proposed. The local clock will not be used until the
    > dispersion of the regular servers becomes too large. This typically
    > takes 24 hours.


    I don't understand where the 24 hours comes from. Even with excellent
    sync and a server that has backed off to a 1024 second poll interval, it
    takes about half an hour for my machine to deselect my internet servers
    and either become unavailable to other clients or fall back to local
    when the link is down.

    Admittedly, allowing all the other ntp clients to simply free run for a
    few hours would probably just fine on that timescale so a local clock
    might not be necessary. But it should be the selected time source much
    sooner than 24 hours.

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  12. Re: Architecture / best practice for small/medium company setups

    "Joachim Schrod" wrote in message
    news:4gk9roF1o6flsU1@individual.net...

    > [...] How many timeservers does one need in an environment as I have
    > described it? [...] there is *no* demand for high precision, ...


    I'd say one, then.

    If timekeeping is not overtly critical, you can do fine with a single
    server. Occasional loss of Internet connectivity is handled by the
    primary itself, the backup in my scheme protects (only) from client
    divergence after total failure of the primary. Not all that interesting,
    really, except as a way to freak people out who know only that having
    two servers is bad.

    Having four servers offers improved fault tolerance mostly against
    faults in the external references, of which you need a significant
    number to actually achieve that tolerance.

    Setting up your own refclocks is great if toys are your thing. You
    can undoubtedly sell them to management, but personally I like tall
    trees. I'm very comfortable at stratum 4.


    [...]
    > The connection between these two cases is still unclear to me. If I
    > have own primary servers with refclocks (case 1); should I still set
    > up internal timeservers (case 2)?


    Yes. If you care enough to have your own refclocks, you should have
    a fully-peered layer below them for the clients to see, with ISP and
    pool fallback associations.

    In my opinion (but other people are bound to have their own), refclocks
    don't take the place of the primary server layer. They augment your
    external references. If nothing else, this way of thinking lets you swap
    out in-house refclocks without affecting all the leaf nodes, since they
    only see the interface server layer.

    Another scenario for refclocks is if you need very good time in a few
    hosts. You can then distribute a (single) PPS signal to them.

    You keep mentioning the number of hosts in your questions. That's really
    not that relevant. Much more interesting are the fault tolerance and
    accuracy you require, and how you want certain failure modes dealt with.
    Failure modes I'm aware of include loss of Internet connectivity, Internet
    connection overload, failure of a single master, internal refclock
    insanity (1-N), and external reference insanity (1-N).

    Groetjes,
    Maarten Wiltink



  13. Re: Architecture / best practice for small/medium company setups

    In article ,
    Richard B. Gilbert wrote:

    > server. If that single server fails, the client's clocks will start to
    > drift, perhaps by as much as four seconds per day but probably less than
    > that. In twenty-four hours, two different systems might differ by as
    > much as eight seconds but again, probably less than that. If he can


    Things would have to have been very bad before the server failed for this
    to happen, and the NTP dispersion calculations would be invalid.

    When the server drops out, individual machines will continue with the
    last known frequency correction, which, unless distorted by whatever
    caused the server loss, will typically be within 1ppm of true, so
    100ms a day is certainly not an unrealistic expectation. If there
    was something that caused a high frequency correction error at the point
    of failure, there is a good chance that it will affect both machines
    more or less equally.

    (In my view, though, ntpd could handle this better. At the moment, it
    doesn't properly differentiate the following reasons for applying
    long term (integral) frequency corrections:

    1) environmental - fast changing but very limited in magnitude;
    2) ageing - very slow except at end of life, but could be relatively
    large.
    3) initial calibration - should only be performed on change of hardware, but
    can be very large and should be applied very quickly.

    The result is that, when upset, it can end up applying a much larger
    correction than could possibly be justified.)

  14. Re: Architecture / best practice for small/medium company setups

    Your "internal" master machines should sync with at least 4 outside servers
    plus each other. I have no opinion as to whether or not your internal
    servers should sync with the same outside servers or not.

    H

+ Reply to Thread