Video: PTP in WAN Applications & Update on PTP v2.1

PTP is evolving as is our ability to use it over WANs. This video explains what’s new in PTP’s second revision and the evolving techniques of using PTP over a wide area network such as the internet. As PTP was built assuming the use of LANs, the longer and more unpredictable latency of WANs throws off the timing calculations, so what can be done to compensate?

In this video from RAVENNA, Andreas Hildebrand from ALC Networx takes us through PTP 2.1, the 2019 revision of PTP following on from PTP 2.0 in 2008 and from the original 1.0 in 2002. Famously, 2.0 and 1.0 were not compatible with each other which has caused problems with some hardware implementations of DANTE which were first written when 1.0 was the only edition. Importantly, Andreas highlights, version 2.1 is backwards compatible with version 2.0. If you’re looking for a PTP primer before digging in, have a look at this intro video from Daniel Boldt, Meinberg

Andreas explains the use of PTP profiles within both AES67 and SMTPTE 2110 which standardise some of the parameters for using PTP such as message frequency. Whilst they do have different defaults, there is an overlap between the two allowing for use of AES67 streams withing both an AES67 ecosystem and with a 2110-30 ecosystem. These overlaps are detailed in the joint AES and SMPTE document, AES-R16-2016.

“What’s new in PTP v2.1?” asks Andreas. Apart from clearer language, accuracy, flexibility and robustness have been enhanced.

Flexibility comes from the ability to mixed multicast and unicast messages. Announce and sync messages are still sent in multicast, but queries like delayresponse & delayrequest can now be sent unicast which provides better scalability as, for many scenarios, the reply never needs to go back to any other computers. Another example of flexibility is modular transparent clocks i.e. ones in SFPs. Another flexibility improvement is that it’s now possible to isolate profiles without using different PTP domain numbers. This is by adding a Profile ID called ‘SdoId’.

Robustness and Security
PTP now allows inter-domain interactions effectively allowing multiple GMs to vote onto a single ‘multi-domain clock’. This becomes a very robust clock as it’s created from the insight of three grandmasters. PTP v2.1 adds source integrity checking to allow identification of false, injected, messages. A long-needed improvement as security, even of a LAN, can’t be assumed nowadays.

Performance and Accuracy
Stats reporting has been added to PTP v2.1 allowing monitoring of the average, minimum, max and standard deviation of a number of metrics from the leader clock, delay metrics and message reception counters. Accuracy has been boosted to sub-nanosecond by the CERN-related White Rabbit Project which is an overall benefit to PTP even if sub-nanosecond timing isn’t needed.

Source: ALC NetworX

The second part of the video features Meinberg’s Daniel Boldt who discusses how to transmit PTP over the WAN. This is more challenging than a WAN because it’s more likely to be affected by queueing delays – particularly if the WAN in question is the internet. Queueing delays happen for a number of reasons but it all boils down to the fact the switches and routers often have to hold packets in a buffer, something that tends to happen more when there is more load. As such, this means that the delay is variable leading to varying jitter on the measurements.

Another problem often encountered is path changes where a switch happens in the network to divert the signal to a different path. Whilst this is a great way to route around problems, it does mean a sudden change in path length and therefore propagation delay. A conventional ping time may change from 100ms to 250ms in a second. This could have a big impact on the accuracy of a PTP timing signal if undetected.

Finally, the PTP timing algorithm assumes that it takes just as long, and no longer, to get the timing information from A to B as it does to get the follow-up reply from B to A. When one direction takes longer than the other, for instance when one direction is forced through a 100Mbps link rather than 1000Mbps, the PTP timing will have a constant timing error.

Source: Meinberg

Daniel explains that these issues can be mitigated by more thorough processing of the incoming packets. For instance, having a high-quality oscillator which can maintain an accurate frequency for a long time without external input is helpful. Having a local GM on GPS is another good way to avoid problems, in the cases when this is practical, where the WAN PTP becomes an ‘aide’ to timing rather than the authority. Finally, the ‘lucky packets’ technique is demonstrated.

Daniel explains that if you look at the delay of each packet incoming over, say, a two-second period, you can collect all the packets that, based on the timestamp, were lucky enough not to be delayed a lot. By discarding those very-delayed packets, the accuracy of the PTP signal becomes much higher and jitter can reduce, as we see from two case studies, by an order of magnitude.

Watch now!

Andreas Hildebrand Andreas Hildebrand
RAVENNA Evangelist,
ALC NetworX
Daniel Boldt Daniel Boldt
Head of Software Development,

Video: Keeping Time with PTP

Different from his talk of the same name we covered last week, Mike Waidson from Telestream explains the fundamentals of PTP joined by Leigh Whitcomb from Imagine Communications and Robert Welch from Arista. Very few PTP talks include a live BCMA quiz plus, with more time than the IP Showcase talks, this is a well-paced, deep look into the basics.

