PTP and SMPTE ST 2059 in ST 2110 Systems: There Is No IP Broadcast Without Time Synchronization

Summary

• PTP is the clock of an ST 2110 system: it keeps video, audio, and ANC flows locked to the same time reference
• SMPTE ST 2059 defines how IEEE 1588 PTP is used in professional broadcast environments
• ST 2110-10 connects the system timing model to PTP time
• ST 2110-21 describes the timing behavior of video RTP packets as they leave the sender
• TAI/UTC/leap seconds and ST 2059-1 explain how PTP time maps into video frames, audio samples, and RTP timestamps
• Grandmaster selection, BMCA, boundary clocks, and transparent clocks are critical production design decisions
• When PTP is wrong, video may appear to exist, but audio drift, lip-sync issues, buffer problems, jitter, and receiver lock failures can follow

Note: This article complements the timing layer of the ST 2110 campus, ST 2110 routing, ST 2110 monitoring, NMOS, and Intel MTL articles.

1. Why is PTP so important?

In the SDI world, devices are usually locked to black burst or tri-level sync. In the ST 2110 world, media travels as IP packets, but this does not remove the need for a timing reference. It makes timing even more central.

In ST 2110, video, audio, and ancillary data are separate RTP flows. These flows may use different multicast addresses, different UDP ports, and even different devices. For a receiver to align them correctly, every device needs to share the same time language. That common time language is provided by PTP.

Put simply:

• RTP carries the media
• SDP describes the flow
• NMOS manages the connection
• PTP tells the system what time it is

Without PTP, ST 2110 devices may still send packets, but they will not behave like a broadcast system. If devices do not run at the same frequency, drift appears over time. If they do not share the same epoch and alignment points, frame, audio sample, and ANC timing cannot be interpreted reliably.

2. What does SMPTE ST 2059 solve?

IEEE 1588 is a general Precision Time Protocol standard. It can be used in finance, power systems, telecom, industrial networks, broadcast, and many other environments. For broadcast, however, saying “we use PTP” is not enough. Which profile, which epoch, which domain, which message intervals, and which alignment behavior should be used?

The SMPTE ST 2059 family provides the broadcast answer:

For ST 2110 systems, the SMPTE ST 2059-2 PTP profile is especially important. It makes devices expect the same broadcast timing behavior.

The key point is this: when a switch or endpoint says “PTP supported,” that does not automatically mean it is suitable for broadcast. A device may support IEEE 1588 and still fail to support the SMPTE ST 2059-2 profile correctly.

3. ST 2059 epoch, TAI, UTC, and leap seconds

To understand PTP time, it is important to understand the difference between UTC and TAI.

One reason PTP is valuable for broadcast is that time distribution becomes deterministic and controlled with respect to leap seconds. A grandmaster often receives UTC information from a reference such as GNSS, knows the UTC-TAI offset, and distributes the correct time into the PTP domain.

In ST 2110, this time is not mainly used to answer “what time is shown on the wall clock?” It is used to align frames, audio samples, and RTP timestamps.

RTP timestamp and PTP are not the same thing. RTP timestamp is the media flow’s own time axis; PTP is the facility-wide time reference. A receiver interprets them together to answer “when should this video frame be presented, and which audio sample aligns with it?”

In ST 2110 environments, this relationship also appears in SDP. ts-refclk tells the receiver that the timestamp reference clock is PTP, while mediaclk describes how the RTP media clock relates to that reference.

1
2

a=ts-refclk:ptp=IEEE1588-2008:00-1D-C1-FF-FE-12-34-56:127
a=mediaclk:direct=0

This detail matters: packets may arrive on the correct multicast address, but if the SDP describes the clock reference incorrectly, the receiver can interpret media timing incorrectly. For that reason, SDP clock lines should be checked during PTP troubleshooting.

4. ST 2059-1: Video phase alignment

ST 2059-2 defines the PTP profile; ST 2059-1 explains how video/audio signal phase is derived from PTP time.

In other words: once we have PTP time, when does a video frame begin? How do 1080p50, 1080i59.94, or 2160p50 signals relate in phase to the PTP epoch? ST 2059-1 provides the model for those questions.

For example:

• 1080p50 has a 20 ms frame period
• 2160p50 also has a 20 ms frame period, but with different payload and bandwidth
• 59.94-based formats require careful handling of 1000/1001 timing
• audio sample clock, video frame boundary, and RTP timestamp must be aligned together

This is why ST 2059 is not just about “making device clocks match.” It also makes devices calculate video frame starts, audio sample alignment, and media presentation time using the same timing model.

5. Are PTP, NTP, and genlock the same thing?

No.

NTP is still useful for logs, monitoring, and general operating system time. But it is not used for ST 2110 media essence alignment. That requires PTP synchronization with hardware timestamping.

6. Grandmaster, ordinary clock, boundary clock, transparent clock

Not every device has the same role in a PTP network.

In a small lab, a grandmaster may directly reach endpoints. In a large production fabric, boundary clock or transparent clock design usually becomes essential.

With the wrong design, endpoints may see poor time even when the grandmaster itself is healthy. Causes include switch path delay, queueing, missing QoS for PTP packets, or incorrect boundary/transparent clock behavior.

7. BMCA: how is the grandmaster selected?

A PTP network may have more than one grandmaster candidate. The Best Master Clock Algorithm (BMCA) decides which clock becomes master.

BMCA typically evaluates:

• priority1
• clock class
• clock accuracy
• offset scaled log variance
• priority2
• clock identity

In production, BMCA should not be treated as magic automation. The expected grandmaster must actually win, the backup grandmaster must wait in the intended order, and failover behavior must be tested.

Clock Class is especially important for both BMCA decisions and operational monitoring. Values should be interpreted according to the profile and device behavior, but common field examples include:

This is why “a GM exists” is not enough. GM clock class, reference state, and holdover behavior should also be monitored.

Practical warning: failover is not successful just because “device B became master.” You also need to verify whether receivers lost lock, whether audio drift appeared, and whether ST 2022-7 paths are seeing different time sources.

8. Redundant time architecture

In real ST 2110 facilities, a single-grandmaster design is usually not considered enough. A common approach is to use two grandmasters connected to the same reference source or to controlled redundant references.

Three behaviors should be tested in this architecture:

Holdover means “the system continues running”; it does not mean “time quality stayed the same.” Holdover duration, clock class changes, and offset drift should therefore generate monitoring events or alerts.

9. PTP domain and profile confusion

Broadcast sites may have multiple time domains:

• ST 2059-2 domain
• AES67 audio domain
• test/lab domain
• vendor default domain
• different PTP/NTP behavior on the control network

One common mistake is having devices visible on the same multicast media fabric but locked to different PTP domains. In that case, a receiver may get SDP, join multicast, and receive packets, yet media timing may still be wrong.

Domain mismatches are especially common when ST 2110 and AES67 devices are used together. In practice, SMPTE ST 2059-2 commonly uses default domain 127, while AES67 commonly uses default domain 0. When AES67 devices remain on domain 0 while ST 2059 devices operate on domain 127, the result can be a hard-to-diagnose “packets are arriving, but timing is wrong” problem.

Production note: the fact that 127 is a default does not make it the best choice for every facility. Some designs use a documented non-default domain to reduce collisions with vendor defaults. The important part is that the domain is chosen deliberately, applied consistently, and monitored explicitly.

10. PTP message types: what is actually on the network?

When troubleshooting PTP, it is not enough to ask “is PTP present?” You need to know which messages are arriving regularly.

In ST 2059-2 environments, Announce messages are especially important for understanding BMCA behavior. Sync and Follow_Up help you inspect the quality of time distribution. Delay messages participate in path delay calculation.

The distinction between One-Step Clock and Two-Step Clock also matters:

This difference is directly visible in Wireshark when inspecting grandmaster, switch, and endpoint behavior. If Follow_Up is expected but missing, or if devices disagree on one-step/two-step behavior, PTP analysis can become misleading.

The delay mechanism matters as well:

Mixing E2E and P2P behavior carelessly inside the same PTP domain can break path delay calculation and receiver lock behavior. Switches, grandmasters, and endpoints should be verified against the same delay mechanism expectation.

11. QoS: PTP is small traffic with large consequences

PTP traffic is tiny in bandwidth terms, but it is extremely sensitive to delay variation. For this reason, broadcast networks often place PTP in the highest-priority queue.

