Why do ordinary Ethernet switches degrade PTP accuracy, and how do PTP boundary clocks and transparent clocks each remove that error?
answer
- queueing that differs packet to packet
- terminate the exchange, or report the wait
- residence time goes into correctionField
- end-to-end versus peer-to-peer
basics
~20 sA switch queues each PTP message for a varying time, which lands in the slave's offset. A boundary clock terminates PTP and re-serves time from its own synchronised clock; a transparent clock forwards messages and adds each one's residence time to correctionField.
solid answer
~50 sPTP, like NTP, computes offset from an exchange of timestamps and assumes the path delay is the same both ways and steady between messages. A store-and-forward switch breaks that: each message waits in a queue for a different time, in each direction, and the difference turns straight into offset error. IEEE 1588 gives switches two ways to take part. A **boundary clock** has a slave port toward its master, synchronises its own clock, and acts as master on its other ports — so every link is a short, separately measured exchange and queueing never sits inside a measured path. A **transparent clock** stays out of the master–slave hierarchy: it timestamps each event message at ingress and egress in hardware and adds that **residence time** to the message's `correctionField`, which the slave subtracts. Peer-to-peer transparent clocks also measure each link's delay.
go deeper
Recall that switches delay PTP messages by varying amounts, and that PTP-aware switches either act as clocks themselves or report how long each message waited.
Explain the boundary clock's slave port and master ports, the transparent clock's residence time in correctionField, and how end-to-end and peer-to-peer transparent clocks differ.
Show how you would spot an unaware hop from a slave's offset noise, and choose boundary or transparent clocks per segment by chain depth, master load and path changes.
Weigh accumulated servo noise in boundary-clock chains against the hardware and security cost of rewriting messages in flight, and decide where the time domain is split.
## Why an ordinary switch hurts The **Precision Time Protocol (PTP)**, defined by IEEE 1588, works out a slave clock's offset from timestamps on messages exchanged with its master — `Sync` from master to slave and, in the end-to-end mechanism, `Delay_Req` back. Like NTP's calculation, it assumes the path delay is **the same in both directions** and **steady** across the exchange. A store-and-forward Ethernet switch violates both: - Each message waits in an output queue for a time that depends on whatever other traffic is there, so the delay varies packet to packet (**packet delay variation**). - The queue on the way down is not the queue on the way up, so the two directions differ. - Half of any unaccounted asymmetry appears directly as offset error. - Giving PTP a high-priority queue helps, but it only shortens the wait; it does not measure it, so the remaining variation still reaches the slave. Hardware timestamping at the endpoints removes host-stack error, but it cannot see inside a switch. IEEE 1588 therefore lets the switch join the protocol, in one of two ways. RFC 7384 groups both as **intermediate clocks**, and RFC 8575 models both. ## Boundary clock: terminate and re-serve A **boundary clock (BC)** is a PTP clock with several ports: 1. One port, chosen by the best master clock algorithm, is in the **slave** state toward the upstream master. 2. The BC synchronises its own clock through that port. 3. Its other ports act as **masters**, sending fresh `Sync` messages stamped from the BC's own clock to the clocks below. PTP event messages do not cross a BC: each hop is a separate, short master–slave exchange, so a switch's queueing is never inside a measured path. Each BC adds one to `stepsRemoved`, the number of communication paths to the grandmaster (RFC 8575). The costs: every BC runs its own servo, so noise accumulates down a long chain, and a mistuned BC degrades everything below it. In return the grandmaster serves only its direct neighbours, and each BC absorbs the delay-measurement load of its own clients. ## Transparent clock: report the wait A **transparent clock (TC)** does not synchronise anyone and is not a master. It forwards PTP messages, but timestamps each event message as it enters and leaves, in hardware, and adds the difference — the **residence time** — to the message's `correctionField`. RFC 7384 describes exactly this, citing IEEE 1588's clause on the correction field. The slave subtracts the accumulated correction, and the switch's queueing drops out of the calculation. There are two kinds, matching the two delay mechanisms RFC 8173 and RFC 8575 model as `e2e` and `p2p`: | | End-to-end TC | Peer-to-peer TC | |---|---|---| | Corrects | residence time on `Sync` and `Delay_Req` | residence time plus the upstream link's delay | | Link delay measured | end to end, slave to master | per link, with `Pdelay_Req` to each neighbour | | Load on the master | every slave's `Delay_Req` reaches it | none beyond its own link | | After a path change | slaves re-measure the whole path | link delays are already known | ## One-step, two-step and security A TC or master that can rewrite a message as it leaves works in **one-step** mode. A **two-step** clock — RFC 8575's `two-step-flag` — sends the precise time in a following message instead. That matters for security: RFC 7384 notes that because a TC modifies `correctionField` in flight, integrity protection must either exclude that field from an end-to-end check or be re-applied hop by hop, and that two-step timestamping avoids having to encrypt after timestamping. ## Choosing between them - **Boundary clocks** suit large or segmented networks: they split the domain, reduce load on the grandmaster and contain faults, at the price of servo noise per hop. - **Transparent clocks** suit flatter networks where accumulated servo noise would hurt and every switch can timestamp in hardware. - **Mixed designs** are common; what is not acceptable is a PTP-unaware switch on a path that needs sub-microsecond accuracy, since its queueing goes uncorrected. The same idea is reaching NTP: the NTPv5 Internet-Draft (draft-ietf-ntp-ntpv5-09, a draft rather than a standard) defines a **Correction** extension field with the same format as PTP's `correctionField`, so switches and routers could report residence time for NTP too.
- What breaks if one switch on a PTP path is not PTP-aware?Its queueing delay varies per message and per direction, and nothing measures it: it is neither inside a boundary clock's terminated hop nor reported in `correctionField`. The slave sees that variation as offset noise, and any direction-dependent part as offset error. In a sub-microsecond design one such hop can dominate the budget.
- Why does a transparent clock not increment stepsRemoved, while a boundary clock does?A boundary clock is a new master for the clocks below it, so they are one more communication path from the grandmaster. A transparent clock is not a master; it forwards the grandmaster's messages with a correction, so clocks behind it still synchronise to the same upstream master.
- How can integrity protection coexist with a transparent clock rewriting messages?RFC 7384 gives two approaches: hop-by-hop, where each clock that modifies a message verifies it, updates `correctionField` and re-computes the protection; or end-to-end, where the protection covers everything except `correctionField`, which then needs its own integrity mechanism.
A transparent clock is a courier depot that writes on each parcel how long it sat in the depot, so the recipient can subtract the waiting. A boundary clock is a regional office that takes delivery, sets its own clock by it, and sends fresh parcels onward under its own name.
saying these in an interview costs you the question
- A transparent clock synchronises its own clock and re-serves time downstream.
- A boundary clock forwards Sync messages unchanged with a correction added.
- Hardware timestamps at the endpoints remove switch queueing error too.
- Any switch with a priority queue for PTP is as good as a transparent clock.
- With peer-to-peer transparent clocks, every slave still sends Delay_Req to the master.