any steps, and the clocks are perfectly aligned. So, assume that a Sync timestamp leaving the master would arrive 100 us later under ideal con- ditions. The slave would calculate OFM and MPD and arrive at the OFM value, which should equal 0 ns (as the clocks are perfectly aligned) and MPD of 100 us. Even without the mathemat- ics, you can see that the slave is basically adding the 100-us path delay to the received T1 timestamp. When comparing that adjusted value to its local time, it should show that they agree because the clocks are aligned and the path delay on those timestamps was exactly as expected. Assume that the next Sync timestamp took 400 us in the forward path (master to slave) and still only 100 us (Delay_Req) in the reverse direction. The slave would calculate that the round-trip time is 500 us and therefore assume that the MPD is 250 us (half the round trip). Then the slave would interpret the T1 timestamp as indicating the slave clock is 150 us too fast (it took 400 us to arrive, but the MPD is 250 us). So, the OFM would show the slave to be 150 us fast. In fact, it is perfectly aligned; the problem is that this series of timestamps has 300 us of asymmetry and therefore shows 150 us of error (half of 300). The OFM should normally average around the zero value, which is to be expected because that is the goal of the servo-it wants to converge on a state where the slave clock is aligned with the master clock. However, the OFM will not be zero for every set of timestamps, unless you have a perfect set of clocks and a perfect network. So, the value of OFM for every timestamp set is not SO important, but how it varies might tell you a lot about the network stability and the timestamp accuracy. When the slave clock is acquiring a master signal for the first time and is trying to align to it (to achieve PHASE-ALIGNED state), the OFM could start with very large values. If the slave has just gone into holdover and is switching to a new master, then the values should not be very large, unless there is a larg