lect the most accurate master. The Announce messages are shown being regularly transmitted from master to slave in Figure 7-2. More details are provided in the section "The Announce Message" later in the chapter. Meanwhile, Figure 7-2 shows how the other four messages work together to transport time. Transit time from M-S Slave knows t1t2 Master Slave Transit time Slave knows t1t2t3 from S-M Slave knows t1t2t3t4 Annonce Figure 7-2 Message Flow Between PTP Master and Slave Ports Before looking at the mathematics, it is better to discuss the mechanism and the concepts. The first thing to happen is that the master informs the slave of the current time. To do so, the master trans- mits a Sync message and notes the time, t1, that the message is sent. The master can either place that t1 timestamp inside the Sync message itself or send it a very short time later in a Follow_Up message. There might be good implementation reasons for either approach, but maximizing the ac- curacy of the timestamp is the main factor (some devices might find it difficult to accurately timestamp a message while trying to transmit it). When the Sync message arrives at the slave, its time of arrival (according to the slave clock) is noted as t2, but of course the message took some unknown transit time to get there (what we will call transit-time master->slave, or tms). How the Sync message is handled in-flight directly affects the accuracy of the time that the slave can recover, SO for accurate timing, the Sync message needs to be handled with utmost priority. Needless delay "ages" the timestamp with the consequence that the timestamp data quickly becomes useless. Remember that the protocol allows that the Sync message does not need to carry t1, allowing it to arrive a little later in the Follow_Up. The Follow_Up message is not a time-sensitive message, but more of a reporting function, "the master is sending the t1 that reflects the departure time of the last Sync message." So, at that point, the slave knows the time on the master when the Sy