44:625.9 + 0.9 correctionField = 236.8 correctionField = 0.3 + 237.5 0.55 = 237.65 0.85 Transit time Transit time 0.60 0.05 0.60 0.05 = 0.65 ns = 0.55 ns Residence time = 207.4 ns Residence time = 237.5 ns Transparent clock Asymmetry corr. = 0.05 ns Asymmetry corr. = -0.05 ns (1-step, end-2-end) Origin TS = 144:7 Origin TS = 144:300 correctionField = 207.75 correctionField = 237.65 = 0.3 + 207.4 + 0.05 = 0.20 + 237.5-0.05 Transit time Transit time 0.70 + (-0.20) 0.70 (-0.20) = 0.50 ns = 0.90 ns T2 time = 144:241.05 T3 time = 144:651.1 Slave clock correctionField = 207.55 Origin TS = 144:300 time = master = 207.75 0.20 correctionField = 0.2 + 25.2 ns T2 = 144:7.3 + 0.65 + 207.4 + 0.50 + 25.2 Slave port on BC Figure 9-20 Simplified Example of the Use of correctionField in One-Step Clocks The originTimestamp and receiveTimestamp in PTP event messages only contain fields for seconds and nanoseconds, SO the sub-nanoseconds portion of a timestamp cannot be represented there. Besides carrying residence times, the other function of the CF is to represent the sub-nano- second portion of the timestamps (any configured asymmetry gets reflected there as well). The timestamp fields are 48 bits for seconds and 32 bits for nanoseconds. Some conventions: Although 1588-2008 does not describe it this way, you can consider the CF to have two subfields, nanoseconds, and sub-nanoseconds. Any nanosecond value (including sub- nanoseconds) pushed into this field gets multiplied by 2 16 , SO the lower 16 bits carry the sub-nano- second portion of the residence times and timestamps. This means that the CF ends up as a 64-bit number with the top 48 bits representing the nanoseconds and the lower 16 bits representing the sub-nanoseconds. In this example, as elsewhere in PTP documentation, timestamps are represented as seconds:nanoseconds (the seconds value in this example starts with 144, rather than seconds since the PTP epoch, to keep the number of digits reasonable). Figure 9-20 warrants some explanation. First, the slave clock is 25.2 n