Five Minute Facts About Packet Timing
By Doug Arnold.
One-step or two-step clocks for IEEE 1588? This is a question I hear a lot. If you are designing PTP enabled equipment, then it is a question, which has important ramifications for the architecture of your device. However, if you are buying PTP enabled equipment and integrating them into a network, it doesn’t matter at all. Furthermore, for the network architect, it doesn’t even matter if you mix one-step and two-step devices in the same network. Let me explain how one-step is different from two-step, and what the IEEE 1588 standard requires of devices, and my statements above will, hopefully, become clear.
The short version of how one and two-step clock work is just this: for any PTP event message, that is one which gets timestamped, the message either gets an accurate timestamp placed in the message on-the-fly as it is about to leave the device (one-step), or a second message carries the accurate timestamp (two-step). In the case of delay requests, a second message is required regardless since the timestamp has to be sent from one device to another, but sync messages, and peer delay response messages can be either one or two-step. Consider the message sequence diagram below depicting one-step end-to-end operation.
Note that this is simpler than the one depicted in the earlier post Why is 1588 so accurate? which describes two-step operation. There is no need for a follow up message, the sync is loaded with the accurate timestamp as it is leaving. A similar economy is seen in peer delay message exchanges.
Again notice that this is simpler than the two-step peer delay mechanism. There is no need for a peer delay response follow up message.
In the case of transparent clocks the difference between one and two step PTP is significant. The diagram below shows a sync message going through a transparent clock.
The transparent clock must intercept the sync message after leaving the switch core and update the correction field based on how long it sat in queues in the transparent clock. Contrast this with a similar diagram of a two-step transparent clock shown in What Are All Of These IEEE 1588 Clock Types?. In the tw0-step version the transparent clock doesn’t need to update the sync message on the fly, but it does need to remember how long it had the sync message for and update the corresponding follow up message. So if you are designing a transparent clock you have to ask yourself if I want to put a lot of effort into the hardware or software. One-step clocks require hardware capable of on-the-fly correction field updates. Two-step clocks require that the software remember the dwell time of a sync message and match it to the corresponding follow up message.
Earlier I made the statement that if you are not building the devices, but just buying them, then it doesn’t matter. But don’t you have to make sure that all the devices in the chain from master to slave use the same number of steps? The answer is no, because all slaves are required by IEEE 1588-2008 to work with either. That was an easy rule to make, since it is only hard to send one-step messages, not receive them. What about the case with a two-step master and a one-step transparent clock? Also no problem. The transparent clock will update the correction field in the sync message, and pass the follow up message through unaltered. The slave will sum the correction fields from both messages, as the standard requires. How about the case with a one-step master and a two-step transparent clock. Still no problem, but a little more work for the transparent clock, since it will have to set the sync step flag to two-step and generate the follow up message.
Isn’t one-step preferred because it uses less network bandwidth? Let’s do a little arithmetic. A follow up messages is 98 bytes for a UDP/IPv4/Ethernet mapping. That’s 784 bits. At a once per second rate that uses less than 0.0001 percent of a gigabit link. Even if there were 100 follow_up messages a second the bandwidth usage is trivial. Even if it were only a 10-BaseT link! For practical purposes assume PTP uses approximately zero bandwidth, whether it is one-step or two-step.
- 1588 onestep
- define ptp
- One Step ptp
- ptp delayresponse not received
- ptp one-step two-step
- what is one step timestamp in PTP