PTP Timing Calculator for Broadcast

What PTP is, in one paragraph

Precision Time Protocol (PTP, IEEE 1588) is how devices on a network agree on what time it is, to well under a microsecond. One device — the grandmaster — holds the reference, usually taken from GPS, and every other device measures how long its messages take to arrive so it can correct for the delay. In a broadcast plant this is what keeps cameras, audio, timecode and studio clocks on the same instant. This page does the arithmetic that configuring it requires.

Why PTP configuration goes wrong

PTP is not difficult to understand, but it is easy to misconfigure, and the mistakes are quiet: the network locks, every device reports a grandmaster, and the timing is wrong anyway. Four things account for most of it.

• Intervals are logarithms. A field that reads −3 means 0.125 seconds, or eight messages per second. Typing 3 instead gives you one message every eight seconds — the network still locks, and the holdover does the rest.
• PTP time is TAI, not UTC. They differ by 37 seconds today. An offset applied in the wrong direction lands you 74 seconds out, which is a number you will see on the studio clocks before you see it in a log.
• The profile matters. The IEEE 1588 default profile sends one Sync per second. That is fine for a factory floor and useless for video.
• The SM TLV is separate from the timing. A grandmaster can be perfectly locked and still publish a wrong local offset, so every clock in the building shows the wrong hour while the timing is flawless.

Message intervals, in plain numbers

Every PTP interval is written as the base-2 logarithm of a number of seconds. The interval in seconds is 2 raised to that value, and the message rate is its reciprocal:

• 0 → 1 s → 1 message per second
• −1 → 0.5 s → 2 per second
• −3 → 0.125 s → 8 per second
• −4 → 0.0625 s → 16 per second
• −7 → 0.0078125 s → 128 per second

Faster is not automatically better. Sync messages are multicast and cost the same regardless of how many devices listen, but Delay_Req is sent by every slave and its Delay_Resp comes back individually. Two hundred devices at eight requests per second is 3,200 message pairs per second arriving at one grandmaster. The calculator above estimates that load so you can size it before you deploy it.

The SMPTE ST 2059-2 profile

ST 2059-2 is the broadcast profile of IEEE 1588. It narrows the permitted ranges and adds the metadata that video needs. From the 2021 edition: domain 0 to 127 with a default of 127; logAnnounceInterval from −3 to +1 with a default of 0; logSyncInterval from −7 to −1 with a default of −3, which is eight Sync messages per second; announceReceiptTimeout from 2 to 10 with a default of 3; priority1 and priority2 from 0 to 255, both defaulting to 128. logMinDelayReqInterval initialises to the value of logSyncInterval and may be up to five steps slower.

The domain number deserves a note. The default of 127 is deliberate: it keeps a media network from colliding with a general-purpose PTP domain, which conventionally uses 0. If your grandmaster is on 127 and a device is looking at 0, they will never meet, and the device will report no grandmaster rather than a wrong one.

TAI, UTC and the 37 seconds

PTP counts from the PTP epoch — 1 January 1970 00:00:00 TAI — and TAI has no leap seconds. UTC does, which is why the two have drifted apart by 37 seconds since the last leap second at the end of 2016. The currentUtcOffset field in the Announce message carries that number, and a receiver that ignores it will be 37 seconds fast.

The value to publish in currentLocalOffset is not your time zone. It is your time zone minus the UTC offset: local time equals PTP time plus currentLocalOffset. For Rome in summer that is 7200 − 37 = 7163 seconds. Publishing 7200 leaves every clock in the building 37 seconds fast, and it is exactly the kind of error that survives a commissioning test because everything is consistently wrong.

Frame alignment to the PTP epoch

SMPTE ST 2059-1 defines where video frames sit in time: frame 0 begins at the PTP epoch, and every boundary after that is an exact multiple of the frame period. For integer rates the pattern repeats every second. For 29.97 fps — that is 30000/1001 — it repeats every 1001 seconds, which is why two devices can agree on the time and still disagree on which frame it is if one of them rounds.

The calculator uses exact integer arithmetic for this, not floating point, so the frame index it gives you is the frame index your hardware should agree on.

The Synchronization Metadata TLV

ST 2059-2 attaches a metadata block to the Announce message carrying the things video needs and plain PTP does not: the system frame rate as a rational number, the grandmaster locking status, the local time offset, the timing of the next daylight saving change or leap second, and the times of the previous and next Daily Jam. The calculator produces all eleven fields from the plant details you enter, including the two that are most often wrong — currentLocalOffset and timeOfNextJam.

Where the hardware comes in

A calculator tells you what the numbers should be. Something still has to produce them, hold them when the GNSS antenna loses sky, and keep producing them at three in the morning. Our PTPMaster is a GNSS-disciplined PTP IEEE 1588 grandmaster with hardware timestamping, an integrated web dashboard, and support for the SMPTE ST 2059-2 and AES67 profiles — built in Rome, where we have been making broadcast timing equipment since 1984.