By Andrew Starks, Director of Product Management at Macnica Americas, Inc.

PTP, short for Precision Time Protocol, is one of the most misunderstood parts of modern media systems. It’s also one of the most important. In various unseen parts of your daily life, PTP keeps the world in sync: from the ability to move down the highway and seamlessly use a series of cell towers without interruption, to trading stocks to managing the power grid. PTP is critical. In IP-based media systems like ST 2110 and IPMX, it plays a similar role by providing a shared reference clock that keeps video, audio, and data locked together, even when they’re flying through a best-effort IP network in separate streams. Maybe you’ve heard it’s difficult. Maybe you’re using Dante and wondering if it’s about like that. Maybe you just want to survive your next meeting with the consultant. This article won’t make you a timing expert, but it will help you understand what PTP does, when it matters, and how to make smarter decisions as you move to AV over IP.

PTP (defined in IEEE 1588) distributes a shared timebase across your network, so every device knows exactly what time it is, down to microseconds or even nanoseconds. That sounds abstract, but in an AV system, it means this:

• Audio and video from the same event can stay in sync, even if they’re sent as separate streams.

• Receivers know exactly when to play out a packet - even if it arrived early or late.

• Systems can switch cleanly between two sources (like stream A to stream B) without a glitch, because both sources are locked to the same master clock and aligned in time.

When a device is locked to a clock, it means its internal oscillator is constantly being adjusted to stay in step with the master reference. Not just matching it once, but following it over time, like marching in formation with the beat, not just hearing it once at the start. When two streams are aligned, they’re not just running at the same speed, they’re also synchronized to the same timeline. So if frame 1000 of Stream A hits at 12:00:01.000, frame 1000 of Stream B does too. That’s what makes seamless switching possible. If your system doesn’t support this kind of timing, you’re not necessarily in trouble but you do need to plan around it. In some cases, receivers may need to re-align content using buffers or internal delay to compensate for sources that are timed to their own internal media clock. That could add complexity, cost, or latency. In other cases, PTP may be completely unnecessary. For example, if you’re connecting a laptop to a projector or sending a looped video to monitors in a sports bar, none of that timing precision really matters. Even in live-to-streaming production systems with multiple sources, the tradeoff of accepting a bit of latency and resampling in exchange for a simpler network might be worth it. In live production scenarios, like IMAG, synchronized AV playback, or seamless switching between sources - lock and alignment are essential. If your system includes synthetic sources like media players or file servers, PTP becomes even more important. Without a shared clock, those devices will drift over time, even if they started out perfectly in sync.

Before you commit to adding (or avoiding) PTP, ask yourself:

1. Are you building an ST 2110 or AES67 system?

If yes, you need PTP. It’s required.

2. Are you building an IPMX system?

PTP is optional but recommended if you want to synchronize multiple devices, switch seamlessly between sources, or align streams across the network. It gives you a shared clock and a consistent timeline to work from.

3. Do you need lip sync or AV synchronization between devices?

PTP helps ensure tight alignment between audio and video, even if your sources aren’t already in sync or aligned. Many IPMX devices use PTP timestamps (via RTCP sender reports) to re-align mismatched content locally. But remember that every time you correct for misalignment, you’re adding latency and touching the content.

4. Are you switching between live sources (e.g. cameras or feeds)?

Clean switching requires that the sources are time-aligned. Without PTP, there is usually a duplicate frame that needs to be inserted and it adds at least one or two frames of latency to your system.

5. Do you need multiple displays or speakers to stay in sync?

For video walls, multi-zone audio, or large-scale installations, PTP helps ensure content hits all outputs at the same time.

6. Are you working with file-based playout or other synthetic sources?

Without a shared clock, these devices will run slightly “off-speed." Over time, these sources will drift.

7. Is your system simple (like signage, conferencing, or one-to-one AV)?

You may not need PTP. If your system isn’t sensitive to small timing errors, local buffering may be enough.

In IPMX systems, RTCP Sender Reports give receivers timing context for incoming media, especially when PTP isn’t available.

Each report includes:

• An NTP-format timestamp (from the sender’s internal or PTP-synced clock)
• An RTP media timestamp (based on the media rate)

This lets receivers:

• Align media from the same sender, even without a shared clock
• Start playback intelligently, even mid-stream

