PTP

Video: IPMX Makes Networks Easy

Posted on by Russell Trafford-Jones

IPMX is bringing a standards-based, software deployable connectivity solution to ProAV. It stands itself in contrast to hardware-based IP technologies such as Zeevee and SDVoE which both aim to create de facto standards by building large alliances of companies based on their chips. IPMX’s aim is to open up the market to a free-to-access technology that can be implemented in hardware and software alike. In this way vendors have more freedom in implementation with the hope of wider interoperability, depending on IPMX adoption. These are amongst some of the business reasons behind IPMX which are covered in this talk Matrox’s David Chiappini.

In today’s video, Matrox’s Jean Lapierre looks at the technical side of IPMX to answer some of the questions from those who have been following its progress. AIMS, the Alliance for IP Media Solutions, are upfront about the fact that IPMX is a work in progress with important parts of the project dealing with carriage of HDCP and USB still being worked on. However, much has already been agreed so it makes sense to start thinking about how this would work in real life when deployed. For a primer on the technical details of IPMX, check out this video from Andreas Hildebrand.

 

 

Jean starts by outlining the aims of the talk; to answer questions such as whether IPMX requires a new network, expensive switches and PTP. IPMX, he continues, is a collection of standards and specifications which enable transport of HD, 4K or 8K video in either an uncompressed form or lightly compressed, visually lossless form with a latency of <1ms. Because you can choose to enable compression, IPMX is compatible with 1GB, CAT5e networks as well as multi-gigabit infrastructure. Moreover, there’s nothing to stop mixing compressed and uncompressed signals on the same network. In fact, the technology is apt for carrying many streams as all media (also known as ‘essences’ to include metadata) is sent separately which can lead to hundreds of separate streams on the network. The benefit of splitting everything up is that in the past if you wanted to read subtitles, you would have to decode a 3Gbps signal to access a data stream better measured in bytes per second. Receiving just the data you need allows servers or hardware chips to minimise costs.

Jean explains how multicast is used to deliver streams to multiple receivers and how receivers can subscribe to multiple streams. A lot of the time, video streams are used separately such as from a computer to a projector meaning exact timing isn’t needed. Even coming into a vision mixer/board doesn’t always need to be synchronised because for many situations, having a frame synchroniser on all inputs works well. There are, however, times when frame-accurate sync is important and for those times, PTP can be used. PTP stands for the Precise Time Protocol and if you’re unfamiliar, you can find out more here.

The upshot of using PTP with IPMX is that you can unlock perfect synchronisation for applications like video walls; any time you need to mix signals really. IMPX relaxes some of the rules of PTP that SMPTE’s ST 2059 employs to reduce the load on the grandmaster clocks. PTP is a very accurate timing mechanism but it’s fundamentally different from black and burst because it’s a two-way technology that relies on an ongoing dialogue between the devices and the clock. This is why Jean says that for anything more than a small network, you are likely to need a switch that is PTP aware and can answer the queries which would normally go to the single, central switch. In summary then, Jean explains that for many IPMX implementations you don’t need a new network, a PTP grandmaster or PTP aware switches. But for those wanting to mix signals with perfect sync or those who have a large network, new investment would reap benefits.

Watch now!
Speaker

Jean Lapierre Jean Lapierre
Senior Director, Advanced Technolgies
Matrox

Video: A Review of the IP Live Core Implementation in BBC Cymru Wales

Posted on by Russell Trafford-Jones

Whenever there’s a step change in technology, we need early adopters and moving to SMPTE’s ST 2110 is no exception. Not only do early adopters help show that the path ahead is good, but they often do a lot to beat down the bushes and make the path easier to pass for all that follow. For larger companies whose tech refresh or building move comes at a time when the industry is facing a major technology change, there comes a time when whilst the ground may not be firm ahead, the company can’t justify investing in technology that would soon be out of date or in technology which won’t support the needs of the company in several years’ time. This is just the situation that BBC Cymru Wales found themselves in when it was time to move out of their old property into a purpose-built national HQ in the heart of Cardiff.

In this video from the IP Showcase, Mark Patrick and Dan Ashcroft guide us through ‘whys’ and the ‘hows’ of the relocation project. It’s important to remember that this project was long in the making with the decision on location taking place in 2014 with the technology decisions taking place in 2016 and 2017. The project took an open approach to the IP/SDI question and asked for RFP responses to include a fully-SDI and a fully-IP option. It was clear during the selection process that IP was the way to go not because the solution was cheaper in the short term, but because it was much more future-proof and the costs would come down over time giving a much better total cost of ownership. Don’t forget that the initial costs of HD video equipment were much higher than those now. For more on the pros and cons of SDI, watch ‘Is IP really better than SDI?‘ by Ed Calverly.

 

 

