Speaker 1: Welcome to the deep dive. Today, we're getting into something
Speaker 1: fundamental but often totally invisible, network synchronization. And we're not
Speaker 1: just talking about you know, knowing it's lunchtime. We mean
Speaker 1: hyper precise time down to nanoseconds that underpins things like
Speaker 1: five G automated trading.
Speaker 2: The works. It really does hold it all together. Our
Speaker 2: mission today really is to get a handle on the
Speaker 2: basics of this digital time. You know, what are the
Speaker 2: different kinds of zync frequency, phase time, and how do
Speaker 2: we actually get this level of precision across huge networks
Speaker 2: down to the nanosecond. And there's a key point in
Speaker 2: the source material too. When this stuff fails, it's sneaky.
Speaker 1: Yeah, that really jumped out. It says timing failures often
Speaker 1: look like something else entirely.
Speaker 2: At first exactly. I remember back in my circuit board
Speaker 2: design days, a clock problem could totally look like a
Speaker 2: software bug or just weird logic makes it incredibly hard
Speaker 2: to track down. Now, scale that up from one board
Speaker 2: to say, a whole continence network, multiple vendors, different gear
Speaker 2: a few microseconds off could look like a bad route,
Speaker 2: a broken process. Really tough.
Speaker 1: Okay, so let's maybe start at the beginning time seems simple, yeah, right,
Speaker 1: but trying to get everyone on the same page globally, Yeah,
Speaker 1: that I complicated fast.
Speaker 2: Oh absolutely. I mean historically, every town just set its
Speaker 2: clock by the sun. Noon was noon locally. Worked fine
Speaker 2: until the trains came along. Suddenly you needed timetables that
Speaker 2: worked across different zones. You couldn't have a train leaving
Speaker 2: one town at two pm and arriving somewhere else, you know,
Speaker 2: before two pm according to their clock. That push, that
Speaker 2: need for consistency led to standardizing time ach wor Greenwich
Speaker 2: Meantime GMT back in eighteen eighty four.
Speaker 1: Right, GMT. But today the standard is Coordinated Universal Time UTC.
Speaker 1: What's the practical difference for most people or for these networks.
Speaker 2: Well, the core reference is different. UTC is what we
Speaker 2: all use. Yeah, but it's based on International Atomic Time TAI.
Speaker 2: TI comes from hundreds of atomic clocks around the world.
Speaker 2: It's incredibly stable, just ticks a long perfectly, well almost perfectly.
Speaker 2: It's continuous. But UTC is what we call discontinuous. We
Speaker 2: sometimes have to add leap seconds.
Speaker 1: Ah, yes, leap seconds the bane of sysadminin's everywhere.
Speaker 2: Huh, exactly, They exist because the Earth's rotation isn't perfectly regular.
Speaker 2: It wobbles a bit, so the IIRS, that's the International
Speaker 2: Earth Rotation Service, they manage these leap seconds. The goal
Speaker 2: is to keep UTC within zero point nine seconds of
Speaker 2: the actual solar day, you know, based on Earth's spin.
Speaker 1: Okay, so if UTC is the gold standard, how do
Speaker 1: we know what the real official UTC is like right
Speaker 1: this second.
Speaker 2: That's the fascinating part. You don't not perfectly in real time.
Speaker 2: Any time signal you get right now is an approximation,
Speaker 2: a very very good one hopefully, but still an approximation.
Speaker 2: The actual single official UTC value. It's only calculated after
Speaker 2: the month ends. They gather data from all those atomic clocks,
Speaker 2: globally process it, and then the BPM, the International Bureau
Speaker 2: of Weights and Measures, publishes the definitive value in something
Speaker 2: called circular t, usually a couple of weeks late.
Speaker 1: So the absolute truth about this very nanosecond we won't
Speaker 1: know it for weeks.
Speaker 2: Pretty much kind of changes how you think about real time,
Speaker 2: doesn't it.
Speaker 1: It really does? Okay? Knowing the official time is always
Speaker 1: a bit delayed, that's a big takeaway. Now let's talk terminology.
Speaker 1: Synchronization gets thrown around a lot, but the sources are clear.
Speaker 1: There are three distinct types.
Speaker 2: Yeah, getting these straight is super important if you're dealing
Speaker 2: with high performance networks. Let's maybe use an orchestra analogy.
Speaker 1: Okay, sound good. Let's start with frequency synchronization. What's that about.
Speaker 2: Frequency sync is about the rate of the clock, the
Speaker 2: tempo maybe, or the pitch in music. So in the orchestra,
Speaker 2: it's making sure two violins are playing the exact same
Speaker 2: a you know, four hundred and forty hertz, four hundred
Speaker 2: and forty oscillations per second. In a network device, it
Speaker 2: means making sure its internal oscillator is ticking at the
Speaker 2: correct speed, its nominal frequency. We can use external sources
Speaker 2: like SINCSA, which we'll get to to make that much
Speaker 2: more accurate. Instead of maybe being off by say four
Speaker 2: point six parts per million, we can get down to
Speaker 2: like sixteen parts per billion, much tighter control over the rate.
Speaker 1: Okay, so frequencies of the rate, the speed of the ticking.
Speaker 1: What about phase synchronization? Then?
Speaker 2: Facinc is about aligning the tick itself, making sure the
Speaker 2: ticks happen at the exact same instant. Back to the orchestra.
Speaker 2: It's the conductor ensuring everyone hits the downbeat together right
Speaker 2: on time. Phase is about the relative offset between clocks,
Speaker 2: usually measured in tiny fractions of a second, milliseconds, microseconds, nanoseconds.
Speaker 2: It's about agreeing on when now is.
Speaker 1: And the sources gave a really good, kind of stark
Speaker 1: example of why phase matters so much in industry factory automation.
Speaker 2: Oh yeah, that's a perfect illustration. Imagine you've got two
Speaker 2: robots passing a part between them. They're not using cameras,
Speaker 2: they're just timed. Robot A let's go at say start
Speaker 2: plus point four over zero seconds. Robot B needs to
Speaker 2: grab it at exactly start plus point four zero zero
Speaker 2: seconds for that to work. Their idea of when start
Speaker 2: plus zero point zero zero theory happen has to be
Speaker 2: absolutely identical. Now, their facecinc is a bit loose, maybe
Speaker 2: only accurate to fifty milliseconds. Robot A might let go
Speaker 2: fifty milliseconds before Robot B is ready, and bam, part
Speaker 2: hits the floor, a physical failure caused by a tiny,
Speaker 2: tiny timing error.
Speaker 1: Wow, so fifty milliseconds is enough to cause real physical problem.
Speaker 2: Absolutely shows you the stakes.
Speaker 1: That factory example really brings it home. Milliseconds matter physically,
Speaker 1: but looking at the big data networks, the requirements are
Speaker 1: pushing into micro seconds, even nanoseconds. Why such extreme precision
Speaker 1: across whole continents?
Speaker 2: Right, It's not just factories. There are really three big
Speaker 2: areas pushing this need for tighter and tighter timing.
Speaker 1: Okay, where should we start? Maybe one? We can perceive
Speaker 1: directly audio and video.
Speaker 2: Yeah, av sync. Humans are surprisingly sensitive to this. Research
Speaker 2: shows if the audio is ahead of the video by
Speaker 2: just forty milliseconds that's less than two frames of video,
Speaker 2: about twenty percent of people will notice it it feels wrong.
Speaker 2: So for professional broadcast streaming movies, they use specific timing
Speaker 2: profiles like SMPTE twenty five nine to two built on
Speaker 2: PTP to keep audio and video locked tight.
Speaker 1: Okay, so av is on one. What about finance? You
Speaker 1: mentioned high frequency trading earlier.
Speaker 2: Definitely a huge driver. This really kicked into high gear
Speaker 2: with a regulation called MIFIED two from the EU back
Speaker 2: in twenty fourteen. It basically mandated that all high frequency
Speaker 2: trading transactions had to have super accurate time stamps. Traceable
Speaker 2: time stamps. We're talking precision way beyond what older protocols
Speaker 2: like MTP could reliably deliver. It became a legal necessity
Speaker 2: for transparency, for proving when trades happened, preventing manipulation, they
Speaker 2: needed microsecond Sometimes better accuracy makes sense.
Speaker 1: Legal compliance often pushes technology, but the sources suggests the
Speaker 1: biggest driver, the one really pushing phasinc. Everywhere, is mobile
Speaker 1: networks five G.
Speaker 2: Specifically, without a doubt, five G is the main engine
Speaker 2: right now for widespread phase synchronization, deployment and transport networks.
Speaker 2: The core reason is a technology called time division duplex
Speaker 2: or TDD. In TDD, a base station uses the same
Speaker 2: chunk of radio frequency to both transmit and receive. It
Speaker 2: just switches really fast between the two. Now, imagine two
Speaker 2: base stations near each other. If one is transmitting while
Speaker 2: its neighbor is trying to receive on that same frequency,
Speaker 2: you get massive interference. They jam each other.
Speaker 1: Uh okay. So they have to coordinate very very carefully
Speaker 1: when they transmit and when they listen exactly.
Speaker 2: They need extremely tight phase alignment. The requirement is pretty stunning.
Speaker 2: The time difference between any two neighboring base stations has
Speaker 2: to be less than three microseconds, and the way networks
Speaker 2: achieve that is by making sure every base station across
Speaker 2: the entire network is synchronized to the master UTC reference
Speaker 2: clock to within plus or minus one point five microseconds.
Speaker 2: If everyone stays within that one point five microsecond window
Speaker 2: relative to UTC, then any two neighbors will automatically be
Speaker 2: within three microseconds of each other.
Speaker 1: Plus or minus one point five microseconds. Wow, that's the
Speaker 1: tolerance across the whole system.
Speaker 2: Tolerance it's demanding.
Speaker 1: Okay, so we understand the need plus or minus one
Speaker 1: point five microseconds for five G, even tighter for finance
Speaker 1: in some cases, How do networks actually get this timing
Speaker 1: signal and then distribute it reliably? Where does it originate?
Speaker 2: Well, the ultimate source, the primary reference time clocks or prtcs.
Speaker 2: Those are generally the Global Navigation Satellite Systems GNSS, So
Speaker 2: think GPS, which is the US system, gel NASS from Russia,
Speaker 2: Galileo from Europe, bay DO from China. They are, in essence,
Speaker 2: constellations of atomic clocks orbiting the Earth. They constantly broadcast
Speaker 2: signals that include very precise timing information. Receivers on the
Speaker 2: ground pick these up and can figure out their position,
Speaker 2: and crucially for us, the current precise time. Got it?
Speaker 1: So the time comes from space basically. Then once a
Speaker 1: receiver on the ground has that signal, how does it
Speaker 1: get shared across say miles of fiber optic cable in
Speaker 1: the finance port network. What tools do network designers use?
Speaker 2: There are two main specialized methods used often in combination.
Speaker 2: The first one is called synchronous ethernet or sink.
Speaker 1: Okay, sink E. What's this role?
Speaker 2: Sink E is all about frequency synchronization, remember the rate
Speaker 2: of the clock. It's actually built into the physical layer
Speaker 2: of the ethernet connection, kind of like how older technologies
Speaker 2: like SDH or sonnet handled frequency. It allows network devices
Speaker 2: to pass along a very stable frequency reference directly over
Speaker 2: the fiberlink itself, without needing special timing packets or relying
Speaker 2: on software higher up. So it's very reliable, very predictable
Speaker 2: for keeping the rate stable across the network carrier grade frequency.
Speaker 1: Okay, so SYNC nails the frequency. What about the actual
Speaker 1: time of day, the phase alignment down to microseconds. That's
Speaker 1: the other one. PTP exactly.
Speaker 2: PTP the precision time protocol that's defined by IE fifteen
Speaker 2: eighty eight PTP is specifically designed to distribute precise phase
Speaker 2: and time synchronization over packet networks. Like standard ethernet networks,
Speaker 2: it aims for microsecond level accuracy, sometimes even better. The
Speaker 2: key thing that makes PTP so much better than older
Speaker 2: protocols like NTP is its use of hardware time stamping.
Speaker 1: Hardware time stamping what does that mean?
Speaker 2: It means the time stamps marking when a PTP timing
Speaker 2: packet arrives or departs, are applied right at the network
Speaker 2: interface card as close to the physical wire as possible.
Speaker 2: If you rely on the main CPU or the operating
Speaker 2: system to do the time stamping, you introduce all sorts
Speaker 2: of delays and variability jitter that kills your accuracy. PTP
Speaker 2: with hardware support bypasses a lot of that software unpredictability.
Speaker 1: Right, get the time stamp as close to the physical
Speaker 1: event as possible makes sense. So SYNCY for frequency stability,
Speaker 1: PTP for phase and time accuracy. How do operators get
Speaker 1: the absolute best result? Do they choose one or the other?
Speaker 2: Usually for the most demanding applications like five G, they
Speaker 2: use both together. It's often called hybrid mode. They use
Speaker 2: sync along constantly on the physical layer to provide that
Speaker 2: rock solid, stable frequency foundation, and then they run PTP
Speaker 2: on top of that stable frequency to distribute the precise
Speaker 2: phase and time information. This combination gives you the best
Speaker 2: of both worlds, the stability of SYNC and the accuracy
Speaker 2: of PTP. It's generally considered the gold standard for carrier
Speaker 2: networks define inspects like the itut G point eight two
Speaker 2: seven five point one profile for telecom. It provides deterministic performance.
Speaker 1: Okay, so hybrid mode seems like the way to go.
Speaker 1: But even with the best protocols, the network itself can
Speaker 1: fight back, right. The sources mentioned packet delay, variation, jitter,
Speaker 1: and something called asymmetry as the main enemy. So let's
Speaker 1: focus on asymmetry.
Speaker 2: What is that, ah, asymmetry. Yes, that's a really tricky
Speaker 2: one for PTP. It's kind of the silent killer of
Speaker 2: timing accuracy. See PTP works out the time it takes
Speaker 2: for a packet to travel from the master clock to
Speaker 2: the slave clock by measuring the total round trip time
Speaker 2: and then dividing by two. It fundamentally assumes that the
Speaker 2: path delay from master to slave is exactly the same
Speaker 2: as the path delay from slave back to master.
Speaker 1: AH Okay, it assumes the journey takes the same amount
Speaker 1: of time in both directions precisely.
Speaker 2: Asymmetry is simply when that assumption is wrong, when the
Speaker 2: forward path delay is different from the reverse path delay.
Speaker 1: What could cause that?
Speaker 2: Yeah, different routs exactly. Maybe the packets go out via
Speaker 2: one set of routers and fibers but come back via
Speaker 2: completely different set due to network routing decisions. Or maybe
Speaker 2: the five verer length itself is physically different in one
Speaker 2: direction versus the other in some older setups. Or maybe
Speaker 2: there's traffic congestion affecting delays only in one direction. Lots
Speaker 2: of potential causes.
Speaker 1: Why is that so bad for PTP?
Speaker 2: Because of what some call the golden rule of packet timing,
Speaker 2: half of the total path asymmetry shows up directly as
Speaker 2: a constant time error a phase offset at the slave clock.
Speaker 2: So if your network path has one hundred nanoseconds of asymmetry,
Speaker 2: meaning the trip one way is one hundred thens longer
Speaker 2: than the other way, your slave clock will be permanently
Speaker 2: wrong by fifty nanoseconds. PDP can't easily detect or correct
Speaker 2: for that on its own.
Speaker 1: Wow, fifty nanoseconds just baked in his error. Okay, that's
Speaker 1: a huge deal when the total budget is only, say,
Speaker 1: fifteen hundred nanoseconds. Yeah, so that's an internal network problem.
Speaker 1: What about the sorts itself. We rely heavily on GNSS
Speaker 1: those satellites. Are they vulnerable?
Speaker 2: Oh? Absolutely, that's a major concern. GENUSA signals are very
Speaker 2: weak by the time they reach the ground. This makes
Speaker 2: them susceptible to jamming, basically overpowering the signal with noise
Speaker 2: so the receiver can't lock on. That's denial of service.
Speaker 2: Even more worrying, perhaps, is spoofing. That's when an attacker
Speaker 2: transmits fake GNSS signals to trick the receiver into calculating
Speaker 2: the wrong time or position.
Speaker 1: So some could potentially feed incorrect time into the network
Speaker 1: at its source.
Speaker 2: It's a known vulnerability. Yes, and because our critical infrastructure,
Speaker 2: power grids, finance, mobile networks relies so heavily on GNSS timing,
Speaker 2: this vulnerability is taken very seriously. Resilient backup timing sources
Speaker 2: are becoming essential, not just nice to haves.
Speaker 1: Is that where things like h l RAN come in.
Speaker 1: I saw that mention enhanced.
Speaker 2: Loran exactly A loran is being looked at and deployed
Speaker 2: in some regions as a terrestrial backup or complement to
Speaker 2: space based GNSS. Loran uses very powerful low frequency radio
Speaker 2: transmitters on the ground. The signals are much harder to
Speaker 2: jam than genss and can penetrate buildings, tunnels, even underground
Speaker 2: to some extent where satellite signals can't reach. The goal
Speaker 2: for l RAN is to provide UTC traceability potentially down
Speaker 2: to the fifteen nanosecond level, offering a really robust alternative
Speaker 2: if GNSS is unavailable or compromised.
Speaker 1: Interesting a ground based backup using very different technology.
Speaker 2: Yeah, diversity and sources is key for resilience. Hashtag tag outro.
Speaker 1: Okay, we'scovered a lot of ground here, from old town
Speaker 1: clocks needing sun dials to needing nanoseca precision from space
Speaker 1: and distributing it globally. Before we wrap up, let's quickly
Speaker 1: just nail down the difference between two terms we used,
Speaker 1: accuracy and stability. They sounds similar, but.
Speaker 2: Aren't the same, right, correct, They're related, but distinct. Accuracy
Speaker 2: is about how close your clock is to the true
Speaker 2: reference time. Like UTC, we measure it using time error.
Speaker 2: Often the maximum absolute time error maxte is your clock
Speaker 2: actually showing the right time. Stability, on the other hand,
Speaker 2: is about how consistently your clock ticks does its rate
Speaker 2: change over time. A clock could be very stable its
Speaker 2: frequency doesn't drift much but still be inaccurate if it
Speaker 2: was set wrong initially, or it could be unstable it's
Speaker 2: rate wandering even if it happens to be accurate right now. Ideally,
Speaker 2: for network timing, you want both high accuracy and high stability.
Speaker 1: Got Accurate means close to the truth. Stable means keeps
Speaker 1: a steady beat. So looking ahead, we talked about that
Speaker 1: demanding one point five microsecond absolute requirement from five G
Speaker 1: relative to UTC, but the source material also mentions something
Speaker 1: even tighter, e merging relative timing requirements between nearby five
Speaker 1: G radios, sometimes needing alignment as close as sixty five nanoseconds.
Speaker 2: That's right. That relative requirement is incredibly tight. It's needed
Speaker 2: for some of the really advanced five G features, like
Speaker 2: coordinated multipoint comp where multiple cell sites coordinate transmissions to
Speaker 2: your phone simultaneously, or for sophisticated massive MIMO antenna arrays.
Speaker 2: These features only work if the radios involved are synchronized
Speaker 2: to each other with extreme precision, far tighter than just
Speaker 2: their individual alignment to UTC.
Speaker 1: Okay, sixty five nanoseconds relative alignment. So here's the final
Speaker 1: thought we wanted to leave you the listener with. Today
Speaker 1: we learned that half of any path asymmetry turns directly
Speaker 1: into time air. If these new radio features demand relative
Speaker 1: accuracy down to maybe sixty five nanoseconds between sites, what
Speaker 1: kind of challenges does that create for the people designing
Speaker 1: and running these transport networks, especially if they're getting their
Speaker 1: timing signal maybe as a service over fiber circuits owned
Speaker 1: by a third party, where they might not have full
Speaker 1: control or visibility over the path symmetry.
Speaker 2: Yeah, that's the rub, isn't it. The margin for error
Speaker 2: is just vanishingly small. Trusting that the underlying path provides
Speaker 2: that level of nanosecond symmetry constantly, that's going to be
Speaker 2: I think one of the next big headaches and opportunities
Speaker 2: in network timing. How do you guarantee that?
Speaker 1: Definitely something to chew on. A fascinating look into an
Speaker 1: invisible world. Thanks for joining us on the deep dive.