Audio Networks and Switching Your Way to PTPv2 Support
Audio networks are hardly new, with a huge increase in the number of projects using audio networks over the past few years. Besides the various solutions (like Dante, RAVENNA, etc.), which have made this possible, there are a number of protocols working under the surface too. One of these is IEEE 1588 (otherwise known as PTP or Precision Time Protocol), one of the protocols that underpins many of the various audio (and video) networking standards.
As with most digital systems, timing and synchronization play a key part in keeping things working smoothly. Essentially, anything that can help achieve better timing in any digital system is a good thing to learn more about. Let’s take a closer look at some of the details, with some useful information on this protocol and some of the differences in what’s out there.
What is PTP?
Precision Time Protocol, the friendly name of IEEE standard 1588, was first published in 2002. It defines a protocol for messages devices can send to each other in order to synchronize their clocks throughout a network. The most recent publication of the standard achieves high accuracy timing to end devices through a combination of hardware time-stamping of packets and accumulated delay calculations. When we say accuracy, we are talking about sub-microsecond figures. This makes PTP extremely suitable for applications in audio and video networks.
Since 2002, a revision to the standard (IEEE 1588-20081) has been published which takes us to PTPv2. This update improves robustness, precision and accuracy, but it is not backwards-compatible with the 2002 standard; this is the first “gotcha” to keep in mind. PTPv2 brings more resolution to the timing fabric of our real-time networks. It’s an advanced timing technology, which represents the future direction of accurate time synchronization across all industries.
Some PTPv2 Terminology
As with most technology, it can be helpful to be familiar with a certain amount of nomenclature. Because PTPv2 deals with timing and sync, many of the terms make reference to clocks of some kind. In fact, any device that contains a PTPv2 clock can simply be considered a clock at the most basic level.
The next distinction is between network and terminal devices. Network Devices are generally considered to be pieces of equipment that make up the underlying fabric of the network (i.e., switches, routers, etc.). These are referred to as Boundary Clocks. Pieces of audio/video gear, DAWs, etc. (our endpoints) are more likely to be Terminal Devices and are known as Ordinary Clocks.
Dante uses the original PTP and works fine. Why should I worry about PTPv2?
A few years ago, you might have found that various audio networking solutions each used different versions of PTP. Dante and Q-LAN used the original Version 1, while Ravenna (ravenna-network.com), which is widely used in the broadcast and studio world, uses Version 2.
With Dante systems, PTPv1 is used to synchronize clocks of all the audio device endpoints. This is an automatic process where a Grand Master is elected (based on your preferred master settings, for example) and then the slave devices receive the clock sync messages.
In order to give PTP some priority on the network (as it travels through the switches connecting your devices), Dante uses Quality of Service (QoS) markings to designate PTP messages as having the highest priority (i.e., Don’t send me the audio and control network packets if I haven’t received the clock yet). That said, the clock precision can still be affected by the volume of traffic and how much contention there is for priority. PTP clock messages can get stuck and delayed in the backbone; in the switches between your devices. (Or “hops,” as many people call it).
As previously mentioned, v2 is not backwards-compatible with v1. When the AES67 interoperability standard was published, it mandated the use of PTPv2. As more manufacturers bring AES67 interoperability and support to their products, they have harmonized their PTP implementations or included other mechanisms in order to adhere to the standard. As an example, QSC Q-LAN updated to PTPv2 approximately two years ago.
At the very least, Dante devices currently support PTPv1; those manufacturers that released AES67-enabled Dante devices support both versions, and many non-Dante AES67 devices support v2 only. You might be wondering how it’s possible for a Dante network using PTPv1 to exchange AES67 streams with devices using PTPv2. In that scenario, one AES67-enabled Dante device needs to act as the Boundary Clock, bridging the PTPv1 and PTPv2 clock domains.
As shown in Fig. 1, we end up with two clock domains (two audio clock territories, Dante and AES67) that will be created across the different devices.
There are a number of different strategies to enable clock distribution in this scenario, and care must be taken when configuring the various settings for “Preferred Master,” “Sync to External” and other intricacies.
Who Gets to Be Master?
In a PTPv2 network, one clock is elected as the Grandmaster. The Grandmaster is the clock from which all other clocks will derive their time; this is similar to a master clock that distributes Word Clock in a digital audio setup.
When a PTPv2 capable device powers up, it starts in the “listen” state, where it listens for PTPv2 announce messages on the network segment it’s connected to. If no messages arrive after a predetermined length of time (the Announce Timeout Interval), the device acts as a master. If upon startup, an announce message arrives, the device concludes that there is already a master present and it will behave as a slave, provided that its own clock is not of a superior quality to that of the master’s.
This process is known as the Best Master Clock Algorithm (BMCA). It is also possible to rig the election and stipulate which device should be the master; for example, the “Preferred Master” in a Dante/AES67 system, which acts as the boundary clock for both domains. Fig. 2 illustrates a simplified cycle of the BMCA.
How is PTPv2 So Accurate?
Part of what makes PTPv2 so accurate is that it uses hardware to solve some of the timing jitter that is encountered as packets move around the network and through different devices. All network devices take some measure of time to process and can slow the bits flowing through them, in much the same way that latency is introduced in an audio path due to A/D conversion.
Knowing the duration of this “residence time” and correcting for it enables the synchronization to be that much tighter. By virtue of special hardware, timestamps are generated from a device’s local clock, which are used in the messages that PTPv2 exchanges. Devices can work out not only the time required for messages to arrive, but also update their time — or that of messages they send — to compensate for the delays experienced by packets as they are processed internally.
As shown in Fig. 3, PTPv2 uses a series of messages to synchronize the time between clocks. The master clock sends a Sync message to the slave clock and makes a note of the timestamp t1 as the message leaves. When the slave clock receives this message, it too makes a note of when it arrived, t2. The master clock also sends a Follow_Up message to the slave that contains the value it noted for t1. The slave sends a Delay_Req message to the master and makes a note of when it was sent, t3. When the master gets this message, it makes a note of the time it was received, t4, and sends that value back to the slave in a Delay_Resp message. The slave clock now possesses all four timestamps that can be used to compute the offset of the slave clock relative to the master, and the propagation time between the two clocks.
Switches and PTPv2
To have the best synchronization in our network, it’s helpful if the switches (and routers) passing our audio data understand PTPv2 — and not just the end devices. This is not to say that a network using AES67 requires special switches. It is perfectly possible to deploy an audio network using switches that don’t speak PTPv2. However, in certain scenarios, or in mixed applications, this may be a requirement in order to avoid problems.
“PTPv2 in switches can also ensure that sync packets, which could have similar priority or higher than streaming data (Dante vs. AES67), will still be correct when delayed by queuing,” explains Hugo Larin from Luminex Network Intelligence. “This could be the case as well from sudden surge of network traffic. Timestamping makes the corrections accurate and thus keeps the jitter low. So no QoS conflicts.”
PTPv2 support in network devices is not yet something that is included in all units. Although not difficult to find, typically this tends to be confined to specialist equipment geared towards media, industrial applications or to higher specification models for use in the traditional IT space.
PTPv2 switches undoubtedly contribute to making the synchronization in our networks better. The point at which you choose to deploy them often comes down to the intended application and how much sync variance can be tolerated. If an application requires a lower level of accuracy that can be achieved without PTPv2 switches, then non-PTP will be fine. If too much clock error is experienced, then PTPv2 switches may be a part of the solution. I say “may be a part” because the performance of the switches is just one aspect of the sync situation. The resulting clock sync accuracy also has a lot to do with how well the PTPv2 algorithms are implemented in all the other various devices — not just the switches.
“In audio applications, PTPv2 support on end devices may be sufficient to maintain synchronization as packets traverse the network from device to device,” Larin continues. “That said, this all depends on the amount of jitter allowed by the end device or the number of hops used (which will make increase jitter). Other situations — like video — demand even tighter degrees of synchronization as the applications attempt to sync down to tens of nanoseconds. In these cases, having PTPv2 support on intermediary devices (such as switches) makes the requirement even greater.”
PTP Profiles
With PTPv2, the concept of “profiles” was introduced. Profiles allow standards bodies (such as the AES and SMPTE) to adapt the PTPv2 implementation to fit a particular application. A profile defines which aspects of PTPv2 are included or excluded and configurable ranges and defaults for the application.
PTPv2 includes a default profile, and there are a few other profiles relevant to networked audio and video, the main ones being:
• The Media profile of AES67
• The SMPTE profile of SMPTE ST 2059-2
This is an area where particular attention needs to be paid in order to ensure interoperability between devices that conform to different profiles. Detailed information on the recommended parameter choices for AES and SMPTE interoperability can be found in the AES document AES-R16-20162 (aes.org).
The IEEE 802.1AS3 (gPTP) standard qualifies as a PTPv2 profile specific to AVB implementations. It simplifies PTPv2 and defines synchronization over other media besides Ethernet.
According to Larin, “PTPv2 and its profiles bring time sensitivity to our real time A/V networks. It is interesting to see a common theme here whereby AVB, AES67, Q-LAN and others are relying on this mechanism for providing high accuracy.”
Table 1 shows a selection of switches that include PTPv2 support. It is by no means an exhaustive list, and many of the manufacturers have more than one model available that supports PTPv2. Interestingly, of the switches shown, it is only the models offered by Luminex which are ruggedized to some degree with Neutrik’s etherCON and opticalCON connectors for use in more demanding production environments. Yamaha recently introduced a similar switch, yet it does not support PTPv2, so it not included here.
There can be a wide range in price difference between various vendors, but one thing is clear: switches that support PTPv2 are not cheap; certainly not when compared to the likes of the popular Cisco SG300 that is found in many racks these days. Of course, the extra premium pays for plenty of additional features and performance enhancements besides PTPv2, so the comparison is a little unfair. It does, however, go back to the point that one must assess the requirement for PTPv2 support on the switch to determine at what point the extra cost is justified.
PTPv2 support is not usually something that can be added to a switch by means of a firmware upgrade, so it might be worth considering how likely or soon a network might benefit from PTPv2 support as different applications are placed on it. It may be better to invest sooner in the extra capacity and functionality of the higher spec’d gear rather than have to replace and upgrade later on.
I believe it’s also too soon to say how some switches that were intended for enterprise top-of-rack situations will fare with life on the road, or even a more heavy-duty cycle of plugging and re-plugging. It’s quite an investment to be trashed if the rigors of production environments prove to be too demanding. This is an area where perhaps the likes of the Luminex products and others, which are similarly ruggedized, might be better suited. (See Fig. 4.)
“Luminex Network Intelligence has been involved in configuring and validating PTPv2 support for different audio over IP solutions including AES67 with industry specialists such as Ravenna,” Larin adds. “For over a year, our GigaCore family of switches have been shipping preconfigured and validated with PTPv2 support out of the box. These switches use hardware timestamping for the forwarding time measurements with a divergence of only +/- 20ns.”
Beyond PTPv2… PTPv3?
The current version of the standard has been with us since 2008, but there is a working group currently discussing a revision to the standard, due for completion towards the end of the year. Could it be that any future revision renders current equipment incompatible and further upgrades/workarounds would then be needed to maintain usability?
The working group’s website strongly urges participation from organizations implementing IEEE 1588. Hopefully, members from the audio and video community are already involved as industries such as: industrial automation, robotics, test and measurement, etc. are listed while broadcast and media receive no mention.
No matter what developments occur within the networked audio and video space, one thing is certain. With the increasing size of our networks, the requirements for high accuracy and for smart, redundant systems means that timing is critical. Protocols like PTPv2 or something newer, better, more accurate will be there in the background making sure that we’re all on the same page, frame or sample.
The author would like to thank Hugo Larin of Luminex Network Intelligence, and Andreas Hildebrand from ALC NetworX for their input and assistance with this article.