Without PTP, you can’t align streams from different senders because each uses its own clock. With PTP, timestamps across senders are meaningful and can be aligned. ST 2110 doesn’t use RTCP; it relies entirely on PTP and the assumption that everything is in sync and aligned. In IPMX, RTCP is always present and useful for local alignment, even without a shared clock.

At a high level, PTP is just a way for all the devices on your network to agree on what time it is and to keep that agreement very precise, even as devices warm up or conditions on the network change. In a PTP-enabled network, one device becomes the grandmaster clock. Every other device adjusts its internal timing to match that grandmaster. This process happens continuously: devices monitor how far off they are and apply corrections as needed. This is what allows separate devices (cameras, encoders, displays) to stay perfectly aligned in time, even if they’re only connected through the network.

PTP uses multicast messages to distribute time. Devices don’t just copy the grandmaster’s time directly; they measure how long it takes for that timing message to arrive, and adjust accordingly.

This is done using a three (sometimes four) step exchange:

1. The grandmaster says, “Here’s what time it was when I sent this (often this is a two-step process)."
2. The device replies, “Here’s what time I received it and here is the time of my delay request.”
3. The grandmaster replies, “Okay, here is when I received your delay request”

Using that exchange, both sides calculate the network delay and the device adjusts its clock accordingly. Here’s the catch: for PTP to work well, those timestamps must be extremely accurate, which requires measurement and insertion at precisely the right moment. That’s easy to say, but hard to do, especially in a software-based system. Operating systems introduce jitter. Network stacks add unpredictable delays. Even small fluctuations in interrupt timing or CPU load can throw off the microsecond-level accuracy that ST 2110 demands. That’s why many systems rely on hardware-based timestamping, where the packet is stamped at the exact moment it hits the wire. At Macnica, we built the MEP100 SmartNIC to handle this kind of job. It’s a purpose-built IO card that captures and transmits media streams with hardware-accurate PTP timestamping, along with support for up to 8 UHD or 32 1080p uncompressed flows, full ST 2110 compliance, and direct support for popular frameworks, including GStreamer and FFMpeg integration. If you’re trying to do real-time media over IP and your timing isn’t stable, everything else suffers. The accuracy of your timestamps is the accuracy of your system.

This all assumes that the path from the grandmaster to the device is the same as the path back. If the timing packet takes 100 microseconds to get there and 100 microseconds to get back, no problem. However, if the “there” path takes 80 microseconds and the “back” path takes 120, the device calculates the wrong delay, and that introduces a timing error. This is called path delay asymmetry, and it’s one of the most common and frustrating PTP problems. Even small errors can introduce timing issues or prevent switching cleanly between two streams.

PTP works best when the network helps out. Higher-end switches often include features that make them “PTP-aware,” meaning they actively support accurate time distribution across the network. The two most common features are:

• Transparent Clocks: These switches measure how long a PTP packet spent inside the switch and adjust its timestamp accordingly, helping eliminate delay-related errors.

• Boundary Clocks: These switches act as local timekeepers. Each port becomes a source of time for downstream devices, reducing the load on the grandmaster and improving overall stability.

Both features help maintain timing accuracy, especially in multi-switch environments where delay asymmetry can throw off synchronization. That said, many lower-cost switches don’t support either mode. They simply forward PTP packets without adjustment. That doesn’t make them unusable, especially in smaller or single-switch systems, but it does mean you need to design carefully. In ST 2110, the timing requirements are strict enough that PTP-aware switches are usually considered essential. In IPMX, the bar is lower: PTP traffic is lighter, accuracy requirements are more forgiving, and many systems can function well with non-aware switches as long as the design accounts for it. However, if you need broadcast-level performance, then even in IPMX, you’ll need PTP-aware switches.

Even with the right switches, the layout of your network can affect how well PTP performs.

• Single-switch systems are usually the most forgiving. PTP packets have only one hop, and delay is easy to manage, particularly if all devices are on the same VLAN, minimizing risk of multicast or routing issues.

• Dual-switch (ST 2022-7 redundancy) systems can also work well, but both switches need to forward PTP correctly and maintain similar latency. It helps if they’re the same model, with identical configurations.

• Multi-switch systems, especially with long or asymmetric paths, introduce more variables. Delay compensation becomes harder, and the risk of asymmetric timing errors grows, unless you’re using PTP-aware switches with proper design.

• Some integrators favor large core switches with breakout modules. This creates a single logical switch with lots of ports, reducing complexity while maintaining central control of PTP timing.