Mark and Dan talk through the thinking for the IP choice and their decision to pick a vendor who would be their partner in the project. The theory being that given the standards were still very young, it would be important to work closely to ensure success. In addition to Grass Valley equipment, they chose a Cisco network with Cisco SDN control and operational control by BNCS. The talk references architectures we’ve featured on The Broadcast Knowledge before with Arista’s Gerard Phillips discussing the dual-network spine-leaf architecture chosen and noting the difficulty they had incorporating the Dante network into the 2110 infrastructure and their choice of a third network purely for control traffic.

We often hear about the importance of PTP in a SMPTE ST 2110 network for live production because it is vital to keep all the essences in sync. For more information about the basics of ST 2110 check out this talk by Wes Simpson. PTP is both simple and complex so Mark explains how they’ve approached distributing PTP ensuring that the separate networks, amber and blue, can share PTP grandmasters for resilience.

Other topics covered in the talk include

  • Control Methodology
  • AES67 and Dante
  • Testing equipment
  • JT-NM interoperability testing
  • Successes and difficulties

Watch now!
Speakers

Mark Patrick Mark Patrick
Lead Architect,
BBC
Dan Ashcroft Dan Ashcroft
Senior Project Manager,
BBC
Wes Simpson Moderator: Wes Simpson
LearnIPVideo.com

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: Precision Time Protocol (PTP) and Packet Timestamping in Linux

Posted on by Russell Trafford-Jones

SMPTE’s ST-2110 standard can work on hardware or software, but its reliance on PTP, the Precision Time Protocol, makes full software support tricky. Why is this? Is this not just a question of more precise coding practices or changing programming language? There are times when PTP support for ST 2110 isn’t strictly needed and, indeed, the IPMX project is currently working on relaxing PTP requirements so that ST 2110 can be used in the ProAV market without ubiquitous PTP. But when you do need it on software deployed on a server, what are your options and what are the challenges?

This talk by Antoine Ténart looks at the pros and cons of using software vs hardware to create timestamps. First, however, Antoine looks at how PTP works. We’ve covered this before in a Cisco talk but Antoine points out that there are two methods that PTP can work, 1-step and 2-step. PTP synchronisation works by sending 2 messages from the grandmaster clock to the clock wanting to synchronise. There are also two messages sent back to the grandmaster. Keeping close track of when each of these messages was sent and received, and assuming the network delay is the same in both directions, you can work out how long it’s currently taking for timing messages to get to you. Once you’ve cracked the secret of how long messages get to you, you can accurately sync your clock to messages from the grandmaster which say ‘the time is currently …”

 

 

Without this exchange of messages, there’s no way to accurately synchronise your time with the PTP grandmaster within nanoseconds and you’d be left with NTP as your best option which can only keep accuracy within a few milliseconds. Some logs, transactions and media need much better accuracy than milliseconds. So with PTP relying on accurate timestamps, it’s important to find the best way to accurately stamp each message with its origin time.

Without hardware support, when the grandmaster sends its first message saying “This is the time”, a second message needs to be sent immediately afterwards saying “By the way, that last message actually left at a slightly different time:…” which is called the Follow-up Packet. Within broadcast, most equipment has hardware support and so can update the packet as it leaves the grandmaster with the actual time. When you can avoid the follow-up packet, this is known as a 1-step process.

As we covered in this the second talk from Cisco there is more than one type of clock: grandmaster, boundary and transparent. Antoine takes a moment to show how the boundary clock fits between end-devices and the grandmaster. For a deeper dive into PTP and its application to broadcast, watch Arista’s Gerard Philips in this IET Media talk.

Source: Antoine Ténart

Antoine tackles both software and hardware timestamping next. Software, he shows is done in the application or the kernel using the system clock. The errors/deltas involved can be big with a long time passing before transmission. Not being certain when timestamps will occur leads to jitter in the timing signal.

Hardware insertion can be done in the Ethernet layer, in PHY or by a dedicated controller like the Mellanox X5 cards. Errors and deltas are small since the timestamp is inserted close to the actual transmission. In fact, the only delta is it crossing the PHY layer.

The video ends with Antoine discussing offloading, specific calls in the kernel such as SO_TIMESTAMPING and SO_TIMESTAMPTING_TX_HARDWARE as well as introducing us to some tools such as ptp4l, which is a PTP client and ptp2sys which updates the system clock to the ptp time.

Watch now!
Speaker

Antoine Ténart Antoine Ténart
Senior Software Engineer, Red Hat
Former Linux Kernel Engineer, Bootlin