Glossary

PTP

Precision Time Protocol

What is PTP

PTP (Precision Time Protocol) is a protocol for achieving high-precision clock synchronization across a computer network, standardized as IEEE 1588. Its goal is to synchronize clocks across a network down to microsecond or even sub-microsecond accuracy — a level of precision that ordinary time-sync protocols like NTP can't reach.

That precision matters in a growing number of environments: distributed computing systems that need consistent event ordering across nodes, AI training clusters that need tightly synchronized clocks for coordinated processing, high-frequency trading systems where trade timestamps have real financial and regulatory weight, media broadcast networks that need frame-accurate timing, and scientific instruments that need precisely time-stamped measurements.

A PTP network is organized as a master-slave hierarchy. At the top sits a single reference clock for the whole domain — the Grandmaster Clock (GMC) — and every other clock node synchronizes to it, directly or through intermediate nodes, forming a tree-like distribution structure.

How PTP Works

A network running PTP is called a PTP domain. Each domain has exactly one time source, and every device in the domain stays synchronized to it.

The nodes inside a PTP domain are clock nodes, and IEEE 1588v2 defines three basic types:

  • Ordinary Clock (OC): participates in PTP synchronization through a single physical port — either syncing from an upstream node, or distributing time downstream.

  • Boundary Clock (BC): participates through two or more ports — one port synchronizes from an upstream device, while the remaining ports distribute time downstream. This lets a BC re-time and re-distribute rather than simply pass traffic through.

  • Transparent Clock (TC): does not synchronize its own clock to anyone. It simply forwards PTP messages between its ports while correcting for the time it spent handling each message (its "residence time"), so downstream nodes can still calculate an accurate delay.

Telecom-specific profiles (ITU-T G.8275.1 and G.8275.2) define related roles — T-GM, T-BC, T-TSC, T-TC for full-timing-support networks, and T-BC-P / T-TSC-P for partial-timing-support networks — built on the same underlying master/slave/transparent concepts.

Each PTP-enabled interface is a PTP port, taking on one of three roles: a master port (distributes time), a slave port (receives time), or a passive port (neither — an idle backup port found only on boundary clocks).

Synchronization itself happens through a defined exchange of PTP messages — Announce (exchanges time-source information to establish master/slave structure), Sync and Follow_Up (carry the master's send timestamp, either in one step or split across two messages), and Delay_Req / Delay_Resp or Pdelay_Req / Pdelay_Resp (measure the path delay between master and slave). By recording the timestamps exchanged during this handshake, a slave clock can calculate both the network path delay and its own time offset from the master, then adjust accordingly.

Two delay-measurement mechanisms are commonly used:

  • End-to-End (E2E): calculates delay based on the overall path between master and slave.

  • Peer-to-Peer (P2P): calculates delay link-by-link, along each hop between master and slave.

Because a domain can contain many clock nodes, PTP needs a way to decide which one acts as the grandmaster. That's the job of the Best Master Clock (BMC) algorithm: nodes exchange Announce messages carrying clock-quality data, and the algorithm compares them — by priority, clock class, accuracy, and a secondary priority value, in that order — to elect the best available clock as the domain's grandmaster (or the grandmaster can simply be configured statically).

Why PTP is Beneficial

  • Delivers precision ordinary protocols can't reach: PTP is purpose-built for microsecond and sub-microsecond synchronization, well beyond what NTP-class protocols can guarantee.

  • Corrects for network-induced timing error: Transparent clocks and boundary clocks actively account for the time messages spend traversing each hop, so synchronization accuracy doesn't degrade as it passes through more of the network.

  • Adapts to different network shapes: Boundary Clock, End-to-End Transparent Clock, and Peer-to-Peer Transparent Clock deployment modes each suit a different topology — from large, layered hierarchies to simple fixed paths to dynamic, mesh-like networks.

  • Self-organizing and resilient: The Best Master Clock algorithm lets a domain automatically elect (and re-elect) its grandmaster clock, without requiring every node to be manually configured or reconfigured as the network changes.

  • Standardized across industries: IEEE 1588v2 and telecom-specific profiles like ITU-T G.8275.1/G.8275.2 and AES67 give PTP well-defined behavior across data center, telecom, and media-production networks.

At Asteraix

What We Can Do at Asteraix

AsterNOS brings PTP support directly into the data center switching platform, so precision time distribution doesn't require a separate, dedicated timing network.

  • Full clock-type support: AsterNOS switches can operate as Transparent Clock, Boundary Clock, or Ordinary Clock, covering every role a device typically plays across a PTP-enabled data center topology.

  • Broad profile coverage: Supported PTP profiles include SMPTE-2059-2, 1588v2, ITU-T G.8275.1, ITU-T G.8275.2, and AES67 — spanning data center, telecom, and media/broadcast timing requirements on the same platform.

  • Both sync modes: One-step and two-step synchronization modes are both supported, so AsterNOS can interoperate with a wide range of upstream and downstream PTP devices.

  • Both delay-measurement mechanisms: End-to-End (E2E) and Peer-to-Peer (P2P) delay measurement are both available, matching the three typical deployment models — BC mode, E2E-TC mode, and P2P-TC mode — to fit hierarchical, fixed-path, or dynamic mesh topologies.

  • Standard BMCA support: The Best Master Clock Algorithm is supported for automatic grandmaster election, alongside multicast, unicast, and hybrid communication modes for flexibility across different network designs.

  • Precision that holds up in practice: AsterNOS-based PTP deployments achieve synchronization accuracy of approximately 20 nanoseconds, suitable for latency-sensitive AI, HPC, and financial-timing environments.