[ntp:questions] NTP stratum-1 architecture

Richard B. Gilbert rgilbert88 at comcast.net
Wed Dec 5 15:55:00 UTC 2007


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.






More information about the questions mailing list