PTP Boundary Clock vs Transparent Clock Explained

When time synchronisation has to be better than NTP can deliver — sub-microsecond, for financial timestamping, industrial control, 5G fronthaul or power substation automation — the answer is IEEE 1588 PTP. The protocol itself is straightforward; what decides whether you actually achieve the accuracy is which clock role each device in the path plays.

PTP basics

A grandmaster clock transmits Sync messages, normally followed immediately by a Follow_Up carrying the precise transmit timestamp, and slaves respond with Delay_Req/Delay_Resp to measure the round trip. From those four timestamps a slave computes offset and path delay. Accuracy therefore depends entirely on how consistently those timestamps reflect the moment a packet crossed the wire — which is what the different clock types exist to guarantee.

The clock roles

Why boundary clocks matter

A single grandmaster serving a large flat network through a chain of transparent clocks accumulates jitter and depends on a shared timing domain. A boundary clock terminates the protocol at each hop: it behaves as a slave toward the upstream device and as a grandmaster toward everything downstream. Each downstream segment gets freshly generated timing, so packet-delay variation (PDV) accumulated in one segment does not propagate, and downstream devices see a clean, shallow master hierarchy.

# Junos: configure a boundary clock
set protocols ptp clock-mode boundary
set protocols ptp slave interface ge-0/0/1.0
set protocols ptp master interface ge-0/0/2.0
set protocols ptp master interface ge-0/0/3.0
set protocols ptp slave-parameters-domain-number 24

Every port is explicitly classified as slave (facing the upstream grandmaster) or master (facing downstream devices). Getting that assignment the wrong way round is the most common configuration error — the device then either creates a timing loop or silently refuses to synchronise.

Verification

show ptp clock
show ptp master
show ptp slave
show ptp port
show ptp statistics

Check the port state on each interface, the offset and path-delay values on the slave side, and the statistics for drops or discarded messages. An offset that oscillates by microseconds rather than holding steady usually means the upstream segment is not PTP-aware, or that traffic is being queued inconsistently — PTP depends on consistent queuing far more than on raw bandwidth.

PTP versus NTP

NTP is designed to be robust over arbitrary networks and settles in the milliseconds. PTP is designed to be accurate on a network you control, and reaches sub-microsecond time. Choose PTP when the application requires it, and be prepared to invest in the clock hierarchy, boundary clocks, and QoS treatment of PTP traffic — a PTP-aware design implemented without boundary clocks often performs worse than a well-run NTP deployment.

Related reading: Time-sensitive networking: 802.1Qbv scheduling, Junos MACsec on EX and QFX, WRED vs tail drop congestion avoidance.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/time-mgmt/topics/concept/ptp-boundary-clock-overview.html