The more complex the topology, the more critical it is to model, test, and monitor PTP behavior. In large systems, it’s common to simulate PTP performance before deployment using tools or lab setups, especially when mixing technologies like Dante, ST 2110, and IPMX.

Even experienced teams can have issues with PTP. Here are some of the most common mistakes, and how to avoid them:

1. Multiple Grandmasters (and no one knows)

By default, many devices are capable of becoming a grandmaster. If no one sets them to slave-only mode (sometimes referred to as “follower-only”), you may accidentally create a “PTP election” and get inconsistent time across the system. In IPMX, devices default to follower mode but always double-check. For ST 2110, explicitly assign your grandmaster and set everything else to slave-only unless you’ve planned for redundancy.

2. PTP Packets Getting Filtered or Rate-Limited

PTP relies on multicast traffic, and some lower-cost switches, especially unmanaged or lightly managed ones, may block, filter, or rate-limit multicast by default to prevent network flooding. Make sure your switches are configured to allow multicast on the correct address (usually 224.0.1.129) and port (UDP 319/320). Disable any filtering features like storm control or IGMP snooping on that address unless you know what they’re doing.

3. Mixing PTP Domains Without Isolation

Dante, ST 2110, and IPMX all use PTP but not the same version or profile by default. Dante uses PTPv1 (IEEE 1588-2002), while ST 2110 and IPMX use PTPv2 (IEEE 1588-2008 with ST 2059-2 profile). Keep incompatible PTP systems (like Dante and ST 2110) on separate domains or VLANs. Some enterprise Dante systems can be configured to follow a PTPv2 clock using Dante Domain Manager but this requires the right hardware, licensing, and setup. IPMX and ST 2110 can safely share a PTP domain, as long as the grandmaster meets the precision and stability requirements of ST 2110.

4. Assuming One-Way Delay Is Good Enough

PTP assumes the path to and from the grandmaster is symmetrical. In reality, asymmetric paths, due to topology or inconsistent switch behavior, can lead to inaccurate timing, even if the network looks healthy. Avoid daisy-chaining switches unless they’re PTP-aware. When possible, keep timing-critical devices as close to the grandmaster as you can, both physically and logically.

5. Deploying Without Monitoring

PTP can fail silently. You won’t get an error message, just a glitch at random times that seems impossible to track down. Plan ahead for monitoring. Some devices report offset from the master; others show which clock they’re using. At minimum, build a test plan that confirms expected behavior before going live.

Want to go deeper? These resources can help solidify your timing knowledge and support your next AV-over-IP deployment.

1. VSF TR-10-1:2024 - IPMX System Timing

Describes how timing works in IPMX systems, including support for networks with and without PTP. videoservicesforum.org

2. SMPTE ST 2059-2:2021 - Use of IEEE 1588 in Broadcast

The PTP profile used by ST 2110 and IPMX systems. Available via smpte.org

3. SMPTE ST 2110-10 - System Timing

Core timing spec for ST 2110-based media networks.

4. “Your Top 10 PTP Questions Answered” - Leader/Phabrix

 A readable, practical Q&A for people new to PTP in media. leaderphabrix.com

5. Audinate Dante and PTP Compatibility FAQ

Explains how Dante handles timing, and when it can (or can’t) work with PTPv2. audinate.com

Does anybody really know what time it is? If you’ve made it this far, the answer is: you do now. You know what PTP is, how it works, when you need it, and what can go wrong if you ignore it. You know why it drives network design, and how IPMX and ST 2110 approach timing differently. You even know what an RTCP sender report is, and that’s more than most people can say. Of course, this begs the question: Does anybody really care? If you’re building AV over IP systems, then the answer is yes. Maybe not because you love timing protocols, but because understanding them takes the guesswork out of deciding the path forward for your next upgrade. Making the right choices might keep your video clean, your audio in sync, your switches crisp, and your team out of trouble.

If PTP timing is critical to your next ST 2110 or IPMX project, don’t leave it to guesswork. Plan your timing architecture early, validate it thoroughly, and choose tools built for microsecond-accurate synchronization. Macnica’s MEP100 SmartNIC was designed for exactly this challenge - delivering hardware-based PTP timestamping, full ST 2110 compliance, and seamless integration into real-time AV-over-IP workflows. Talk to Macnica today to see how we can help you keep every frame and every packet exactly where and when it should be.