nc message was sent, and the slave believes it knows what time it is when the message arrives. If the transit time from the master to the slave was 0 ns, then the slave could simply set its clock to be the same as the t1, and it would be perfectly aligned. But of course, tms is greater than zero, SO the slave must try to figure out how long the Sync message was in flight SO that it knows how "old" the t1 timestamp was when it was received, and it can correct or compensate for it. To do this, the slave sends another time-sensitive Delay_Req message (with a transmit timestamp of t3) back to the master. That Delay_Req message also has a non-zero transit time, which is known as tsm, and again, must not be unnecessarily delayed in order to recover the most accurate time. The master records the time of arrival of the Delay_Req as t4 and reports that value back to the slave in a Delay_Resp message. As with Follow_Up, the Delay_Resp is more of a reporting message, "this is the last t4 from the master." It is the duty of the slave to periodically generate the Delay_Req message, and the master is re- quired to answer with a Delay_Resp. With this protocol flow, the slave is in possession of all the t1, t2, t3, and t4 timestamps that allows it to determine the time it should be on the slave when the Sync message was received. This transaction is repeated frequently, with the exact value determined by a combination of the use-case needs or the limits of the profile. For some profiles, it is fixed at 16 messages per second, but for some others, it can range from a high of 64-128 per second down to once every 8 seconds or 7.3.1 The (Simple) Mathematics Now that the slave has the t1, t2, t3, and t4 timestamps, it has enough information to recover the time. Remember that t1 and t4 are measured using time on the master, while t2 and t3 are measured using the time according to the slave. There are several terms defined in 1588 that are used on PTP implementations, SO it is helpful to in- troduce them here as they may appear in the 