Why Transparent Clock
Transparent clocks are used in PTP topologies in order to improve the accuracy of the end-station synchronization. The reason is that time-unaware devices introduce varying amount of path-delay between the clock-source (master) and end-station (slave). Unless the master and slave are directly connected, or all the devices in between then are time-aware the inaccuracy increases due to varying amounts of queue-delays and path-delays of different nodes and links.
How Transparent Clocks work
Transparent clocks are much simpler that full-featured Boundary clocks because the aim of a transparent clock is to make itself invisible (of sorts) from their own effect on transport of time across the PTP topology. They do this by timestamping PTP packets as they ingress (with a timestamp T1) and at egress (with a timestamp T2) and putting this delta-difference (T2 - T1) as a correction-field (CF) in the PTP packets. Such a device (called an End-to-End or E2E TC) removes its internal delay (and thus delay-variation) by informing the end-station about its own CF.
Types of Transparent clocks
There are 2 types of Transparent clock:
- The ones that measure their own delay (E2E)
- The ones that also measure the link-delay (P2P)
The additional logic in the latter TC is that, it uses PDelay_Req and PDelay_Response packets with its peer-device to calculate the link-delay and adds that to the residence time (T2-T1) calculation ie.
Correction Field = Link Delay + Residence time
There is another way to classify Transparent clocks:
- The ones that use 1-step clock
- The ones that use 2-step clock
The difference in the latter is that they use a Follow-up message to convey the Correction-Field as they cannot update the delta (residence time) on the fly.
...that's not all folks!
(c) AVChrono 2021, All Rights Reserved