What "locked" actually means
A PTP slave is locked when two numbers stay small and stable: the offset from master, the difference between its clock and the grandmaster's, and the mean path delay, its estimate of how long a message takes to travel one way. Both are calculated from timestamps in the Sync, Follow_Up, Delay_Req and Delay_Resp exchange shown above.
The offset calculation assumes the path is symmetric: that a packet takes as long going one way as the other. That assumption is what most real-world PTP problems quietly violate.
Reading the symptoms
Offset swings by microseconds, path delay is stable
Something between the endpoint and the master is queueing PTP packets behind other traffic. A switch that forwards PTP as ordinary multicast rather than acting as a boundary or transparent clock produces exactly this. The fix is configuration, not tuning: the switch must be in the timing path, not merely on it.
Path delay jumps when a redundant link changes state
In a ST 2022-7 plant the two paths rarely have identical lengths and identical switch hops. A failover moves the timing reference onto a path with a different delay, and the slave spends the next seconds re-converging. Watching path delay per interface, rather than a single aggregate number, is what separates this from a grandmaster problem.
Everything is stable, but the receiver still refuses the stream
Check the domain number and the profile before anything else. SMPTE ST 2059-2 devices are often deployed on a non-default domain, and a device listening on the wrong domain will sit there perfectly locked to nothing at all. A mismatch in message rates or in the announce timeout can produce the same silence.
The grandmaster identity keeps changing
Two masters are competing. The Best Master Clock Algorithm is deciding repeatedly, often because a device with a poor clock class is allowed to participate, or because a GNSS antenna loses fix and hands over, then takes over again when it recovers. The history of grandmaster identity over time tells you which device is unstable; the instantaneous view does not.
Software timestamps lie. A PTP reading taken in userspace includes whatever the operating system's scheduler did between the packet arriving and the software looking at it. On a busy Windows machine that is easily tens of microseconds of noise, which is the same order as the errors you are hunting. Hardware timestamping in the NIC is what makes the numbers trustworthy.
How PTP failure shows up in ST 2110
ST 2110 senders stamp each RTP packet with a timestamp derived from the PTP-disciplined clock, and receivers use those timestamps to reassemble and align essences. When timing drifts, the visible results are not timing errors:
- Video and audio drift apart slowly, because ST 2110-20 and ST 2110-30 are separate streams aligned only by their timestamps.
- A receiver reports buffer underruns or overruns, since packets arrive earlier or later than their stated presentation time.
- Frames repeat or drop at a regular interval as the receiver resynchronises.
- ANC data in ST 2110-40 lands on the wrong frame, which is where subtitles and timecode start looking haunted.
That is why comparing a stream's RTP timestamps against the local PTP clock is more informative than either number alone: it shows whether the sender's clock, the network, or your own receiver is the one that is off.
A working order of checks
- Confirm the domain and profile match on every device involved — this eliminates the most common cause in minutes.
- Identify the current grandmaster and check whether it has changed recently.
- Read offset and path delay over a period of minutes, not as a snapshot; stability matters more than the absolute value.
- Check whether each switch in the path is a boundary or transparent clock, and whether PTP is enabled on the specific ports in use.
- Compare the two redundant paths separately before trusting any aggregate number.
- Only then look at the endpoint's own configuration, which is where most people start.