a properly designed boundary clock trans- fers time, it should add only a very small time error (in the order of tens of nanoseconds) to the end- to-end phase offset. Chapter 9 and Chapter 12 cover more details of the performance of telecom profile boundary clocks. 7.4.1 Transparent Clocks There are two basic forms of transparent clocks: E2E TCs and P2P TCs. Those deployed in the tele- com profiles are E2E TCs, but some industry profiles, such as that supporting the power industry, use P2P TCs. This section examines both in some detail, but understand that depending on the pro- file and industry use case, one or the other (or both) may not be allowed. The idea behind using a TC is that by counting the amount of time the PTP event message was delayed, the slave can reduce the error in the recovered clock. Table 7-7 shows a simplified example of four messages that flow between a master and slave-they flow over the same path with two TCs between the master and slave. Table 7-7 Example Sync Messages Sync Message Time in Residence Time in TC- Residence Time in TC- Corrected Time in Flight Flight 250 us 20 us 30 us 250 - (20 + 30) = 200 us 350 - (100 + 45) = 205 350 us 100 us 45 us 210 us 210 - (5 + 5) = 200 us 400 - (50 + 155) = 195 400 us 50 us 155 us Given the four Sync messages were in flight for quite different times (between 210 and 400 us), then most of those Sync messages were delayed in transit (as captured in the TC transit times columns). Therefore, the timestamps on the event messages have "aged" and at least three of them would be useless to help calculate accurate values for clock offset and mean path delay. But if we correct the timestamps for the residency time inside the two TCs, then one can see that the corrected time in flight is now in the range of 195-205 us, which is much more useful. So, how is this done? End-to-End Transparent Clocks An E2E TC allows PTP traffic to pass through but will update a field (the correctionField) in PTP event messages to adjust for the time that the message was reside