Mike starts by reviewing how the measurement of time has been more and more accurately measured with us now, typically using atomic clocks. In the TV-domain analogue video used signals for B&B which gave frequency information in the subcarrier and allowed frequency locking and to keep in sync with other signals. NTP has allowed computers and routers on IP networks to keep lock allowing sub-millisecond synchronisation over LANs. Now we have IEEE 1588 PTP which harnesses hardware for maximum precision providing sub-microsecond precision.

Traditionally an SPG would create many different synchronising signals, distributed by DAs. With PTP however, the idea is creating a single time signal on to the network (as well as older signals if necessary). Although, the important thing to remember is that PTP both sends and receives data from the endpoints. GPS is made from 31 active satellites of which only 4 are needed for a lock. But other systems such as the Russian GLONASS, the Chinese BAIDU Navigational system or the European Galileo can also be used, sometimes in conjunction with each other to improve locking speed or give resilience.

Mike and his co-hosts give an overview of the standards that make all this possible, starting with the PTP standard itself IEEE 1588-2019 which is added to by SMPTE 2059. The latter is two standards that, together ensure broadcast devices can usefully harness PTP which is a general, cross-industry standard and track all signals back to a single point in time in 1970. Whilst this may seem extreme, the benefit of doing this is that if we know that all possible types of signal were in-phase at this one point in time, we can extrapolate how each signal should be phased now and use that information to synchronise the system. Upcoming to PTP, we hear, are standardised ways to monitor PTP plus additional security around the standard.

The next section looks at the types of Grandmaster and the fact that each clock works in its own domain. Typically, all your system will be in the same domain, but if you have incompatible situations such as older Dante networks or if you want to have a testing environment, you can use domains to separate your equipment. The standard, as defined by SMPTE 2059 is 127.

Mike then looks at the different types of PTP Message types: Announce, Sync & Follow up, Delay Request, Delay Response and Management Messages (broadcast information, drop second, time zone etc.) He then brings some of these up in Wireshark and talks us through the structure and what can be found within.

The most original part of the talk is the live walkthrough of three different scenarios where Leigh and Robert talk through their thinking on which clock will be the grandmaster and for what reason. This comes down to their understanding of the order of precedence of the metrics such as the manually-allotted priority, then the class of clock, clock accuracy and other values. One value worth remembering is that if your clock is locked to GPS it will have a class of 6, but if it then loses lock, it will become 7.

PTP talks are not complete without an explanation of the sync message exchanges needed to actually determine the time (and the relative delays in order to compute it) as well as the secondary clock types, boundary and transparent. Boundary clocks take on much of the two-way traffic in PTP protecting the grandmasters from having to speak directly to all the, potentially, thousands of devices. Transparent switches, simply update the time announcements with the delay for the message to move through the switch. Whilst this is useful in keeping the timing accurate, it provides no protection for the grandmasters.

Before the talk finishes with a Q&A, the team finish by explaining the difference between operating in unicast and multicast, prioritising PTP traffic using the differentiated services protocol and adding redundancy to the PTP system.

Watch now!
Free registration required

Robert Welch Robert Welch
Technical Solultions Lead,
Leigh Whitcomb Leigh Whitcomb
Principal Engineer.
Michael Waidson Mike Waidson
Application Engineer,

Video: Migrating to IP – Top Questions from Broadcasters

Moving to IP can be difficult. For some, it’s about knowing where to even start. For others, it’s a matter of understanding some of the details which is the purpose of this talk from Leader US which looks at the top questions that Leader’s heard from its customer base:

  • How do we look at it?
  • How do we test it?
  • How is the data sent?
  • What is PTP?
  • How do we control it?
  • What is NMOS?
  • What are the standards involved?

These questions, and more, are covered in this webinar.

Steve Holmes from Lader Us details the IP relevant basics starting with the motivations: weight, cost, scale, density, and independent essences. We can then move on to the next questions covering RTP itself and how 2022-6 was built upon it. SMPTE ST 2022-6 splits up a regular SDI signal into sections and encapsulates them, uncompressed. This is one big difference from SMPTE ST 2110 where all essences are sent separately. For some, this is not a benefit, but for general broadcast workflows, it can sometimes be tricky getting them into alignment and some workflows are aimed at delivering an incoming bundle of PIDs so being able to separate them is a backward step.

With this groundwork laid, Steve explains how seamless redundancy works with SMPTE 2022-7 going on to then describe the difficulty of keeping jitter low and the importance of sender profiles in ST 2110. Steve finishes this section with a discussion of NMOS specifications such as IS-05 and IS-06. The session ends with a Q&A.

Watch now!

Steve Holmes Steve Holmes
Freelance consultant

Video: AES67 & SMPTE ST 2110 Timing and Synchronization

