As we’ve seen in so many videos, PTP is fundamental to large-scale SMPTE ST 2110 and pro-audio installations. On The Broadcast Knowledge we’ve looked at a large range of talks on PTP on architecture, scaling, and how it fits in to the broadcast industry. Few of these break down PTP into the fundamentals like today’s article about a video from Albert Mitchell from Cisco.
The key to a PTP network is having one grandmaster clock which can provide time for the rest of the network. In this article, the clocks running in the end devices are called ‘ordinary clocks’. Whilst there are ways to avoid using PTP with uncompressed video such as ST 2110, for live, studio-style productions where you will be bringing them together in a video mixer or similar, keeping these videos effectively zero latency is important and frame syncs on every input of the mixer are discouraged. A grandmaster clock can provide the timing the whole network needs to make this work, usually fed by GPS time.
SMPTE’s ST 2110 suite has built itself on the timing mechanism of PTP in form of IEEE-1588. SMPTE ST 2059 standards suite provides a method to accommodate all legacy reference and media signals using IEEE-1588 Precision Time Protocol (PTP), delivered over an IP network.
Albert moves on to how this all works. He keeps it simple explaining that there are two measurements needed to get the timing right. You need to know how long it takes to get a message from the grandmaster to the clock and how long it takes to get a message from the clock to the grandmaster. If the grandmaster sends a message with the time in it, it’s trivial for the ordinary clock to look at the time when the message arrived and work out the time it took. It can do the same; an ordinary clock can put the time into a message and send it to a grandmaster. The grandmaster will look at the current time and reply saying how long the transmission delay was. The ordinary clock averages these two measurements and can use the result and the time from the grandmaster to correct its own clock.
Albert finishes by explaining that if there are other switches between the grandmaster and the ordinary clock, those switches should be expected to identify the ‘residence time’ and add this extra delay of simply going through the switch to the time message. Changes in network delay due to congestion or path changes are the reason this timing calculation happens once a second.
PTP is foundational for SMPTE ST 2110 systems. It provides the accurate timing needed to make the most out of almost zero-latency professional video systems. In the strictest sense, some ST 2110 workflows can work without PTP where they’re not combining signals, but for live production, this is almost never the case. This is why a lot of time and effort goes into getting PTP right from the outset because making it work perfectly from the outset gives you the bedrock on which to build your most valuable infrastructure upon.
In this video, Gerard Phillips from Arista, Leigh Whitcomb from Imagine Communications and Telestream’s Mike Waidson join forces to run down their top 15 best practices of building a PTP infrastructure you can rely on.
Gerard kicks off underlining the importance of PTP but with the reassuring message that if you ‘bake it in’ to your underlying network, with PTP-aware equipment that can support the scale you need, you’ll have the timing system you need. Thinking of scale is important as PTP is a bi-directional protocol. That is, it’s not like the black and burst and TLS that it replaces which are simply waterfall signals. Each endpoint needs to speak to a clock so understanding how many devices you’ll be having and where is important to consider. For a look a look at PTP itself, rather than best practices, have a look at this talk free registration required or this video with Meinberg.
Gerard’s best practices advice continues as he recommends using a routed network meaning having multiple layer 2 networks with layer 3 routing between This reduces the broadcast domain size which, in turn, increases stability and resilience. JT-NM TR-1001 can help to assist in deployments using this network architecture. Gerard next cautions about layer 2 IGMP snoopers and queriers which should exist on every VLAN. As the multicast traffic is flooded to the snooping querier in layer 2, it’s important to consider traffic flows.
When Gerard says PTP should be ‘baked in’, it’s partly boundary clocks he’s referring to. Use them ‘everywhere you can’ is the advice as they bring simplicity to your design and allow for easier debugging. Part of the simplicity they bring is in helping the scalability as they shed load from your GM, taking the brunt of the bi-directional traffic and can reduce load on the endpoints.
It’s long been known that audio devices, for instance, older versions of Dante before v4.2, use version one of PTP which isn’t compatible with SPMTE ST 2059’s requirement to use PTP v2. Gerard says that, if necessary, you should buy a version 1 to version 2 converter from your audio vendor to join the v1 island to your v2 infrastructure. This is linked to best practice point 6; All GMs must have the same time. Mike makes the point that all GMs should be locked to GPS and that if you have multiple sites, they should all have an active, GPS-locked GM even if they do send PTP to each other over a WAN as that is likely to deliver less accurate timing even if it is useful as a backup.
Even if you are using physically separate networks for your PTP and ST 2110 main and backup networks, it’s important to have a link between the two GMs for ST 2022-7 traffic so a link between the two networks just for PTP traffic should be established.
The next 3 points of advice are about the ongoing stability of the network. Firstly, ST 2059-2 specifies the use of TLV messages as part of a mechanism for media notes to generate drop-frame timecode. Whilst this may not be needed day 1, if you have it running and show your PTP system works well with it on, there shouldn’t be any surprises in a couple of years when you need to introduce an end-point that will use it. Similarly, the advice is to give your PTP domain a number which isn’t a SMPTE or AES default for the sole reason that if you ever have a device join your network which hasn’t been fully configured, if it’s still on defaults it will join your PTP domain and could disrupt it. If, part of the configuration of a new endpoint is changing the domain number, the chances of this are notably reduced. One example of a configuration item which could affect the network is ‘ptp role master’ which will stop a boundary clock from taking part in BCMA and prevents unauthorised end-points taking over.
Gerard lays out the ways in which to do ‘proper commissioning’ which is the way you can verify, at the beginning, that your PTP network is working well-meaning you have designed and built your system correctly. Unfortunately, PTP can appear to be working properly when in reality it is not for reasons of design, the way your devices are acting, configuration or simply due to bugs. To account for this, Gerard advocates separate checklists for GM switches and media nodes with a list of items to check…and this will be a long list. Commissioning should include monitoring the PTP traffic, and taking a packet capture, for a couple of days for analysis with test and measurement gear or simply Wireshark.
Leigh finishes up the video talking about verifying functionality during redundancy switches and on power-up. Commissioning is your chance to characterise the behaviour of the system in these transitory states and to observe how equipment attached is affected. His last point before summarising is to implement a PTP monitoring solution to capture the critical parameters and to detect changes in the system. SMPTE RP 2059-15 will define parameters to monitor, with the aim that monitoring across vendors will provide some sort of consistent metrics. Also, a new version of IEEE-1588, version 2.1, will add monitoring features that should aid in actively monitoring the timing in your ST 2110 system.
How much timing do you need? PTP can get you timing in the nanoseconds, but is that needed, how can you transport it and how does it work? These questions and more are under the microscope in this video from RTS Thames Valley.
SMPTE Standards Vice President, Bruce Devlin introduces the two main speakers by reminding us why we need timing and how we dealt with it in the past. Looking back to the genesis of television, points out Bruce, everything was analogue and it was almost impossible to delay a signal at all. An 8cm, tightly wound coil of copper would give you only 450 nanoseconds of delay alternatively quartz crystals could be used to create delays. In the analogue world, these delays were used to time signals and since little could be delayed, only small adjustments were necessary. Bruce’s point is that we’ve swapped around now. Delays are everywhere because IP signals need to be buffered at every interface. It’s easy to find buffers that you didn’t know about and even small ones really add up. Whereas analogue TV got us from camera to TV within microseconds, it’s now a struggle to get below two seconds.
Hand in hand with this change is the change from metadata and control data being embedded in the video signal – and hence synchronised with the video signal – to all data being sent separately. This is where PTP, Precision Time Protocol, comes in. An IP-based timing mechanism which can keep time despite the buffers and allow signals to be synchronised.
Next to speak is Richard Hoptroff whose company works with broadcasters and financial services to provide accurate time derived from 4 satellite services (GPS, GLONASS etc) and the Swedish time authority RiSE. They have been working on the problem of delivering time to people who can’t put up antennas either because they are operating in an AWS datacentre or broadcasting from an underground car park. Delivering time by a wired network, Richard points out, is much more practical as it’s not susceptible to jamming and spoofing, unlike GPS.
Richard outlines SMPTE’s ST 2059-2 standard which says that a local system should maintain accuracy to within 1 microsecond. the JT-NM TR1001-1 specification calls for a maximum of 100ms between facilities, however Richard points out that, in practice, 1ms or even 10 microseconds is highly desired. And in tests, he shows that with layer 2, PTP unicast looping around western Europe was able to adhere to 1 microsecond, layer 3 within 10 microseconds. Over the internet, with a VPN Richard says he’s seen around 40 microseconds which would then feed into a boundary clock at the receiving site.
Summing up Richard points out that delivering PTP over a wired network can deliver great timing without needing timing hardware on an OPEX budget. On top of that, you can use it to add resilience to any existing GPS timing.
Already in use by many industries including finance, power and telcoms, PTP is base on IEEE-1588 allowing synchronisation down to 10s of nanoseconds. Just sending out a timestamp to the network would be a problem because jitter is inherent in networks; it’s part and parcel of how switches work. Dealing with the timing variations as smaller packets wait for larger packets to get out of the way is part of the job of PTP.
To do this, the main clock – called the grandmaster – sends out the time to everyone 8 times a second. This means that all the devices on the network, known as endpoints, will know what time it was when the message was sent. They still won’t know the actual time because they don’t know how long the message took to get to them. To determine this, each endpoint has to send a message back to the grandmaster. This is called a delay request. All that happens here is that the grandmaster replies with the time it received the message.
This gives us 4 points in time. The first (t1) is when the grandmaster sent out the first message. The second (t2) is when the device received it. t3 is when the endpoint sent out its delay request and t4 is the time when the master clock received that request. The difference between t2 and t1 indicates how long the original message took to get there. Similarly t4-t3 gives that information in the other direction. These can be combined to derive the time. For more info either check out Arista’s talk on the topic or this talk from RAVENNA and Meinberg from which the figure above comes.
Gerard briefly gives an overview of Boundary Clock which act as secondary time sources taking pressure off the main grandmaster(s) so they don’t have to deal with thousands of delay requests, but they also solve a problem with jitter of signals being passed through switches as it’s usually the switch itself which is the boundary clock. Alternatively, Transparent Clock switches simply pass on the PTP messages but they update the timestamps to take account of how long the message took to travel through the switch. Gerard recommends only using one type in a single system.
Referring back to Bruce’s opening, Gerard highlights the need to monitor the PTP system. Black and burst timing didn’t need monitoring. As long as the main clock was happy, the DA’s downstream just did their job and on occasion needed replacing. PTP is a system with bidirectional communication and it changes depending on network conditions. Gerard makes a plea to build a monitoring system as part of your solution to provide visibility into how it’s working because as soon as there’s a problem with PTP, there could quickly be major problems. Network switches themselves can provide a lot of telemetry on this showing you delay values and allowing you to see grandmaster changes.
Gerard’s ‘Lessons Learnt’ list features locking down PTP so only a few ports are actually allowed to provide time information to the network, dealing carefully with audio protocols like Dante which need PTP version 1 domains, and making sure all switches are PTP-aware.
The video finishes with Q&A after a quick summary of SMPTE RP 2059-15 which is aiming to standardise telemetry reporting on PTP and associated information. Questions from the audience include asking how easy it is to do inter-continental PTP, whether the internet is prone to asymmetrical paths and how to deal with PTP in the cloud.
An informal chat touching on the newest work around SMPTE ST-2110 standards and related specifications in today’s video. The industry’s leading projects are now tracking the best practices in IT as much as the latest technology in IP because simply getting video working over the network isn’t enough. Broadcasters demand solutions which are secure from the ground up, easy to deploy and have nuanced options for deployment.
Andy Rayner from Nevion talks to Prin Boon from Phabrix to understand the latest trends. Between then, Andy and Prin account for a lot of activity in standards work within standards and industry bodies such as SMPTE, VSF and JT-NM to name a but a few, so whom better to hear from regarding the latest thinking and ongoing work.
Andy starts by outlining the context of SMPTE’s ST-2110 suite of standards which covers not only the standards within 2110, but also the NMOS specifications from AMWA as well as the timing standards (SMPTE 2059 and IEEE 1588). Prin and Andy both agree that the initial benefit of moving to IT networking was benefiting from the massive network switches which now delivering much higher switching density than SDI ever could or would, now the work of 2110 projects is also tracking IT, rather than simply IP. By benefiting from the best practices of the IT industry as a whole, the broadcast industry is getting a much better product. Andy makes the point that broadcast-uses have very much pushed fabric manufacturers to implement PTP and other network technologies in a much more mature and scalable way than was imagined before.
The focus of conversation now moves to the data, control and timing plane. The data plane contains the media essences and all of the ST 21110 standards. Control is about the AMWA/NMOS specs such as the IS-0X specs as well as the security-focused BCP-003 and JT-NM TR-1001. Timing is about PTP and associated guidelines.
Prin explains that in-service test and measurement is there to give a feeling for the health of a system; how close to the edge is the system? This is about early alerting of engineering specialists and then enable deep faultfinding with hand-held 2110 analysers. Phabrix, owned by Leader, are one of a number of companies who are creating monitoring and measurement tools. In doing this Willem Vermost observed that little of the vendor data was aligned so couldn’t be compared. This has directly led to work between many vendors and broadcasters to standardise the reported measurement data in terms of how it’s measured and how it is named and is being standardised under 2110-25. This will cover latency, video timing, margin and RTP offset.
More new work discussed by the duo includes the recommended practice, RP 2059-15 which is related to the the ST 2059 standards which apply PTP to media streams. As PTP, also known as IEEE 1588 has been updated to version 2.1 as part of the 2019 update, this RP creates a unified framework to expose PTP data in a structured manner and relies on RFC 8575 which, itself, relies on the YANG data modeling language.
We also hear about work to ensure that NMOS can fully deal with SMPTE 2022-7 flows in all the cases where a receiver is expecting a single or dual feed. IS-08 corner cases have been addressed and an all-encompassing model to develop against has been created as a reference.
Pleasingly, as this video was released in December, we are treated to a live performance of a festive song on piano and trombone. Whilst this doesn’t progress the 2110 narrative, it is welcomed as a great excuse to have a mine pie.
Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members.
This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE