PTP Boundary Clock vs Transparent Clock: Which to Deploy

Synchronous Ethernet gives you frequency, but 5G, TDD radio, power substations and financial timestamping need phase and time. Once PTP crosses more than a couple of switches, someone asks whether the network should use boundary clocks or transparent clocks — and the answer changes the hardware you buy. This article explains both mechanisms, their error behaviours, and why one is the default in telecom networks.

Transparent clock: stay out of the protocol

A transparent clock (TC) does not become a master or a slave. It measures how long a PTP event message stayed inside the device — the residence time — and adds that value to the message’s correctionField before forwarding it. The slave at the far end subtracts total residence time from the measured offset and gets an accurate result as if the switches were not there.

• End-to-end TC — corrects residence time only; the slave measures the full path delay.
• Peer-to-peer TC — also measures link delay per hop and accumulates it, so path asymmetry and queueing per link are handled as well.

The advantage is scale and simplicity: no protocol state, no master/slave election, and the grandmaster is unchanged. The catch is that PTP must reach every node in the chain — if a device in the path does not understand PTP, the correction chain breaks.

Boundary clock: terminate and regenerate

A boundary clock (BC) runs a full PTP clock instance. One port is a slave to the best upstream master; all other ports act as masters to downstream devices. Each downstream link therefore looks like a short, single-hop PTP domain, which removes accumulated path delay and packet-delay variation from end to end — the reason telecom profiles define the telecom boundary clock (T-BC) as the standard network element for phase distribution.

Operational consequences:

• Best Master Clock Algorithm runs at every BC, so a misconfigured priority or a rogue master can steal the clock. Track the parent relationship, not just the sync state.
• Each hop adds its own servo and holdover characteristics. Class B/C oscillators and holdover specifications become part of the design.
• The chain of clocks creates a bounded error budget per hop, which is why ITU-T G.8271 sets phase/time budgets per network element.

Why phase and time are harder than frequency

Synchronous Ethernet distributes frequency by locking a physical-layer clock to the incoming Ethernet bit stream. It is a continuous process with a narrow loop bandwidth, and it does not care how long a packet took to cross the network — only that bits keep arriving at the right average rate. PTP is different in kind. A grandmaster timestamps messages, and every device in the path adds serialisation delay, forwarding delay and queueing delay which varies from packet to packet. That variation, packet delay variation (PDV), is what a PTP servo has to filter, and it is the reason a network that is perfectly adequate for SyncE can be useless for phase.

Frequency from PTP is comparatively easy: average out the delay and you recover the rate. Phase and time also require path symmetry. If the forward path is 3 µs slower than the reverse path, the slave computes an offset error of 1.5 µs — and it does so forever, because nothing in the message exchange reveals it. Asymmetry comes from the PHY itself (different transmit and receive latencies), from different optics or media converters in one direction, from LAG hashing that puts the two directions on different members, and from queueing that is asymmetric. This is why phase deployments obsess over symmetrical paths, and why a boundary clock chain that hides the network behind single-hop links is attractive even when it costs more hardware.

The message exchange you are actually measuring

In an ordinary-clock deployment the exchange is Sync (timestamp t1), Follow_Up (carrying the precise t1 when Sync is two-step), Delay_Req (t3) and Delay_Resp (t4). The slave computes offset as ((t2 - t1) - (t4 - t3)) / 2, where t2 is the arrival time of Sync and t3 the departure time of Delay_Req. Everything in that equation assumes the two directions are symmetrical, and everything about the correction field described above exists to keep the delay terms honest.

Peer delay is the alternative. Instead of asking the master, each port measures its own link with Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up. Delay then becomes a per-link property that can be accumulated hop by hop, which is what makes the peer-to-peer transparent clock and the G.8275.1 profile possible: a P2P TC does not need the slave to know anything about the end-to-end path, it corrects residence time and link delay at each hop and the slave simply subtracts the total.

One-step and two-step matters too. A one-step clock writes the egress timestamp into the Sync message as it leaves, which requires hardware timestamping in the port. A two-step clock sends Sync and then a Follow_Up carrying the timestamp. Both are accurate; mixing implementations inside one domain is legal but makes packet captures considerably harder to read.

! Linux: use pmc as a microscope into a running ptp4l instance
pmc -u -b 0 'GET TIME_STATUS_NP'
pmc -u -b 0 'GET CURRENT_DATA_SET'
pmc -u -b 0 'GET PARENT_DATA_SET'
pmc -u -b 0 'GET PORT_DATA_SET'

! Capture PTP to watch the correction field grow hop by hop (EtherType 0x88F7)
sudo tcpdump -i eth0 -c 20 'ether proto 0x88f7' -vv

Profiles: G.8275.1, G.8275.2 and the enterprise default

Selecting a profile is not a preference, it determines message rates, transport, delay mechanism and what kind of clock every node in the chain has to be.

G.8275.1 is the profile used in mobile fronthaul and transport: a boundary clock at every node, peer-to-peer delay measurement, L2 multicast and no negotiation, because every element is known to be PTP-aware. G.8275.2 exists for cases where you cannot control the path — an ordinary clock reaches a grandmaster through a network of unknown switches and the servo has to filter PDV on its own, which costs accuracy and demands much better holdover. G.8265.1 delivers frequency for legacy backhaul where phase is not required. In a data centre or broadcast plant you will most often meet the default profile with end-to-end transparent clocks implemented in the switch ASIC.

Error budgets: where the nanoseconds actually go

