PTP

Video: Precision Time Protocol (PTP) Clock Types

Posted on by Russell Trafford-Jones

Part II in this Cisco series on PTP, Precision Time Protocol, focuses on Boundary Clocks and Transparent Clocks. Last week we heard how PTP maintains accurate time by calculating the delay between clocks and the grandmaster clock which is the source of time for the network. This video summarises how to distribute that source of time to all your devices and how to choose between the two methods.

Albert Mitchell from Cisco explains that transparent clocks are just that, they transparently let the timing data flow through. All they do is update the timestamps on the outgoing packets to compensate for the extra time getting through the switch. A boundary clock (BC), however, is a source of time of itself but gets its time from the grandmaster like any other clock. Acting in this dual way, it creates the boundary it’s named after. It’s a boundary because it provides time to other end devices on the network, These devices never see the grandmaster, they only see the BC. Likewise, the grandmaster only sees the BC acting like any ordinary clock sending delay requests. This means that the boundary clock can shield the grandmaster from the rest of the devices on the network. A grandmaster with 10 boundary clocks can deliver time to over a thousand endpoints without a problem. Without the boundary clocks, the grandmaster may not be able to handle the two-way conversations necessary with so many clocks.

 

 

For broadcast networks, boundary clocks are preferred as they enable easier diagnosis and can reduce the blast radius of problems. Importantly they can span multiple VLANs. Other benefits are that they filter packet delay variation and shields the downstream/following clocks from any transient changes in the grandmasters. The downside of BCs is that they do add small errors to the timing which can add up if multiple BCs are concatenated.

Transparent clocks, on the other hand, don’t help with scalability like BCs and are limited to single VLANs. On the plus side, they require no configuration and provide faster convergence.

Lastly, Albert looks at the Best Master Clock Algorithm (BMCA) which is the method used to determine which grandmaster is providing timing to the whole network. For a deeper dive into the BMCA, have a look at this Arista video on PTP timing. Albert gives a good starting overview of how the algorithm works, the data it needs to operate and advice on settings to make sure you know which clock will win in each instance.

Watch now!
Speakers

Albert Mitchell Albert Mitichell
Technical Marketing Engineer,
Cisco

Video: Introduction to Precision Time Protocol (PTP)

Posted on by Russell Trafford-Jones

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.

Watch now!
Speakers

Albert Mitchell Albert Mitchell
Technical MArketing Engineer,
Cisco

Video: PTP/ST 2059 Best Practices developed from PTP deployments and experiences

Posted on by Russell Trafford-Jones

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.

This Arista white paper contains further detail on many of these best practices.

Watch now!
Speakers

Gerard Phillips Gerard Phillips
Solutions Engineer,
Arista
Leigh Whitcomb Leigh Whitcomb
Principal Engineer.
Imagine
Michael Waidson Mike Waidson
Application Engineer,
Telestream

Video: Time and timing at VidTrans21

Posted on by Russell Trafford-Jones

Timing is both everything and nothing. Although much fuss is made of timing, often it’s not important. But when it is important, it can be absolutely critical. Helping us navigate through the broadcast chains varying dependence on a central co-ordinated time source is Nevion’s Andy Rayner in this talk at the VSF’s VidTrans21. When it comes down to it, you need time for coordination. In the 1840s, the UK introduced ‘Railway time’ bringing each station’s clock into line with GMT to coordinate people and trains.

For broadcast, working with multiple signals in a low-latency workflow is the time we’re most likely to need synchronisation such as in a vision or audio mixer. Andy shows us some of the original television technology where the camera had to be directly synchronised to the display. This is the era timing came from, built on by analogue video and RF transmission systems which had components whose timing relied on those earlier in the chain. Andy brings us into the digital world reminding us of the ever-useful blanking areas of the video raster which we packed with non-video data. Now, as many people move to SMPTE’s ST 2110 there is still a timing legacy as we see that some devices are still generating data with gaps where the blanking of the video would be even though 2110 has no blanking. This means we have to have timing modes for linear and non-linear delivery of video.
 

 
In ST 2110 every packet is marked with a reduced resolution timestamp from PTP, the Precision Time Protocol (or See all our PTP articles). This allows highly accurate alignment of essences when bringing them together as even a slight offset between audios can create comb filters and destroy the sound. The idea of the PTP timestamp is to stamp the time the source was acquired. But Andy laments that in ST 2110 it’s hard to keep this timestamp since interim functions (e.g. graphics generators) may restamp the PTP breaking the association.

Taking a step back, though, there are delays now up to a minute later delivering content to the home. Which underlines that relative timing is what’s most important. A lesson learnt many years back when VR/AR was first being used in studios where whole sections of the gallery were running several frames delayed to the rest of the facility to account for the processing delay. Today this is more common as is remote production which takes this fixed time offset to the next level. Andy highlights NMOS IS-07 which allows you timestamp button presses and other tally info allowing this type of time-offset working to succeed.

The talk finishes by talking about the work of the GCCG Activity Group at the VSF of which Andy is the co-chair. This group is looking at how to get essences into and out of the cloud. Andy spends some time talking about the tests done to date and the fact that PTP doesn’t exist in the cloud (it may be available for select customers). In fact you may have live with NTP-derived time. Dealing with this is still a lively discussion in progress and Andy is welcoming participants.

Watch now!
Speakers

Andy Rayner Andy Rayner
Co-Chair, Ground-Cloud-Cloud-Ground Activity Group, VSF
Chief Technologist, Nevion