[ntp:questions] NTP architecture recommendation

Jason Rabel jason at extremeoverclocking.com
Thu Aug 16 15:18:52 UTC 2007

> I need to update the current NTP infrastructure of our company, to
> have more accurate server internal timing (allowable offset during 24
> hours: < 3 ms). I would appreciate comments on my proposed solution:

You aren't going to get 3ms using NTP servers over the internet. You aren't
even going to get that using NTP servers on a LAN... With a LAN you might
get about 5-8ms if you are lucky and have low traffic, something like
10-20ms on a LAN is more realistic.

> Topology:
> HQ localted in central Europe, plus 3 datacenters spread over the
> world (US, Asia).
> Problem:
> the offset between ALL servers needs to be < 3 ms; can't put GPS-
> clocks in the datacenters (no GPS-signal); using free public NTP
> servers is not good enough (low accuracy, high jitter because of a
> number of different Inet-lines with changing latency)

The only cost-effective way you will be able to have < 3ms over that wide of
an area would be to use GPS as a time source with a direct PPS connection to
the server. You might be able to use some radio signals, but that depends on
your location and reception ability.

> My proposal:
> 1. set up two reference clocks in two separate locations in Europe
> (where we got offices), each setup consisting of:
> a) Meinberg Lantime M300 GPS with OCX LQ or even MQ in the office (ie.
> where I can get the GPS signal)
> b) Meinberg Lantime M300 MRS (no GPS antenna, just a precise internal
> clock) in the server room (this one syncs to the first one)
> 2. the datacenters in the US/Asia will each contain one Meinberg
> Lantime M300 MRS, syncing to the main 2 stratum 1 servers

> Question:
> 1. Will this setup guarantee me the required accuracy?

No... The data still has to be transmitted over the internet, so there is a
factor of uncertainty added. The oscillators in these devices are for
'holdover' ability. i.e. when they do not receive any external time
synchronization they rely on the oscillator as their time source.

> 2. Can the same be achieved with less investment?

A requirement of < 3ms will probably require more of an investment than you
think. If you can loosen your restrictions to say 10ms, or 25ms, or even 100
ms then you can reduce your costs significantly.


All that being said, here's your problem(s) and possible solutions....

Problem: 3 ms will require using a PPS type signal directly to the server.
You will actually end up with better time than that, but using NTP over
Ethernet will not get you 3 ms (due to hardware & OS) so you have to jump to
the next better sync method. PPS support requires FreeBSD, Solaris, or Linux
with a patched kernel. I think there is a window's app that will sync to a
PPS, but the Windows NTP port (AFAIK) doesn't have PPSAPI support.

Solution: The cheapest in the short-term and probably long-term would be to
somehow get GPS at all your locations. Possibly leasing roof access at the
data centers, or if they already have an antenna you can use signal
splitters and go from there. Maybe even talk the data center into setting up
their own Stratum-1 server for all their clients as a side-benefit.

Here's some specs grabbed from a brochure, the numbers will obviously vary
based on the oscillators used, but you can get a general idea of holdover
time using just an oscillator:

VCXO: 48ms/day
OCXO: 5ms/day
Rubidium: 6.5µs/month
Cesium: < 5^-14/month

Pending no GPS at all, and not wanting to make monthly trips out to each
location, a rubidium or even cesium standard would be the only way to
'guarantee' < 3 ms.

So... If could live with a greater tolerance then you could save boatloads
of money. If not, then tell the boss to get ready to shell out a lot of

More information about the questions mailing list