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 <[email protected]> wrote: > > Baldur Norddahl <[email protected]>: >> 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>
