Cost-effectivenesss of highly-accurate clocks for NTP

[mel at beckman.org (Mel Beckman)]

I have deployed rubidium-disciplined clocks at cellular carriers, where money is no object (look at your cellphone bill), typically for $20K-$100K for redundant clocks. The holdover time on these is supposed to be days, but we've never tested that. I think I'd better. 

But a more critical deployment of rubidium clocks is in cash-strapped public safety institutions, such as local police dispatch centers. Timing is crucial for the squad car communication systems, which these days are all digital, based on wireless T1/T3 trunks to remote repeaters. The clocking on these trunks can't drift much before voice communication fails due to repeater outages. The telecom gear has OXCO clocks that can provide a few hours holdover. A rubidium clock onsite provides coverage for longer outages. 

In these installations I have tested GPS outages of up to a week without enough clock drift to knock out the Tx links. I've never gone longer than that though, so I don't know the actual breaking point. But if you lose that rubidium clock, things go south in a less than a day.

The cash-strapping comes into play when municipal bean counters eyeball the rubidium clock(s) and start thinking they can get by with a cheaper substitute. 

The upshot is that there are many real-world situations where expensive clock discipline is needed. But IT isn't, I don't think, one of them, with the exception of private SONET networks (fast disappearing in the face of metro Ethernet).

 -mel beckman

> On May 15, 2016, at 3:22 AM, Eric S. Raymond <esr at thyrsus.com> wrote:
> 
> Baldur Norddahl <baldur.norddahl at gmail.com>:
>> Ok how many hours or days of holdover can you expect from quartz,
>> temperature compensated quartz or Rubidium?
> 
> Sorry, I don't have those drift figures handy.  I'm a programmer, not
> a large-site sysadmin - I've never had purchase authority with a
> budget large enough to buy a rubidium-oscillator GPSDO or any other
> device with holdover.  Better to ask Mel Beckman or someone else
> with field experience.
> 
>>                                Should we calculate holdover as
>> time until drift is more than 1 millisecond, 10 ms or more for NTP
>> applications?
> 
> If you want to go super-accurate, 1ms.  If you want to go cheap, on
> sampling-theory grounds I'd say you want to vary your drift threshold
> from 1 to 5ms (half the expected precision of WAN time, think of it as
> the Nyquist rate) and look for a knee in the cost curve.
> 
>> I am thinking that many available datacenter locations will have poor GPS
>> signal so we can expect signal loss to be common. Some weather patterns
>> might even cause extended GPS signal loss.
> 
> Weather won't do it, usually. Rain and fog and clouds are transparent
> to GPS frequencies. Standing water directly on an antenna can cause
> some attenuation, but with any serious GPS engine made more recently
> than 5 years ago I would be extremely surprised if that lost it
> lock.  The newer ones handle down to 30 feet in ocean water on robot
> submarines.
> -- 
>        <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>