ITU-T G.8271.1 gives a phase and time budget for a TDD radio chain and splits it into constant time error (cTE), which never averages out, and dynamic time error (dTE), which does. G.8273.2 then classes boundary clocks: a class A T-BC contributes roughly 50 ns of constant error, class B about 20 ns, class C about 10 ns and class D about 5 ns, with corresponding dTE allowances and holdover behaviour. The consequence of a hop-by-hop budget is that ten class A boundary clocks can consume most of a strict radio budget before the grandmaster or the radio itself are counted, which is why transport nodes in a mobile network are normally class B or better.

The other half of the budget is not in the standard at all. It is asymmetry in your own infrastructure: fibre strands cut to different lengths, an SFP in one direction and a copper PHY in the other, a LAG that hashes the two directions onto different members, or a QoS policy that queues PTP event traffic in one direction only. Any of these produces a constant offset that no amount of servo tuning will remove. Measure it before blaming the clock — the LACP hashing and bonding modes article explains why an uneven hash breaks phase, and QoS trust boundaries covers the queueing side.

Configuring boundary and transparent clocks on real hardware

Syntax differs between vendors and even between software releases, so treat the blocks below as the shape of the configuration and confirm the details against your platform's PTP guide. A worked example for the Arista stack is in Arista AVD PTP configuration.

! Arista EOS: boundary clock in a telecom profile
ptp mode boundary
ptp domain 24
ptp profile g8275.1
ptp priority1 128
ptp priority2 128
interface Ethernet1
   ptp enable
!
! Or an end-to-end transparent clock instead
ptp mode e2etransparent
ptp domain 0

! Junos: boundary clock with one slave port and one master port
set protocols ptp clock-mode boundary
set protocols ptp domain 0
set protocols ptp slave interface ge-0/0/0.0
set protocols ptp master interface ge-0/0/1.0

! Cisco IOS XE / Catalyst
ptp clock boundary domain 0
interface GigabitEthernet1/0/1
 ptp enable

! Cisco Nexus
feature ptp
ptp domain 0
ptp source 10.10.10.10
interface Ethernet1/1
 ptp
 ptp role master

! Linux ptp4l as a boundary clock (one slave port, one master port)
ptp4l -f /etc/ptp4l.conf -m -i eth0 -i eth1

! Synchronise the NIC hardware clock to system time
phc2sys -s eth0 -c CLOCK_REALTIME -w -m

! Check hardware timestamping capabilities of an interface
ethtool -T eth0

Verifying a PTP deployment end to end

• Port state and role. Every port should report a role consistent with the design: one slave port facing the grandmaster, the rest master. A port that alternates between master and listening points at a competing master or an announce timeout.
• Parent and grandmaster identity. Check the parent dataset, not just the sync state. A boundary clock locked to the wrong master is still reported as locked.
• Correction field. In a transparent clock chain the value grows by the residence time of each hop. In a boundary clock chain it resets at each hop, because the message is regenerated. Look at the actual numbers, not just at whether they are non-zero.
• Offset and delay trends. A fixed offset that never improves is asymmetry; a wandering offset with a daily pattern is temperature or oscillator drift; a sawtooth that resets every few minutes is a servo fighting a heavily loaded path.
• Message rate and QoS. Confirm that PTP event traffic is in its own queue, and verify the marking with counters and a capture rather than trusting the configuration.
• Holdover. Pull the uplink and measure how long the node stays inside budget. That number, not the locked-state accuracy, is what keeps the radio alive through a fibre cut.
• Monitoring. Export offset and clock state as metrics and alert on state changes or a growing absolute offset — the same exporter and SNMP approach used for the rest of the network works fine for PTP counters.

Migration and mixed networks

Real networks are rarely pure. The workable patterns are: run boundary clocks in the transport layer and transparent clocks inside the data centre so each domain is internally consistent; keep one PTP domain number across the chain you want synchronised; and place a boundary clock at every boundary between domains. Where a chain of transparent clocks crosses a device that does not understand PTP, the correction stops being applied and everything downstream is silently wrong — the slave still locks, but to the wrong time. That failure mode is the strongest argument for boundary clocks in operated networks: a boundary clock terminates the chain, so a non-PTP-aware device becomes invisible to the protocol instead of corrupting it. The price is that every boundary clock is now a clock you must monitor, upgrade and holdover-test.

Choosing, in practice

• Fronthaul and telecom transport: boundary clocks at every transport node (T-BC), because phase budgets at the radio require hopping the delay accumulation.
• Data centre, broadcast and industrial: transparent clocks (often in the switch ASIC) keep the grandmaster relationship simple and scale well.
• Mixed networks: the boundary clock terminates the chain, so PTP does not need to be understood by every box on the path — but every BC is now a clock you must monitor and manage.

What to verify on the wire

• Check the correctionField on Sync and Follow_Up messages — if a TC is doing its job, the field increases by residence time at each hop.
• Check the hop sequence: BC installations show a chain of independent domains; TC installations show one domain with growing corrections.
• Watch for asymmetry: both clock types correct delay, but only if the forward and reverse paths are symmetric. Link aggregation with uneven hashing or an asymmetric queue in one direction will show up as a constant phase offset that no amount of tuning removes.
• Keep PTP event traffic in its own queue (DSCP 46, strict priority or a dedicated traffic class). Congestion is the dominant source of packet delay variation in practice.

Related reading: PTP versus NTP explained, chrony and NTP drift troubleshooting and optical transceiver power thresholds.

原文链接：https://www.ti.com/lit/an/snla104a/snla104a.pdf