PTP

Video: Timing Requirements in Broadcast Applications

Posted on by Russell Trafford-Jones

How does timing for AES67 and SMPTE ST 2110-30 work? All is revealed in this short video by Andrea Hildebrand who explains why we need PTP timing and how we relate the absolute time to the signals themselves.

In a network for audio streams, Andreas starts, we want all the streams to run on their native sample rate, use the same clock, but also want to have the possibility of multiple concurrent streams using different sample rates. Also, it’s important to have a deterministic end-to-end latency and that, when streams arrive, they should be suitably aligned. We achieve all of this by distributing time around the system. Audio has very high accuracy requirements of down to within 10 microseconds for typical 48KHz broadcast signals, but AES11 requires within 1 microsecond which is why the Precision Time Protocol, PTP is used which is defined by the standard IEEE 1588. For more information on PTP, check out our PTP back library

End devices run their own local clocks, synchronised to the PTP on the network. In charge of it all, there is a grandmaster locked to GPS which can then distribute to other secondary clocks which feed the end devices. The end device can generate a media clock from the PTP and by using PTP, different facilities can be kept in time with each other. All media is then timestamped with the time when they were generated. For advice on architecting PTP, have a listen to this talk from Arista’s Gerard Phillips.

RTP is used to carry professional media streams like AES. RTP builds on top of UDP to add the critical timing information we need. Namely, the timestamp but also the sequence number. Andreas looks at the structure of the RTP packet header to see where the timestamp and identifiers go. To follow up on the IT basics underpinning AES67 and SMPTE ST 2110, check out Ed Calverley’s presentation on the topic.

‘Profiles’ are required to link the time of day to media flows – to give the time some meaning in terms of the expected signal. The AES67 Media Profile does this for AES67 as an annexe in the standard. SMPTE use ST 2059 to define how to use AES67 as well as all the other essences it supports and relate them all back to an originating epoch time in 1970.

The talk finishes by looking at the overlap in timing specs for AES67 and ST 2110-30 (AES67 for 2110). For more information on how AES67 and ST 2110 work (and don’t work) together, watch Andreas’s ‘Deeper dive’ on the topic.

Watch now!
Speakers

Andreas Hildebrand Andreas Hildebrand
RAVENNA Evangelist
ALC NetworX

Video: Keeping Time with PTP

Posted on by Russell Trafford-Jones

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
Speakers

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

Video: Keeping Time with PTP

Posted on by Russell Trafford-Jones

The audio world has been using PTP for years, but now there is renewed interest thanks to its inclusion in SMPTE ST 2110. Replacing the black and burst timing signal (and for those that used it, TLS), PTP changes the way we distribute time. B&B was a waterfall distribution, PTP is a bi-directional conversation which, as a system, needs to be monitored and should be actively maintained.

Michael Waidson from Telestream (who now own Tektronix) brings us the foundational basics of PTP as well as tips and tricks to troubleshoot your PTP system. He starts by explaining. the types of messages which are exchanged between the clock and the device as well as why all these different messages are necessary. We see that we can set the frequency at which the announce, sync and follow-up messages. The sync and follow-up messages actually contain the time. When a device receives one of these messages, it needs to respond with a ‘delay request’ in order to work out how much of a delay there is between it and the grand master clock. This will result in it receiving a delay response. On top of these basic messages, there is a periodic management message which can contain further information such as daylight savings time or drop-frame information.

Michael moves on to looking at troubleshooting highlighting the four main numbers to check: The domain value, grandmaster ID, message rates and the communication mode. PTP is a global standard used in many industries. To make PTP most useful to the broadcast industry, SMPTE ST 2059 defines values to use for message repetition (4 per second for announce messages, 8 for sync, delay request and delay response). ST 2059 also defines how devices can determine the phase of any broadcast signal for any given time which is the fundamental link needed to ensure all devices keep synchronicity.

Another good tip from Michael is if you see the grandmaster MAC changing between the grandmasters on the system, this indicates it’s no receiving any announce messages so is initiating the Best Master Clock Algorithm (BMCA) and trying the next grandmaster. Some PTP monitoring equipment including from Meinberg and from Telestream can show the phase lag of the PTP timing as well as the delay between the primary and secondary grandmaster – the lower the better.

A talk on PTP can’t avoid mentioning boundary clocks and transparent switches. 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. He finishes video ends with a look at how to check PTP messages on the switch.

Watch now!
Speakers

Michael Waidson Michael Waidson
Application Engineer
Telestream (formerly Tektronix)

Video: Case Study – ST 2110 4K OB Van for AMV

Posted on by Russell Trafford-Jones

Systems based on SMPTE ST 2110 continue to come online throughout the year and, as they do, it’s worth seeing the choices they made to make it happen. We recently featured a project building two OB truck and how they worked around COVID 19 to deliver them. Today we’re looking at an OB truck based on Grass Valley and Cisco equipment.

Anup Mehta and Rahul Parameswaran from Cisco join the VSF’s Wes Simpson to explain their approach to getting ST 2110 working to deliver a scalable truck for All Mobile Video. This brief was to deliver a truck based on NMOS control, maximal COTS equipment, flexible networking with scalable PTP and security.

Thinking back to yesterday’s talk on Network Architecture we recognise the ‘hub and spoke’ architecture in use which makes a lot of sense in OB trucks. Using monolithic routers is initially tempting for OB trucks, but there is a need for a lot of 1G and 10G ports which tends to use up high-bandwidth ports on core routers quickly. Therefore moving to a monolithic architecture with multiple, directly connected, access switches makes them most sense. As Gerard Philips commented, this is a specialised form of the more general ‘spine-leaf’ architecture which is typically deployed in larger systems.

One argument against using IGMP/PIM routing in larger installations is that those protocols have no understanding of the wider picture. They don’t take a system-wide view like a SDN controller would. If IGMP is a paper roadmap, SDN is satnav with up to date road metrics, full knowledge of width/weight restrictions and live traffic alerts. To address this, Cisco created their own technology Non-Blocking Multicast (NBM) which takes in to account the bandwidth of the streams and works closely with Cisco’s DCNM (Data Centre Network Manager). These Cisco technologies allow more insight into the system as a whole, thus make better decisions.

Anup and Rahul continue to explain how the implementation of PTP was scaled by offloading the processing to line cards than relying on the main CPU of the unit before explaining how the DCNM, not only supporting the NBM feature, also supports GV Orbit. This is the configuration and system management unit from GV. From a security perspective, the network, by default, denies access to any connections into the port plus it has the ability to enforce bandwidth limits to stop accidental flooding or similar.

Watch now!
Speakers

Anup Mehta Anup Mehta
Product Manager,
Cisco
Rahul Parameswaran Rahul Parameswaran
Senior Technical Product Manager,
Cisco