Daniel Boldt

Video: PTP Over Wan

Posted on by Russell Trafford-Jones

Work is ongoing in the IPMX project to reduce SMPTE ST 2110’s reliance on PTP, but the reality is that PTP is currently necessary for digital audio systems as well as for most ST 2110 workflows. There are certainly challenges in deploying PTP from an architectural standpoint with some established best practices, but these are only useful when you have the PTP signal itself. For the times when you don’t have a local PTP clock, delivery over a WAN may be your only solution. With PTP’s standards not written with a WAN in mind, can this be done and what are the problems?

 

 

Meinberg’s Daniel Boldt describes the work he’s been involved with in testing PTP delivery over Wide Area Networks (WANs) which are known for having higher, more variable latency than Local Area Networks (LANs) which are usually better managed with low latency which users can interrogate to understand exactly how traffic is moving and configure it to behave as needed. One aspect that Daniel focuses on today is Packet Delay Variation (PDV) which is a term that describes the difference in time between the packets which arrive the soonest and those that arrive last. For accurate timing, we would prefer overall latency to be very low and for each packet to take the same amount of time to arrive. In real networks, this isn’t what happens as there are queuing delays in network equipment depending on how busy the device is both in general and on the specific port being used for the traffic. These delays vary from second to second as well as throughout the day. Asymmetry can develop between send and receive paths meaning packets in one direction take half the time to arrive than those in the other. Finally, path switching can create sudden step changes in path latency.

Boundary Clocks and Transparent Clocks can resolve some of this as they take in to account the delays through switches. Over the internet, however, these just don’t exist so your options are to either build your own WAN using dark fibre or to deal with these problems at the remote site. If you are able to have a clock at the remote site, you could use the local GNSS-locked clock with the WAN as a backup feed to help when GNSS reception isn’t available. But when that’s not possible due to cost, space or inability to rack an antenna, something more clever is needed.

Lucky Packet Filter
Source: Meinberg

The ‘lucky packet filter’ is a way of cleaning up the timing packets. Typically, PTP timing packets will arrive between 8 and 16 times a second, each one stamped with the time it was sent. When received, its propagation time can be easily calculated and put in a buffer. The filter can look at the statistics then throw away any packets which took a long time to arrive. Effectively this helps select for those packets which had the least interference through the network. Packets which got held a long time are not useful for calculating the typical propagation time of packets so it makes sense to discard them. In a three-day-long test, Meinberg used a higher transmit rate of 64 packets per second saw the filter reduced jitter from 100 microseconds to an offset variation of 5 microseconds. When this was fed into a high-quality clock filter, the final jitter was only 300ns which was well within the 500ns requirement of ST 2059-2 used for SMPTE ST 2110.

Daniel concludes the video by showing the results of a test with WDR where a PTP Slave gateway device was fed with 16 packets a second from a master PTP switch over the WAN. The lucky packet filter produced a timing signal within 500ns and after going through an asymmetry step detection process in the clock produced a signal with an accuracy of no more than 100ns.

Watch now!
Speaker

Daniel Boldt Daniel Boldt
Meinberg

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

Posted on by Russell Trafford-Jones

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
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!
Speakers

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

Video: AES67 & SMPTE ST 2110 Timing and Synchronization

Posted on by Russell Trafford-Jones

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!
Speakers

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

Video: Real World IP – PTP

Posted on by Russell Trafford-Jones

PTP, Precision Time Protocol, underpins the recent uncompressed video and audio over IP standards. It takes over the role of facility-wide synchronisation from black and burst signals. So it’s no surprise that The Broadcast Bridge invited Meinberg to speak at their ‘Real World IP’ event exploring all aspects of video over IP.

David Boldt, head of software engineering at Meinberg, explains how you can accurately transmit time over a network. He summarises the way that PTP accounts for the time taken for messages to move from A to B. David covers different types of clock explaining the often-heard terms ‘boundary clock’ and ‘transparent clock’ exploring their pros and cons.

Unlike black and burst which is a distributed signal, PTP is a system with bi-directional communication which makes redundancy all the more critical and, in some ways, complicated. David talks about different ways to attack the main/reserve problem.

PTP is a cross-industry standard which needs to be interpreted by devices to map the PTP time into an understanding of how the signal should look in order for everything to be in time. SMPTE 2059 does this task which David cover.

PTP-over-WAN: David looks at a case study of delivering PTP over a WAN. Commonly assumed not practical by many, David shows how this was done without using a GPS antenna at the destination. To finish off the talk, there’s a teaser of the new features coming up in the backwards-compatible PTP Version 2.1 before a Q&A.

This is part of a series of videos from The Broadcast Bridge

Watch now!
Speakers

Daniel Boldt

 Daniel Boldt
Head of Software Engineering
Meinberg