[ntp:questions] Re: a couple of questions

Helmut Wollmersdorfer helmut at wollmersdorfer.at
Thu Nov 4 12:13:58 UTC 2004

Folkert van Heusden wrote:

> 1. what is the mtbf for a typical atomic clock? how often do these
> devices fail? 

I don't know.

> 2. when one uses an atomic clock, should one still use 3
> of them because of fals tickers? or are atomic clocks reliable enough?

Depends on your requirements. There are some questions to ask yourself:
- Why do you need accurate time?
- How accurate should it be?
- Which level of availability do you need - 99%, 99.9 %, ... 99.99999%?
- What is the MTR (Meantime To Repair)?

E.g. a service like DCF77 uses 3 atomic clocks, to provide very accurate 
time. They also have a second sender, which they use in case the main 
sender needs maintenance.

Second example:
I myself run a high availabilty cluster as multi purpose (web, file, 
mail, time etc.) server. As I have a small, low traffic network, mostly 
linux, accuracy below 1 second will be enough. The most sensible part, 
DRBD wich mirrors data in realtime, has no time dependencies. Heartbeat, 
the cluster management software, has time dependencies, but in terms of 
some seconds. For my above needs the accuracy +/- 0.01 seconds of 
pool.ntp.org will be enough.

The reason for more accuracy is, that I want time stamps as accurate as 
possible in my _test_ environments.

Lets look at MTR and SPOF (Single Point Of Failure). Hardware fails. 
 From experience this always happens on weekend, where you cannot get 
spare parts. Or it happens, when I am far away for two weeks. Worst case 
my time to repair can be weeks, and the only possibility is, to avoid 
SPOF as much as possible. This means, that I try to have different time 
references on each node of the cluster. If one node is down, the other 
node works. If the WAN connection to pool.ntp is out, DCF works. If the 
DCF sender is down, HBG works.

> 3. when using a pc as a kind of proxy, e.g.: it runs ntpd and connects
> to 4 upstream ntp-servers, and all clients connect to this one system.
> should one still preferably have 3 proxy-systems instead of 1? or only
> when the upstream link is likely to be broken in some cases? 

See SPOF above. In case of only 1 proxy what happens, if this proxy or 
the connection to it is down?

> 5. if one has 3 time servers in an intranet, does it make sense to hook
> up a gps receiver to each of them, even if the gps receivers are
> installed at the same location on the roof of the building? 

It makes sense to have more than one, because cables can break, power 
supplies can stop to work etc. If budget is not a great problem, I would 
connect GPS and a different time source (like DCF) to each server.

> 6. what is
> the mtbf of a typical dcf77 receiver?

Don't know.

> 7. if one has 3 time servers in an intranet, does it make sense to hook
> up a dcf77 receiver to each of them, even if the dcf77 receivers are
> installed at the same location in the building? 

I do it that way. I choosed the best place where I have a good and 
stable signal, mounted each receiver beneath the other. The only reason 
to choose different locations could be, if you expect e.g. large steel 
containers near your receivers.

> 8. about peering servers: should they peer if they use the same
> upstream-servers? or in any case?

I peer them to minimize the difference between my time servers. Even 
with same hardware, same network and same upstreams there are usally 
different offsets and jitter of the references.

Helmut Wollmersdorfer

More information about the questions mailing list