Artel's lessons learned Part 2: Optimal Handling of PTP

The first blog in this “lessons learned” series took a close look at how important it is to use a PTP-aware switch when implementing IP-based media workflows. In this second installment, we’ll focus more on IEEE 1588 Precision Time Protocol (PTP) itself and how to handle PTP configuration and data correctly.

Accurate timing is critical to IP video/audio signal transport using SMPTE ST 2110 and AES67. Enabling synchronization of devices, including timing servers and clients, to one shared clock across packet-based networks, PTP provides a stable timebase for signals across a media operation or workflow and supports use of time code to align different media sources.

Set Consistent PTP Profiles and BMCA Settings
All devices that could potentially become the PTP timing server must execute a common Best Master Clock Algorithm (defined in IEEE 1588) to identify the best choice. Once a particular clock is selected, all other potential clocks receive timing from it. If something happens on the network that bumps that preferred or best clock, and it’s no longer available, then the next best clock on the network automatically becomes the reference.

Every clock on the network, whether a boundary clock or end device (client), has a user-provisioned priority field that defines their place in the hierarchy. The lower the number, the higher the priority, with high priority indicating that a particular clock is the best one to use and low priority essentially saying, “Don’t use this clock.” If two or more clocks share the same high priority value, then other criteria related to clock quality are compared to determine which clock should be selected as the PTP reference.

To keep this model running smoothly, it’s important to set consistent PTP profiles as you provision variables for each element participating on the PTP network. Because different industries have different PTP profiles for the different variables, you want to make sure that all the elements have the same profile — that they are all speaking the same language — and that the same (and correct) selection criteria are applied across all clocks so that every endpoint (client) will shift to the appropriate common source for PTP clock signals in the event of an interruption.

Leverage Your PTP Hierarchy Correctly
While both boundary and transparent clocks deliver the signal from the timing server to various clients, or end devices, the two generally serve different purposes.

Transparent clocks are easy to use. They simply allow PTP packets to flow through a device, adding a correction factor to each packet to account for the time it took the packet to flow through the device. With this information, the destination device can calculate the network delay and determine an accurate PTP time.

For small or mid-sized networks with only a handful of devices, a transparent clock is likely sufficient. For larger, more complex networks, a mix of transparent and boundary clocks helps to manage the larger PTP message load effectively. (More endpoints = more PTP messages.)

Because a boundary clock can act as a client device to an upstream PTP timing server and as a timing server for downstream clients/devices, it can be used to take some of the load off of that upstream timing server. The output of the upstream timing server thus can be shared with multiple downstream devices, preventing constant timing requests from various clients from causing an overload.

You can use boundary clocks to partition traffic — to create boundaries that not only keep the flows of PTP messages manageable, but also prevent an error on one endpoint from propagating and causing havoc across the network. It’s an extreme case, but not impossible, and could result from a simple mistake that causes an overload on the timing server, or a more malicious denial of service attack. In either case, you can use boundary clocks to contain this kind of threat and add a layer of security to the network.

Correlate Clock Accuracy to the Applications
When everything is going well, you can trace timing through the PTP timing server, which presumably has a very good clock, all the way to the ultimate reference, an atomic clock. But sometimes things go wrong, and there is a break in the timing chain. At this point, your switch goes into holdover, capturing the latest and most accurate timing data and maintaining it as long as possible.

To prepare for this moment, you need to know what your endpoints can handle in terms of drift, which inevitably will occur when clocks are no longer traceable through a GPS or similar time source. Depending on the quality of crystal used in your clock, the rate of drift will be slower or faster. High-quality crystal is costly, and so vendors have to make a choice about cost of performance and correlation to a particular application. You too have to make a choice about the level of performance — and clock accuracy — required for your application and the endpoints across your network.

Other Timing Reference Options
PTP messages are just one source of timing information. While they are less common, there are other ways to communicate this data. Physical connections, for example, can carry timing in a different form, such as a waveform. Depending on the industry and application, you may find that you’re working with endpoints or other devices that don’t know about PTP. In this case, you want to be sure that you have the means to synchronize with other timing reference modes.

Full Support for IEEE 1588
It’s always good to know that your systems support all the variables are specified in key industry standards and specifications, and in the broadcast realm, IEEE 1588 is one of those specifications. You’ll likely need to be connecting end points that come from different vendors, each with their own interpretation of PTP and how to work with it. Full support for IEEE 1588 will ensure that you have the flexibility to accommodate deviations that might still be within the specification. With robust support for PTP, you can be confident that every aspect of PTP-based synchronization translates well across your network and devices.

Summary
These are some of the top lessons learned by Artel engineers in building IP-based solutions for our customers, in supporting deployments in IP environments, and in responding to evolving customer requirements as they extend their use of IP networks for media transport. If you have questions about working with PTP in your own operations, just give us a shout. We’d love to help!

• Share: