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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