Good timing is essential in production for AES67 audio and SMPTE ST 2110. Delivering timing is no longer a matter of delivering a signal throughout your facility, over IP timing is bidirectional and forms a system which should be monitored and managed. Timing distribution has always needed design and architecture, but the detail and understanding needed are much more. At the beginning of this talk, Andreas Hildebrand explains why we need to bother with such complexity, after all, we got along very well for many years without it! Non-IP timing signals are distributed on their own cables as part of their own system. There are some parts of the chain which can get away without timing signals, but when they are needed, they are on a separate cable. With IP, having a separate network for distribution of timing doesn’t make sense so, whether you have an analogue or digital timing signal, that needs to be moving into the IP domain. But how much accuracy in timing to you need? Network devices already widely use NTP which can achieve an accuracy of less than a millisecond. Andreas explains that this isn’t enough for professional audio. At 48Khz, AES samples happen at an accuracy of plus or minus 10 microseconds with 192KHz going down to 2.5 microseconds. As your timing signal has to be less than the accuracy you need, this means we need to achieve nanosecond precision.

Daniel Boldt from timing specialists Meinberg is the focus of this talk explaining how we achieve this nano-second precision. Enter PTP, the Precision Time Protocol. This is a cross-industry standard from the IEEE uses in telcoms, power, finance and in many others wherever a network and its devices need to understand the time. It’s not a static standard, Daniel explains, and it’s just about to see its third revision which, like the last, adds features.

Before finding out about the latest changes, Daniel explains how PTP works in the first place; how is it possible to accurately derive time down to the nanosecond over a network which will have variable propagation times? We see how timestamps are introduced into the network interface controller (NIC) at the last moment allowing the timestamps to be created in hardware which removes some of the variable delays that is typical in software. This happens, Daniel shows, in the switch as well as in the server network cards. This article will refer to either a primary clock or a grand master. Daniel steps us through the messages exchanged between the primary and secondary clock which is the interaction at the heart of the protocol. The key is that after the primary has sent a timestamp, the secondary sends its timestamp to the primary which replies saying the time it received the secondary the reply. The secondary ends up with 4 timestamps that it can combine to determine its offset from the primary’s time and the delay in receiving messages. Applying this information allows it to correct the clock very accurately.

PTP Primary-Secondary Message Exchange.
Source: Meinberg

Most broadcasters would prefer to have more than one grandmaster clock but if there are multiple clocks, how do you choose which to sync from? Timing systems have long used strata whereby clocks are rated based on accuracy, either for internal accuracy & stability or by what they are synched to. This is also true for PTP and is part of the considerations in the ‘Best Master Clock Algorithm’. The BMCA starts by allowing a time source to assess its own accuracy and then search for better options on the network. Clocks announce themselves to the network and by listening to other announcements, a clock can decide if it should become a primary clock if, for instance, it hears no announce messages at all. For devices which should never be a grand primary, you can force them never to decide to become grand masters. This is a requisite for audio devices participating in ST 2110-3x.

Passing PTP around the network takes some care and is most easily done by using switches which understand PTP. These switches either run a ‘boundary clock’ or are ‘transparent clocks’. Daniel explores both of these scenarios explaining how the boundary clock switch is able to run multiple primary and secondary clocks depending on what is connected on each interface. We also see what work the switches have to do behind the scenes to maintain timing precision in transparent mode. In summary, Daniel summaries boundary clocks as being good for hierarchical systems and scales well but requires continuous monitoring whereas transparent clocks are simpler to deploy and require minimal monitoring. The main issue with transparent clocks is that they don’t scale well as all your timing messages are still going back to one main clock which could get overwhelmed.

SMPTE 2022-7 has been a very successful standard as its reliance only on RTP has allowed it to be widely applicable to compressed and uncompressed IP flows. It is often used in 2110 networks, too, where two separate networks are run and brought together at the receiving device. That device, on a packet-by-packet basis, is free to derive its audio/video stream from either network. This requires, however, exactly the same timing on both networks so Daniel looks at an example diagram where this PTP sharing is shown.

PTP’s still evolving and in this next section, Daniel takes us through some of the coming improvements which are also outlined at Meinberg’s blog. These are profile isolation, multi-domain clocks, security improvements and more.

Andreas takes the final section of the webinar to explain how we use PTP in media networks. All receivers will have the same clock which could be derived from GPS removing the need to distribute PTP between sites. 2110 is based on RTP which requires a timestamp to be added to every packet delivered to the network. RTP is a wrapper around IP packets which includes a timestamp which can be derived from the media clock counter.

Andreas looks at how accurate RTP delivery is achieved, dealing with offset values, populating the timestamp from the PTP clock for realties streams and he explains how the playout delay is calculated from the link offset. Finally, he shows the relatively simple process of synchronisation art the playout device. With all the timestamps in the system, synchronising playback of audio, video and metadata using buffers can be achieved fairly easily. Unfortunately, timestamps are easily destroyed by secondary processing (for instance loudness adjustment for an audio stream). Clearly, if this happened, synchronisation at the receiver would be broken. Whilst this will be addressed by out-of-band messaging in future standards, for now, this is managed by a broadcast controller which can take delay information from processing stages and distribute this to receivers.

Watch now!

Daniel Boldt Daniel Boldt
Head of Software Development,
Andreas Hildebrand Andreas Hildebrand
RAVENNA Technology Evangelist,
ALC NetworX