means that the slave clock will take longer to lock because of the time that the messages are in transit, but theoret- ically it will still work. What is important is that the length of time that the packet is in flight is symmetrical in both directions. The golden rule is that half the asymmetry shows up as time error in the slave alignment. If the transit time is 10 ms in one direction and 15 ms in another, this would lead to a (15 - 10) / = 2.5-ms phase error. Similarly, accurate recovery of time with PTP does not automatically degrade with distance, although things like chromatic dispersion can introduce small asymmetry over long- distance fiber runs. If the PTP messages arrive without undue delay and are symmetrical in transit time, there is no theoretical limit to the distance one can recover accurate time using PTP. So, what is "undue delay"? This will be covered in more detail when we discuss packet delay vari- ation (PDV) in following chapters. For now, a practical example will suffice. Imagine that a Sync message is timestamped with the current master time and takes 100 us to arrive at the slave. Assume that this is the absolute minimal time possible to transit that path, counting dis- tance through fiber, and best-case switching time through devices. When the Sync message arrives, this is very valuable time data, since it has been stamped by a master with an accurate time source, and the message has arrived in the minimum time possible. The data is very "fresh." A clock getting a fair number of these messages (and the Delay_Req in the other direction) would quickly figure out that the tms was 100 us (from 200 us two-way delay) and that the timestamp was only 100 us old. So, add 100 us to the t1 timestamp, and that is what the slave clock time should be. Now imagine that the next Sync message (1/16 second later) is timestamped but is held up by some event and arrives 400 us after timestamping-rather than 100 us. That data is useless because it will show the slave time as 300 us off compared to the previ