What is Precision Time Protocol (PTP)?

5 mins read

PTP stands for “Precision Timing Protocol”, and is described in IEEE Standard 1588. It is a protocol for distributing time across a packet network. It works by sending a message from a master clock to a slave clock, telling the slave clock what time it is at the master. However, the main issue is working out the delay of that message, and much of the PTP protocol is dedicated to solving that problem.

For example, if I sent a letter containing the time and date when I posted the letter, that is not useful to the receiver unless they know how long the letter took to arrive. If they know I used a next-day delivery service, they could set their calendar correctly, but they couldn’t set their watch. The accuracy to which they know the delay is the accuracy to which they can set their time to.

PTP works by using a two-way exchange of timing messages, known as “event messages”. It is easy to calculate a “round trip delay” from this, and the protocol then estimates the one-way message delay by simply halving the round-trip delay. This assumption is the protocol’s Achilles heel – it simply does not have the information required to work out the one-way delay correctly. If, as is often the case, the forward and reverse messages take different amounts of time to cross the network, the time estimate will be wrong. This is known as the “asymmetry problem”.

There are three key techniques used by the protocol to reduce error in the delay estimate:

It precisely records the time at which event messages cross the physical interface. This eliminates the software delay involved in recognising and processing the messages.

These recover the time at intermediate points across the network, and forward the time on in a new set of messages. Typically these clocks are found in switches and routers in the network, and they help to reduce the effect of delay variation in the network, such as might be caused by queueing delays.

These may also be found in switches and routers across the network, but instead of recovering the time and forwarding it on, they simply record the amount of time the message spent traversing that switch or router. When the message finally arrives at the slave clock, it contains information about the accumulated delay through the network, allowing the slave clock to more precisely align its local time to the master clock.

PTP has evolved over time, and IEEE 1588 is currently undergoing a revision process to help improve the suitability of the protocol for use in a variety of industries, including telecoms, power distribution, automotive, scientific and industrial networks. From the number of participants in that process from many different backgrounds, it is clear that it has a strong future over the next few years as the principal method of distributing accurate time across networks.

A clock is simply a device that counts regular events from a common starting point. That applies to all clocks and calendars, with the possible exception of a sundial! The regular events might be days, months and years, or they might be pendulum swings, quartz vibrations, or atomic transitions.

For example, my watch counts the resonant vibrations of a quartz crystal. I manually set the time to a known starting point, usually by comparing to a clock that I assume has a more accurate version of the time in my time-zone, for example my cell phone. In turn, my cell phone gets its time from the cellular network, which gets its time from a time server, which gets its time from a national time server, which gets its time from UTC. In that way, there is a loose traceability of my watch right back to UTC time, even if it is somewhat inaccurate when it reaches my watch. The crystal frequency of my watch doesn’t exactly match UTC frequency, so the time gradually deviates from the correct value, and I periodically adjust my watch to keep it reading close to the correct time.

A PTP clock is no different. A PTP slave clock receives messages from a PTP master clock several times a second, and adjusts its time to match the incoming messages. In between these messages, it relies on a counting “ticks” of a local oscillator – typically quartz crystal vibrations – to keep the time advancing, just like my watch also relies on its internal crystal. PTP boundary clocks work on the same principle, they receive time messages from a grandmaster clock, adjust their own time, and then pass that time along to subsequent boundary clocks or slave clocks.

Clearly, at the end of the chain, the time is not as accurate as the start of the chain. Each clock introduces a certain amount of inaccuracy. For example, these errors might be caused by inaccuracy in the time adjustments, or by instability in the crystal, causing the time to deviate between adjustments. The performance of a clock can be defined in terms of four key parameters: noise generation, noise tolerance, noise transfer, and transient response or holdover. Noise generation is the amount of time error a clock introduces, measured with an “ideal” timing signal at the input. Noise tolerance is the amount of time error a clock can tolerate at its input and still function correctly. Noise transfer is how much noise a clock passes from its input to its output, or in other words, how much does the clock filter a noisy incoming signal. Holdover (sometimes called “long-term transient response” defines how long a clock will maintain accurate time if the input timing signal is lost. In subsequent posts will look in more detail at each of these parameters.

EEE1588 (2008) is a huge standard, 269 pages long. It defines the Precision Time Profile (PTP), a protocol for distributing time over a packet network. Thing is, types of packet networks are ten a penny these days. There are industrial networks, power networks, telecom networks, audio networks, video networks, in-car networks just to name a few. All have subtly different requirements and therefore IEEE1588 contains loads of different options and features that simply aren’t appropriate for every network.

To cope with this, the good folks on the 1588 committee added profiles. A profile is “a set of required options, prohibited options, and the ranges and defaults of configurable attributes”. The idea was to allow other organisations (such as industry bodies or other standards bodies) to define which portions of the PTP protocol their industry would use. For example, ITU defined the G.8265.1 profile specifically for distributing accurate frequency (but not time) to mobile basestations.

Problem is, profiles have proliferated. ITU have defined 3 of them, IEEE themselves have at least 3, IETF tried to define one but never finished, IEC have one that is almost the same as one of the IEEE profiles but not quite, SMPTE have one, and there are probably others out there too.

It’s like they all claim to speak English, but they all have a different dialect – one speaks Geordie, one speaks American, another speaks Scots, and another speaks the Queen’s English. Each are sufficiently different for them to not quite understand each other.

So next time someone says “These are all PTP clocks, surely they’ll talk to each other?” you need to ask what profile they run before answering. Confusing or what?!