Typical design logic:

DSCP/CoS values vary by vendor and facility policy. Some designs use CS7 or similarly high classes for PTP, and EF/AF-based classification for media. The important point is not memorizing one value; it is preserving the same QoS policy across the entire switch fabric.

Commands and details differ across Arista, Cisco, NVIDIA/Mellanox, Evertz, Grass Valley, Imagine, or Lawo ecosystems, but the principle is the same: PTP packets should not wait behind the wrong queue, and switch residence-time uncertainty should be minimized.

12. Relationship between ST 2022-7 and PTP

ST 2022-7 provides media redundancy; it does not automatically provide PTP redundancy. This distinction is critical.

With ST 2022-7, the same RTP stream is transported over A and B paths. The receiver combines packets from both paths using sequence numbers and timing behavior. But if A and B paths see different PTP domains, different grandmasters, or different clock quality, seamless switching may behave worse than expected.

Bad examples:

• A path is locked to GM A, B path is locked to GM B, but the GMs are not tied to the same reference
• A path uses domain 127, B path uses domain 0
• A network uses boundary clocks, B network uses transparent clocks, and delay behavior differs
• Media is ST 2022-7 redundant, but PTP is available only through one path

In production design, the PTP strategy should be considered together with A/B media redundancy. GM identity, A/B path offset difference, and receiver behavior during failover must be tested together.

13. ST 2110-30, AES67, and audio clock recovery

ST 2110-30 is closely related to AES67 timing concepts. Frame boundaries are critical on the video side; sample clock and packet time alignment are just as critical on the audio side.

PTP is also the reference for audio sampling clocks. In a 48 kHz audio system, if sender and receiver are not locked to the same time reference, audio drift, sample slips, clicks/pops, or lip-sync problems can appear.

This is why PTP problems do not always appear first as video lock failures. Sometimes the first visible symptom is slow audio drift or occasional audio artifacts.

14. Linux side: ptp4l, phc2sys, and hardware timestamping

In software-based ST 2110 systems, Linux host timing becomes critical. This is especially true when working with Intel MTL, FFmpeg, GStreamer, or custom RTP applications, where NIC hardware clocks, kernel clocks, and application timestamp behavior must be understood.

Core components:

Simplified flow:

Useful checks:

1
2
3
4
5

ethtool -T eth0
pmc -u -b 0 'GET CURRENT_DATA_SET'
pmc -u -b 0 'GET TIME_STATUS_NP'
journalctl -u ptp4l -f
journalctl -u phc2sys -f

If ethtool -T does not show hardware timestamping support, expecting high-accuracy ST 2110 timing is not realistic. Lab tests may still appear to work, but production behavior is a different matter.

15. Relationship between ST 2110-21 and PTP

ST 2110-21 describes how a video RTP sender times packet output. PTP answers “what time is it?” ST 2110-21 answers “how should these video packets leave according to that time?”

Even if PTP is correct, a bursty sender can still stress receiver buffers. Conversely, even if sender pacing is good, bad PTP offset or drift can break synchronization. PTP and packet pacing are separate but tightly connected topics.

1
2
3
4
5

Bad case:
PTP offset + bursty packet output + small receiver buffer = lock/drop/jitter problems

Good case:
Stable PTP + ST 2110-21-compliant pacing + correct buffer = deterministic media flow

16. Minimal lab topology

You do not need a huge fabric to learn PTP. But the lab should still be designed like a production system.

Minimum checklist:

• Is the grandmaster running the ST 2059-2 profile?
• Does the switch prioritize PTP packets with QoS?
• Do all endpoints see the same PTP domain?
• Is NIC hardware timestamping active?
• Are ptp4l offset and frequency adjustment values stable?
• Are there RTP packet loss or sequence gaps?
• Is receiver buffer level and lock state being monitored?

17. Production design checklist

Even when a PTP design looks correct on a diagram, it should not be trusted without testing. Failover testing should happen during commissioning, not only during planned maintenance.

18. Monitoring: which metrics matter?

PTP monitoring is not just “locked/unlocked.” A device may appear locked and still produce poor timing quality.

Important metrics:

• grandmaster identity
• clock class
• PTP domain
• offset from master
• mean path delay
• frequency adjustment
• port state
• announce/sync/follow_up message counters
• BMCA state changes
• servo state
• GM failover events

