Have you ever heard of PTP? Most people haven’t, unless you’re an engineer dealing specifically with timing. For example, broadcast engineers will setup their network to run PTP so that all their cameras and systems will be synchronized. It’s an incredibly important, say mandatory, step in the core of a broadcast operation.

PTP stands for Precision Time Protocol. It runs either through ethernet or IP-based ports. Simply put, it’s a protocol that will adjust the internal time of a machine so that it matches a “Grand Master” time source. It accounts for simple differences in time on each machine, as well as delay in sending signals over the network.

Let me give you an example. Say we have 3 broadcast cameras. Each are sending back video to the broadcast unit’s core. Some of those internal times may be slightly off. If they are too far off (in nanoseconds), when a director switches between cameras, the internal system has to switch to a different source. If those times are out of sync, then a black hole appears as the system switches. If they are in sync, then it is seamless. Remember old tube tv’s in the 80’s? You’d switch to a different channel, it would take a second and go black in-between changing channels. That’s what we’re trying to avoid with PTP.

The “rules” for PTP are documented in IEEE 1588. The way PTP works is basically a 3 step process. This is a very generalized view of it, there are a lot of other items that can be added and/or changed.

First, the Grand Master (GM) sends a sync message to a Slave machine (these terms are changing in new documentation to Leader and Follower, but for current documentation I will stay with the same terminology). The GM notes the time it sends this sync message. The Slave receives the message and records the time. (Sometimes, the Grand Master will send a follow-up message as well, depending on PTP configuration).

Second, the Slave sends a delay request to the GM. Basically, it is saying “Hey GM, I received your time message at this time”.

Lastly, the GM receives that delay request from the Slave. It knows when it first sent the sync message and compares that to what the Slave is sending as the time it received that sync message. It calculates the difference in time and sends that difference as a delay response to the Slave. The Slave gets that message and adjusts it’s clocks based on that delay. Thus, the two clocks become synced, including delay in network traffic.

This process happens over and over and over again. The machines at my work do this about 8 times a second, for example.

Upgrades are currently still in development. PTP is an open source library, so anybody interested can clone and use it. It’s an incredibly accurate process that’s revolutionized precision timing.