You are correct with one notable exception. The presence of a cesium clock is considered a de facto timing source. I've never seen a BITS system that actively disciplines a Cesium Source. What they will do is take many Cesium (or Primary Reference Sources, PRS) and verify them against each other. The output from that mathematical function is then used to discipline a Rubidium or Ovenized Crystal Oscillator. The output from THAT is then used to drive BITS feeds to telecom equipment.
The desire for everyone to have a timing source that is tracable to a Cesium clock comes from the SONET standard. If you tie two SONET networks together, if they both don't have timing that's tracable to a Stratum 1 (PRS) source, they'll drift at the points where they interconnect and PSE (Positive Stuff Event) and NSE (Negative Stuff Event) errors will be the result. This is BAD BAD BAD for the voice networks that are provisioned over SONET.
Spinka, Kristofer wrote:
You are correct with one notable exception. The presence of a cesium clock is
considered a de facto timing source. I've never seen a BITS system that
actively disciplines a Cesium Source. What they will do is take many Cesium
(or Primary Reference Sources, PRS) and verify them against each other. The
output from that mathematical function is then used to discipline a Rubidium
or Ovenized Crystal Oscillator. The output from THAT is then used to drive
BITS feeds to telecom equipment.
The desire for everyone to have a timing source that is tracable to a Cesium
clock comes from the SONET standard. If you tie two SONET networks together,
if they both don't have timing that's tracable to a Stratum 1 (PRS) source,
A Stratum 1 source will slip but thats ok if its within tolerance
If you tie two networks together that both have their own PRS source they will
still slip because of these in tolerance variances thats why its ideal to have
only one PRS.
they'll drift at the points where they interconnect and PSE (Positive Stuff
Event) and NSE (Negative Stuff Event) errors will be the result. This is BAD
BAD BAD for the voice networks that are provisioned over SONET.
Shouldnt be too bad, the MUXs that do the stuffing have their own clock
independent of the circuits so the data goes out how it comes in.
End devices connected to a single network will derive clocking from that network
and be happy with whatever that clocking does within reason (course this doesnt
work when you connect to two with their own PRS!)
Steve