Search Results for: PTP

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

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