TL;DR
- ▸A grandmaster is the authoritative time source — disciplined to GNSS and serving PTP downstream. Every PTP fabric has at least one (ideally two for redundancy).
- ▸A boundary clock terminates PTP on its upstream port and re-originates it on its downstream ports — it disciplines its own clock and acts as master to the next layer.
- ▸A transparent clock doesn't terminate PTP; it measures the residence time of each PTP message as it transits the device and writes the correction inline.
Grandmaster: where trust originates
A PTP grandmaster is the authoritative time source for an IEEE 1588 network. It takes time from a primary reference (almost always GNSS), disciplines a local oscillator to that reference, and distributes the disciplined time downstream via PTP messages. Every other clock in the fabric is ultimately tracking the grandmaster, so its accuracy and reliability set the upper bound for everything else.
Production grandmasters are hardware appliances or PCIe time cards with hardware-grade GNSS receivers, OCXO/Rubidium/DOCXO holdover oscillators, and PTP transports that handle multiple profiles simultaneously. Software-only grandmasters running on commodity NICs exist for lab use but cannot deliver the precision a production network depends on.
Boundary clock: the workhorse of every real network
Real networks have multiple switches and routers between any two endpoints, and the variable queueing delay through each switch is enough to destroy PTP precision if the protocol can't compensate for it. Boundary clocks solve this by running PTP on every port: upstream-facing ports act as slaves to the master, downstream-facing ports act as masters to the next layer.
Each boundary clock disciplines its own internal clock to the upstream master and then re-originates fresh PTP messages downstream. This resets the network jitter accumulation at every hop, allowing PTP to traverse arbitrarily complex topologies. The trade-off is that each boundary clock contributes its own residual error to the chain — typically ±30 ns per hop on a Class C BC. Six hops costs you about ±200 ns from the boundary clock chain alone.
Transparent clock: the simpler alternative
Transparent clocks take a different approach to the same problem. Rather than terminating PTP and re-originating it, the transparent clock measures how long each PTP message spends inside the device (the residence time) and writes that residence time as a correction field on the message before forwarding it. The downstream slave subtracts the accumulated residence time from its delay calculation, effectively removing the switch's contribution to network jitter.
Transparent clocks are simpler to certify and remain common in industrial automation deployments where switch hardware is constrained. Modern enterprise and telecom deployments mostly lean toward boundary clocks because they offer better operational visibility and more predictable failover behaviour.
Choosing between BC and TC
Boundary clocks for any deployment where you want operational visibility, observability per hop and predictable BMCA failover. Transparent clocks for embedded industrial deployments where simpler certification matters more than per-hop visibility. Don't mix them on the same fabric without thinking it through.
How they work together
A typical production deployment looks like this: one or two grandmasters at the top of the timing hierarchy, a layer of PTP-aware boundary clocks across the network fabric, and a population of slave clocks at the leaves (NICs in servers, FPGAs in trading systems, embedded clocks in cameras and base stations). Every device speaks the same PTP profile with the same defaults, BMCA elects a single active grandmaster, and the boundary clock chain delivers the grandmaster's time downstream with bounded error.
When something goes wrong — a grandmaster fails, a GNSS antenna is unplugged, a boundary clock reboots — BMCA detects the change and the timing fabric reconfigures within seconds without human intervention. That's the design intent, and it works in practice when the deployment is correctly configured. Most PTP failures we see in the field are not protocol failures; they're failures to specify or audit one of the three clock types correctly.
Frequently asked questions
What is a PTP grandmaster clock?+
What's the difference between a boundary clock and a transparent clock?+
How many boundary clock hops can a PTP fabric tolerate?+
Can a single device be both a boundary clock and a grandmaster?+
Related reading
Blog · Standards
Understanding IEEE 1588 PTP: How Precision Time Powers Industrial Ethernet
What IEEE 1588 actually defines, how the protocol works at the message level, and why it's the foundation under every modern industrial Ethernet, telecom and broadcast timing fabric.
Blog · Protocols
Precision Time Protocol vs NTP: When Each Belongs in Production
The honest engineering comparison between Precision Time Protocol and NTP — what each protocol can actually deliver, where the boundary lives, and how to choose between them without falling for either side's marketing.
Blog · PTP
A Critical Look at Boundary Clock PTP Distribution
The traditional boundary-clock-chain model for PTP distribution has limits — particularly when the chain gets long, the topology gets complex, or the failure modes get subtle. A critical look at where the old model still works and where it doesn't.