PTP

Overview

Precision Time Protocol (PTP) is a way of synchronizing clocks within a computer network. Correctly implemented it can achieve a clock accuracy in the sub-microsecond range and is suitable to synchronize media streams. Version 2 is applicable today and has been standardized as IEEE1588-2008.

PTP time uses the same epoch Unix time uses (00:00 on 1970-01-01), but is based on International Atomic Time which is not adjusted for leap seconds.

PTP uses a master-slave approach in which all master-capable devices elect the best master, called the grandmaster, following a common algorithm (“best master clock algorithm”, “BMCA”). To ensure accurate time at the client, the delay caused by the time it takes the packets to travel between master and slave is measured and compensated for in a continuous adjustment process.

PTP usually uses multicast to distribute time information, even though version 2 of the standard extended the protocol by an option for unicast transmission.

Generally, PTP can be run on any network. Switches that are unaware of PTP treat it as regular multicast traffic. This allows PTP to function, but decreases the clock accuracy since the switch itself introduces variable delays in packet processing which are not accounted for. Using switches without support for PTP should be avoided.

Some switches support PTP in order to increase clock accuracy. They can work in two modes: transparent and boundary clock.

The switches running in transparent PTP mode measure the time the PTP packets spend travelling through the switch and add a compensation value into the packets to account for that time. This increases the accuracy of PTP time. In this mode all slaves communicate directly with the master, which – depending on the amount of slaves – might cause a substantial amount of load on the master.

In boundary clock mode the switch participates in the master election process and presents itself as PTP master on any switch port that does not have “better” master attached to it. This mode alleviates much of the processing load from the grandmaster (now only the switch request time directly from the grandmaster) and thus allows for bigger networks with more PTP clients.

With many participants in the synchronization process the amount of messages exchanged can increase substantially when using multicast without boundary clock, especially when using SMPTE ST2059-2 timing with 8 delay request messages per second: every PTP slave will see every other PTP slaves’ delay request messages and delay response messages from the grandmaster as they are all subscribed to the same multicast addresses. To avoid this, the delay requests and the corresponding delay responses from the master can be exchanged in unicast mode. This communication scheme is then often called “hybrid” mode. If the master is able to handle the amount of concurrent client requests from the slaves, this can be an alternative to a switch with boundary clock.

The V__line has been successfully tested as grandmaster with approximately 200 V__lines acting as PTP slaves in hybrid mode.

PTP will be used as a complement and later a replacement of video reference and word clock signals. The accuracy that can be achieved with a well-tuned system is perfectly sufficient for phase-accurate audio and video applications.

If the switch implements boundary clock mode correctly, we recommend using boundary clock. For smaller networks transparent clock is a valid option as well. For medium sized networks the hybrid mode can be used.

 

Profiles

AES-R16-2016 proposes the PTP settings for interoperability between the existing profiles. The first option includes the default Peer-to-Peer Profile as specified in IEEE1588-2008, the Media Profile as specified in AES67 and the SMPTE Profile as specified in ST2059-2.

The second option only includes the latter two (AES67, ST2059-2).

 

The following tables outline the parameter values for both proposals:

Parameter

Proposed Value

Comment

Domain

0

 

Announce Interval

1

= 2 seconds

Announce Receipt Timeout

3

 

Sync Interval

-1

= 0.5 seconds

Min Delay Request Interval

0

= 1 second

(Interoperability between IEEE1588-2008 Default Profile, AES67 Media Profile and SMPTE ST2059-2 Profile)

 

Parameter

Proposed Value

Comment

Domain

0

 

Announce Interval

0

= 1 second

Announce Receipt Timeout

3

 

Sync Interval

-3

= 0.125 seconds

Min Delay Request Interval

-3

= 0.125 seconds

(Interoperability between AES67 Media Profile and SMPTE ST2059-2 Profile)

 

Parameter

Value

Comment

Domain

127

 

Announce Interval

-2

= 0,25 seconds

Announce Receipt Timeout

3

 

Sync Interval

-3

= 0.125 seconds

Min Delay Request Interval

-3

= 0.125 seconds

(SMPTE ST2059-2 Profile)

Please keep in mind that in order for PTP to work correctly, all PTP masters AND slaves must use the same values.

As the new standard SMPTE ST2110 specifies the use of the SMPTE ST2959-2 profile, we recommend the use of this profile as well. If integrating with (older) audio devices, we recommend using the interoperability profile between AES67 and SMPTE ST2059-2.

Since the ST2059-2 profile uses an “aggressive” timing, the use of a high performance grand master, hybrid mode and / or boundary clock is recommended for larger systems. For a more detailed test of PTP scaling read the SMPTE Presentation “Large scale PTP: How big can it get?” by Nicholas Ciarleglio (Arista), Thomas Edwards (FOX) and Robert Welch (Arista).

 

For the V__line the PTP values can be set in the “Settings” –> “Switch” –> “PTP” menu:

 

For the A__line these values can be set in the “PTP” settings:

PTP Timing Accuracy

The time distributed in the network needs to be accurate enough to synchronize essence streams including phase information. Therefore, it is essential that the PTP clients do not deviate too much from the PTP grandmaster’s time.

With a good grandmaster and a PTP-aware network you should be able to reach an accuracy of +/-1µs. An accuracy of +/-2µs is still considered sufficient.

The V__lines allow to measure and display these offsets and can be set to respect either accuracy definition (+/-1µs = Timing Precision High; +/-2µs = Timing Precision Low) or even create custom one. These settings can be found in “Settings” –> “Switch” –> “PTP":

Values of +/- 5µs offset have been tested successfully between 2 V__lines without impact to the video on the output. Results with other devices may vary.

 

 

 

In the A__line the timing precision is displayed as a color-coded graph on the “Ravenna” page.

Green means the offset is below 1µs, yellow means between 1µs and 5µs and red means above 5µs.

1 µs translates into +/-5% of media a clock period (at 48 kHz), which is the allowed phase tolerance for digital outputs specified in AES11-2009. 5 µs translates into +/-25% of a media clock period (at 48 kHz), which is the required maximum tolerance for digital inputs of connected downstream equipment. This usually won't be noticeable with a common slave device. A value beyond 5µs may indicate a potential problem in certain critical applications. External MADI signals might not work together with the network-based signals. This has been chosen to become a red indication.

However, if there is only analogue audio signal exchange or if a connected audio device derives its own synchronization from the network device, timing precision even worse than 5 µs won’t produce audible artifacts.

Noticeable issues, such as sample slip, may arise if the offset is larger than 10 µs, representing more than +/-50% of a sample period.