The PTP servo is the control loop that disciplines the endpoint’s local clock toward the grandmaster. If servo state is unstable, the system should not be considered healthy even when a single offset sample looks good.

Example alert logic:

Example operational thresholds depend on facility policy and device tolerance, but the following is a useful starting point:

PTP metrics should be read together with RTP metrics. For example, if PTP offset rises, RTP jitter increases, and receiver buffer level starts oscillating at the same time, the issue should be treated as systemic.

19. Quick PTP checks with Wireshark

Wireshark remains one of the first tools to use in the field.

1
2
3
4
5
6

ptp
ptp.v2
ptp.v2.messageid == 0x0    # Sync
ptp.v2.messageid == 0x8    # Follow_Up
ptp.v2.messageid == 0xb    # Announce
ptp.v2.domainNumber == 127 # example domain check

Things to check:

• Are Announce messages arriving regularly?
• Is there an unexpected second grandmaster on the same network?
• Is the domain number correct?
• Does the source MAC/vendor match the expected GM or boundary clock?
• Are Sync and Follow_Up messages arriving at the expected interval?

Wireshark will not solve every PTP issue, but it quickly exposes wrong domains, unexpected grandmasters, missing announce messages, and VLAN/QoS mistakes.

20. Common failure scenarios

This section is more useful when read as a field playbook: problem, evidence, and mitigation. PTP problems are rarely solved with a single log line; PTP, RTP, switch telemetry, and receiver state should be evaluated together.

Practical order:

1. First verify GM identity, domain, and clock class.
2. Then check endpoint offset, mean path delay, and servo state.
3. Next inspect RTP sequence, packet pacing, and receiver buffer behavior.
4. Finally go deeper into switch QoS, boundary/transparent clock behavior, and host tuning.

21. Where to be careful in PTP design

Do not treat PTP as separate from the media network. PTP packets are small, but their impact is large. QoS, VLANs, switch queues, and boundary clock behavior can directly affect media quality.

Be explicit when a device has multiple time sources. If GNSS, black burst, PTP, NTP, and internal clock all exist on the same device, the selected reference must be unambiguous.

Do not trust vendor defaults. Domain, priority, announce interval, and profile values may differ by device.

Monitor both paths in A/B redundancy. ST 2022-7 may protect media paths, but if time reference behavior is asymmetric, failover can still surprise you.

Host tuning matters for software-based ST 2110. Even with correct PTP, CPU jitter, NIC queues, IRQ affinity, NUMA placement, and driver settings can affect sender/receiver behavior.

22. PTP and NMOS relationship

NMOS discovers devices, describes resources, and manages connections. PTP provides the time reference. They do not solve the same problem.

A receiver may connect to the correct sender through NMOS, receive the correct SDP, and join multicast successfully; if PTP is wrong, media can still behave incorrectly. In ST 2110 troubleshooting, “NMOS connection is complete” is not the end of the investigation.

23. Conclusion

In ST 2110 systems, PTP is not a helper service. It is the timing layer of the media fabric. Without SMPTE ST 2059, ST 2110 streams can still be packetized, but expecting reliable, synchronized, broadcast-grade behavior is not realistic.

A solid ST 2110 design should treat PTP like this:

• grandmaster and backup grandmaster plans must be explicit
• BMCA behavior must be tested
• switch boundary/transparent clock roles must be understood
• endpoints must be verified against the same ST 2059-2 profile and domain
• PTP offset, GM identity, and servo state must be continuously monitored
• failover, cable pull, and restart scenarios must be tested with real media flows

In short: RTP carries the picture, ST 2110-30 carries the sound, ST 2110-40 carries ANC; but time is what makes them part of the same broadcast. That time is provided by PTP and SMPTE ST 2059.

PTP golden rules

References

• SMPTE ST 2110 Standards
• SMPTE ST 2059-2:2021
• SMPTE EG 2059-10:2023
• linuxptp documentation: ptp4l
• linuxptp documentation: phc2sys
• Wireshark RTP Analysis
• Related article: ST 2110 Television Campus Overview
• Related article: Monitoring SMPTE ST 2110 Systems
• Related article: Intel Media Transport Library for ST 2110