Five Minute Facts About Packet Timing
By Doug Arnold.
Which delay measurement mechanism is best for deploying IEEE 1588? Since I’m an engineer, the answer is, of course, it depends. The short answer is that the peer-to-peer delay measurement mechanism is best in an engineered network, where all switches (and routers if there are any) can be guaranteed to be 1588 capable, i.e. they are either transparent clocks or boundary clocks. If there are going to be any non-1588 aware switches, or if there is any doubt about this, then you want the end-to-end delay measurement mechanism.
Why this is the case should become apparent as we review how these two mechanisms work. The end-to-end delay mechanism was described in my previous posting, Why is IEEE 1588 So Accurate. In peer-to-peer networks the master still sends Sync and Follow_Up messages to the slave clock just as with the end-to-end delay measurement mechanism. With peer-to-peer the slave calculates its clock offset with respect to the master as follows:
slave time = master time + network delay.
No need to combine four timestamps like we did with end-to-end networks. But wait, how did the slave know the network delay? That is the magic of the peer-to-peer delay measurement mechanism. Instead of sending delay measurement messages from the slave to the master, as with the end-to-end approach, each device on the network exchanges peer-delay measurement messages. That way each device can keep track of the delays between itself and its immediately connected neighbors. The diagram below shows how this works.
Each device periodically initiates an exchange of peer-delay messages on every connected port. Then each device removes the peer-delay from Sync messages when it enters the device, by updating the correction field in either the Sync or Follow_Up message. If its a switch, it doesn’t include the peer-delay in the out going cable, even though it also knows that. The next device in the chain will do that correction, and we don’t want to double count.
The sequence of peer-delay messages looks like this:
Clock A wants to know the delay to Clock B. So it sends a Pdelay_Req messages, short for peer-delay request. Clock A also saves the time it sent that message, t1. Clock B saves the time, on its clock, when this message arrives, t2. Then Clock B sends a PDelay_Resp message, short for peer-delay response, and a Pdelay_Resp_Follow_Up. The follow up message contains the departure time for the Pdelay_Resp, t3. Clock A also saves the arrival time of the Pdelay_Resp, t4, so it has all of four timestamps and can calculate the delay between the clocks. If you saw my earlier post, where I described end-to-end delay measurements, this all looks pretty familiar, and it turns out we have to deal with the whole four timestamp business anyway. Clock B will also initiate the same series of messages in the reverse direction so that both clocks know the peer-delay.
Here, as with the end-to-end mechanism, the assumption is made that the time it takes for the peer-delay messages to get from one clock to the other is the same in each direction. In the peer-to-peer case we only making that assumption over a cable, not the whole network, and there are no queues. So unless the cable is very long, that is a good assumption.
What about the queues in the switches? At the beginning of this post I said that peer-to-peer only works well when every switch is either a transparent clock or a boundary clock. That way the switch will take care of its own queuing delays. Another reason that we don’t use peer-delay with ordinary switches is that the switches don’t know what to do with peer-delay messages, and will not respond to them.
Although the end-to-end mechanism is more versatile, because it can handle ordinary switches and routers, the peer-to-peer mechanism has several advantages in networks where it does work:
- All links are periodically measured, so delay between the master and slave are already known when the network path changes. Note that peer-delay messages are exchanged even on ports blocked to prevent loops, such as by the Rapid Spanning Tree Protocol.
- There is no chance of Sync and Delay_Request messages taking different paths, since there are no Delay_Request messages.
- There is no need to worry about the master clocks ability to respond to Delay_Request messages when there are a lot of slaves, it only has to send the Sync and Follow_Up.
- 1588 transparent clock end to end
- dgs3420 e2e ptp
- difference between end to end and peer to peer networks
- pier to pier ptp
- ptp boundery clock p2p
- ptp e2e vs p2p
- ptp rogue peer delay
- solarflare ptp end to end vs peer to peer