NTP stratum-1 architecture - NTP

This is a discussion on NTP stratum-1 architecture - NTP ; Folks, For a large organisation, I am reviewing the current NTP-infrastructure. Because high-availability is a major concern, I am considering the following architecture (improvement): * Three stratum-1 NTP-servers, geographically dispersed * Each stratum-1 NTP-server has a peering relation with each ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: NTP stratum-1 architecture

  1. NTP stratum-1 architecture

    Folks,

    For a large organisation, I am reviewing the current NTP-infrastructure. Because high-availability is a major concern, I am considering the following architecture (improvement):

    *
    Three stratum-1 NTP-servers, geographically dispersed
    *
    Each stratum-1 NTP-server has a peering relation with each other stratum-1 NTP-server
    *
    Two stratum-1 NTP servers use GPS as stratum-0.
    *
    Two stratum-1 NTP servers use Rubidium as stratum-0.
    *
    (So consequently, one stratum-1 server uses both).

    The formal requirement states that when one location fails completely, it must still be possible to apply maintance on the other NTP-infrastructure without discontinuing the service. Intuitively, I would say 3 servers are required, also because of the algorithms (which I dont understand in detail) used for identifying "false-tickers"(??). One option is to have each stratum-1 server implemented with GPS and Rubidium timesources, but especially for GPS there are cost considerations.

    Another consideration is that the stratum-2 implementation is outside the scope of the department offering the NTP-service. So we do not control this implementation, but we could define guidelines for a proper implementation. But if controlling the stratum-2 layer is an essential requirement for high availability, this probably could be implemented.

    Any comments on this architecture proposal and consequences for the implementation are highly appreciated.
    For instance, what are considered best practices for NTP-architecture?

    Thanks a lot!

    Raymond



    This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

  2. Re: NTP stratum-1 architecture

    Groenewoud, Raymond wrote:
    > Folks,
    >
    > For a large organisation, I am reviewing the current NTP-infrastructure.
    >Because high-availability is a major concern, I am considering the

    following
    >architecture (improvement):
    >
    > *
    > Three stratum-1 NTP-servers, geographically dispersed
    > *
    > Each stratum-1 NTP-server has a peering relation with each other
    > stratum-1 NTP-server
    > *
    > Two stratum-1 NTP servers use GPS as stratum-0.
    > *
    > Two stratum-1 NTP servers use Rubidium as stratum-0.
    > *
    > (So consequently, one stratum-1 server uses both).
    >
    > The formal requirement states that when one location fails completely,
    >it must still be possible to apply maintance on the other

    NTP-infrastructure
    >without discontinuing the service. Intuitively, I would say 3 servers

    are required,
    >also because of the algorithms (which I dont understand in detail)

    used for
    >identifying "false-tickers"(??). One option is to have each stratum-1

    server
    >implemented with GPS and Rubidium timesources, but especially for GPS

    there are cost
    >considerations.
    >
    > Another consideration is that the stratum-2 implementation is outside the scope of
    >the department offering the NTP-service. So we do not control this

    implementation,
    >but we could define guidelines for a proper implementation. But if

    controlling the
    >stratum-2 layer is an essential requirement for high availability,

    this probably
    >could be implemented.
    >
    > Any comments on this architecture proposal and consequences for the implementation
    >are highly appreciated.
    > For instance, what are considered best practices for NTP-architecture?
    >
    > Thanks a lot!


    First, it is customary to use the carriage return key after
    approximately seventy characters have been typed. It makes your message
    MUCH easier to read and reply to. I had to reformat your text in order
    to reply!

    I think four servers are the minimum. With only three servers, if one
    fails, you have no way to determine which of the survivors is more
    nearly correct. Five servers allows the failure of any two and seven
    servers allow the loss or failure of three without ill effect.

    Second; Rubidium, in and of itself, is not a source of time. A Rubidium
    oscillator can provide an extremely precise and stable frequency
    reference and you can determine "delta time" simply by counting the
    "ticks". Knowing what time it is requires something more than a simple
    Rubidium oscillator! Having the finest Rolex watch does not guarantee
    that you have the correct time; it's only as good as the time you use to
    set it!

    Third, if your servers are geographically remote, you introduce
    uncertainty in the time returned by those servers. The uncertainty is
    equal to one half the round trip delay. The actual error is usually far
    less than that but you cannot know it!

    A GPS disciplined quartz crystal oscillator such as the HP3816A, the
    Symmetricom BC637 or the similar product from Meinberg Funkuhren makes a
    very good reference clock. These all provide good holdover
    characteristics in case of temporary loss of GPS signals.




  3. Re: NTP stratum-1 architecture

    Groenewoud, Raymond wrote:

    > * Three stratum-1 NTP-servers, geographically dispersed * Each
    > stratum-1 NTP-server has a peering relation with each other stratum-1
    > NTP-server * Two stratum-1 NTP servers use GPS as stratum-0. * Two
    > stratum-1 NTP servers use Rubidium as stratum-0. * (So consequently,
    > one stratum-1 server uses both).


    If I read this correctly, you are exclusively relying on GPS as a time
    source (Rubidium is a frequency source). I would suggest that you use
    different *independent* time sources, and as many as practical. Radio
    signals from DCF77 and MSF both have very good signal quality in The
    Netherlands.

    N

  4. Re: NTP stratum-1 architecture

    >>> In article <0ED191612CF19246BF2E48B12CB0C719167755@nl-ex006.groupinfra.com>, raymond.groenewoud@logicacmg.com (Groenewoud, Raymond) writes:

    Raymond> Folks, For a large organisation, I am reviewing the current
    Raymond> NTP-infrastructure. Because high-availability is a major concern, I
    Raymond> am considering the following architecture (improvement):

    I recommend http://support.ntp.org/Support/DesigningYourNTPNetwork if you
    have not already seen it.

    There are tradeoffs.

    And you were saying that GPS would cost you more than rubidium?

    The problem with only 3 S1s is that if 1 is unreachable and if the other two
    drift apart for any reason, there is no way to decide which of the other 2
    to believe. If you get 4 S1s and for whatever reason they form 2 two-unit
    cliques, your downstreams will have no way to know which clique to believe.

    These problems may not be all that bad, however.

    You may be able to add a modem refclock during times of "trouble".

    And I would also recommend adding some offsite NTP servers to your mix, just
    to keep your server numbers up.

    If you have good monitoring software in place then if there is ever a
    problem people can be notified and steps taken before things get out of
    hand.

    It all boils down to how many 9s you want and can afford.

    H
    --
    http://ntpforum.isc.org - be a member!

  5. Re: NTP stratum-1 architecture

    Richard B. Gilbert wrote:

    > First, it is customary to use the carriage return key after
    > approximately seventy characters have been typed. It makes your
    > message MUCH easier to read and reply to. I had to reformat your
    > text in order to reply!


    And you made a proper mess out of it!

    :-

    Mozilla is able to wrap long lines to the message window's width,
    and it provides a "Rewrap" command to reformat the original message
    before replying. If your User-Agent string is telling the truth,
    you might want to consider upgrading.

  6. Re: NTP stratum-1 architecture

    Spoon wrote:
    > Richard B. Gilbert wrote:
    >
    >> First, it is customary to use the carriage return key after
    >> approximately seventy characters have been typed. It makes your
    >> message MUCH easier to read and reply to. I had to reformat your
    >> text in order to reply!

    >
    >
    > And you made a proper mess out of it!
    >
    > :-
    >
    > Mozilla is able to wrap long lines to the message window's width,
    > and it provides a "Rewrap" command to reformat the original message
    > before replying. If your User-Agent string is telling the truth,
    > you might want to consider upgrading.


    *plonk*


+ Reply to Thread