The Clocking Crisis: Why the Cloud is Breaking Broadcast IP
The move from SDI to IP was supposed to grant the broadcast industry ultimate flexibility. However, while ST 2110 and AES67 work flawlessly on localized, “bare metal” ground networks, they hit a wall when crossing into the cloud.
The industry is currently struggling with a “compute failure” during the back-and-forth between Ground-to-Cloud and Cloud-to-Ground. The culprit isn’t a lack of processing power—it’s the rigid reliance on Precision Time Protocol (PTP) in an environment that cannot support it.
The Problem: PTP vs. The Hypervisor
PTP (IEEE 1588) requires hardware-level timestamping. It needs to know exactly when a packet hits the physical wire. Cloud hypervisors (AWS, Azure, GCP) add layers of abstraction that introduce “scheduling jitter.”
When a cloud VM is momentarily de-prioritized by the hypervisor, the timing of the IP packets is disrupted. For a protocol like ST 2110-20, which expects nanosecond-level precision, this jitter is catastrophic. The buffers fail, the “compute” chokes, and the essence flows break.
The Solution: Syntonization over Synchronization
The industry’s mistake has been trying to force the Cloud to behave like a hardware switch. The fix lies in shifting the philosophy from Synchronization to Syntonization.
* Synchronization (Phase Aligned): Requires every device to share the exact same “time of day” and the exact same “clock tick” moment. This is what PTP attempts to do, and it is what fails in virtualized environments.
* Syntonization (Frequency Aligned): Focuses on ensuring two clocks run at the exact same rate, regardless of whether their “time of day” matches.
Why Syntonization Solves the “Back and Forth”
In a syntonized system, the receiver doesn’t care exactly when a packet arrives, as long as it arrives within a reasonable window. It uses the incoming stream to recover the frequency (clock recovery).
| Feature | PTP (Synchronization) | Syntonization (Frequency Lock)
| Network Requirement | Deterministic / L2 / Boundary Clocks | Asynchronous / L3 / Standard Internet |
| Cloud Compatibility | Poor (Requires Bare Metal/EFA) | Native (SRT, RIST, NDI) |
| Buffer Strategy | Microscopic (Ultra-low latency) | Adaptive (Resilient to Jitter) |
| Compute Impact | High overhead to maintain sync | Low; handles variable CPU cycles |
Redefining the Architecture
To stop the compute failures, the “Back and Forth” must be treated as a translation of timing philosophies:
* The Ground (PTP): Keep ST 2110 and PTP for local, ultra-low latency production where hardware control exists.
* The Bridge (Syntonization): At the network edge, use a gateway to convert 2110 into a syntonized protocol like SRT or JPEG XS. These protocols use timestamps within the stream to maintain frequency, allowing them to survive the “jittery” trip to the cloud.
* The Cloud (Timing Agnostic): Process the media using internal cloud clocks or protocols like AWS CDI, which are designed to handle the nuances of virtualized compute
PTP is a hardware-era solution being forced into a software-defined world. By embracing Syntonization, broadcasters can finally achieve the “Ground-to-Cloud” mobility they need without the compute crashing every time a hypervisor skips a beat.