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.

Groenewoud, Raymond wrote:[color=blue]
> Folks,
>
> For a large organisation, I am reviewing the current NTP-infrastructure.
>Because high-availability is a major concern, I am considering the[/color]
following[color=blue]
>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[/color]
NTP-infrastructure[color=blue]
>without discontinuing the service. Intuitively, I would say 3 servers[/color]
are required,[color=blue]
>also because of the algorithms (which I dont understand in detail)[/color]
used for[color=blue]
>identifying "false-tickers"(??). One option is to have each stratum-1[/color]
server[color=blue]
>implemented with GPS and Rubidium timesources, but especially for GPS[/color]
there are cost[color=blue]
>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[/color]
implementation,[color=blue]
>but we could define guidelines for a proper implementation. But if[/color]
controlling the[color=blue]
>stratum-2 layer is an essential requirement for high availability,[/color]
this probably[color=blue]
>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![/color]

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.

Groenewoud, Raymond wrote:
[color=blue]
> * 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).[/color]

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

>>> In article <0ED191612CF19246BF2E48B12CB0C719167755@nl-ex006.groupinfra.com>, [email]raymond.groenewoud@logicacmg.com[/email] (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 [url]http://support.ntp.org/Support/DesigningYourNTPNetwork[/url] 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
--
[url]http://ntpforum.isc.org[/url] - be a member!

Richard B. Gilbert wrote:
[color=blue]
> 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![/color]

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.

Spoon wrote:[color=blue]
> Richard B. Gilbert wrote:
>[color=green]
>> 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![/color]
>
>
> 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.[/color]

*plonk*