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.
While the P2P is always more accurate than E2E, a similar thing can be said about 2-step. Usually the timestamping at PHY Hardware level has much less clock-jitter (when compared to a MAC timestamping hardware) and measure the exact time when the packet goes out, and usually the PHY timestamping requires a 2-step more. This is because by the time an Ethernet frame is started to get transmitted on the PHY, the opportunity to update the CF in its payload is long gone, so a follow-up message becomes necessary making it a 2-step clock.
While TCs can also be classified based on the the Transport, like Ethernet, or IPv4 or IPv6 etc but that is not currently relevant for the current article
Inter-operation of 1-step and 2-step
While it will be better to have the network planned such a way that all the nodes are 1-step or 2-step, but practically (especially mixing the devices from different vendors or capabilities) can have different clock-steps. However, we will see how these two work with each other.
The general idea is that when a TC is 2-step it always generates a follow-up message, while it may or may not get a follow-up (depending on the upstream node’s clock-step). On the other hand, when a TC is 1-step it does not need to generate a 2-step and in case it has received a follow-up from upstream, it may just forward the follow-up without modification.
So, we get into the following scenarios:
|1-step clock to 1-step TC||The corrections are straight-forward|
|2-step clock to 1-step TC||Corrections are put in Sync packet.|
Follow-up is forwarded without change.
|1-step clock to 2-step TC||Sync is forwarded without change.|
Follow-up is generated with Correction.
|2-step clock to 2-step TC||Sync is forwarded without change|
Follow-up is updated with Correction.
Please see the use of appropriate words forwarded/generated/updated in the above table. Only in the 3rd case (1-step clock to 2-step TC) the 2-step flag is changed to TRUE, while it remains the same in all other cases.
Note: The same interop logic can be extended to PDelay state-machine running in the P2P TC when there is mix and match of different clock-steps.