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>