Re: Cost-effectivenesss of highly-accurate clocks for NTP

[Mel Beckman <mel () beckman org>]

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 () thyrsus com> wrote:
>
> Baldur Norddahl <baldur.norddahl () 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>