Five Minute Facts About Packet Timing
By Doug Arnold.
If you are new to the exciting world of IEEE 1588, or even if you are not, you might find yourself confused by all of the different types of clocks. I’ve heard and seen the following terms used related to PTP:
- ordinary clock
- master clock
- slave clock
- slave only clock
- grandmaster clock
- preferred grandmaster
- server
- client
- transparent clock
- boundary clock
What the heck! Is PTP really that complicated? Certainly that appears like a lot of device types, but we can sort this out quickly.
Let’s start with an ordinary clock. This is an end device on a network (as opposed to a switch or router). It comes in three flavors:
- Slave only clock. This one is pretty self explanatory, it always acts a slave, receiving time from a master clock.
- Preferred grandmaster. This is a device which only acts as a master, never as a slave. Usually such a device is referred to simply as a grandmaster. Generally a grandmaster has a good oscillator and the ability to get standard time, for example from a GPS receiver. One has to be careful though since the IEEE 1588 standard considers grandmaster to be a state of a grandmaster capable device, i.e. the state when it is acting as the source of time in a PTP network.
- Master clock or slave clock. This kind of ordinary clock can act as either a master or slave. Usually it acts as slave unless there is no better master available in the network, in which case it takes over that function and becomes the grandmaster.
Some people don’t like to use the terms master and slave, since it reminds them of ugly aspects of human culture and history. So instead they prefer to use the terms server and client. However, traditionally in information technology a client initiates a transfer of information by asking a server for the information. Think of a web browser (client) and web server. In contrast a slave is more passive and waits for the master to initiate the transfer. So there is value in preserving the distinction between the two pairs of terms. I will make the following moral statement: When people are masters and slaves, it is bad. When electronic devices are masters and slaves, it is just fine.
OK, enough about that. We still have two kinds of clocks to define, and they are, in some ways, the most interesting. As I mentioned in an earlier post, PTP achieves accuracy when hardware timestamping is used. This allows us to circumvent the unpredictable delays in queues. Well folks the worst queuing noise is often in the switches and routers. So IEEE 1588-2008 has defined two types of switches (or routers) which specifically deal with their own queues. One device is called a transparent clock. This type performs hardware timestamps whenever a sync message arrives or departs the transparent clock. Consider the transparent clock block diagram shown below. A sync message enters the device, a hardware time stamp is generated it then enters the core switching element and departs through a different network port. While in the core switching element it might have to wait in a queue, since the port it needs to leave could be busy. The departure and arrival timestamps are used to update the correction field in the follow_up message. This is how it works for a two step transparent clock. If the transparent clock is a one-step clock, it updates the sync message, which also has a correction field, on the fly instead. More on one-step clocks in a future post. Note also that in a network which uses the peer delay scheme the ingress cable delay is also added to the correction. In a network which use end-to-end scheme a similar correction is made to a delay_response message to correct for the queuing of the delay_request message.
Transparent clock block diagram showing the flow how a follow_up message is corrected for the queuing delays experienced by the sync message
A boundary clock has another way of removing the effects of its own queues. A boundary clock has one port which is in a slave state, getting time from a master clock. All other ports are in a master state which disseminate time to downstream slaves. So instead of tracking sync messages and updating correction fields it absorbs sync messages in the slave port, uses that port to sets its clock, and generates new sync messages from this clock out of all of its master ports. Note that the master ports, are masters, but not grandmasters, since they are merely re-timing from an upstream grandmaster or boundary clock. See the diagram below.
Boundary clock block diagram, showing how a sync messages in absorbed in the slave port and a new one generated for a master port.
If you have any questions about PTP or hardware timestamping, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.
I assume that a transparent clock would calculate the “residence time” using the PTP network “time” as reference – i mean its own clock would be synchronized to network time, and it would use this clock to calculate residence time. Now, how does it synchronize to PTP network clock?
In some cases a device containing a transparent clock (TC) will synchronize itself to PTP time and use the PTP steered clock to measure the residence time. Just as you suggest. In this case we think of the device as including both a TC and an ordinary clock in the slave state. The slave is responsible for setting the time. Usually this would be done in conjunction with the peer delay network propagation measurement mode. That way the slave hidden in the TC would not have to issue delay request messages.
However, this is not how most TCs work. Because residence time is a time interval, the TCs clock does not have to be synchronized to PTP time. The TC determines the residence time from the TC ingress timestamp from the TC egress timestamp. Since both timestamps are generated by the same clock, it doesn’t matter if that clock is offset from PTP time. The offset will cancel out.
That is, the offset will cancel out as long as it doesn’t change while the message is in residence. For this reason many TCs will syntonize to PTP time. In other words they set they adjust their frequency to be the same as the PTP master, but without regard to a constant phase offset. The good thing about this scheme is that only the sync (and follow_up for two step) messages are needed. The propagation delay to the master is needed for time, but not frequency. So even in a delay request/response PTP network the TC could syntonize its clock just by looking at the PTP messages passing through.
How frequency synchronization is done with help of ptp ?
I mean how TC will frequency synchronize with PTP time with just help of sync message ?
I am new to this area could you please help me understand this .
This is an important question. A Transparent Clock (TC) does not actually need the PTP domain time, since the residence time is actually a time interval. So if the TC has a time offset with respect to the PTP domain, then the offset will cancel out when the received timestamp is subtracted from the transmit timestamp. However, if the frequency of the TC is off, then the TC time offset will be different between the receipt and transmission timestamps, leading to an error from the difference in offsets. For this reason, manufacturers of TCs, will either make sure that they use a sufficiently high quality oscillator in a switch with TC capability, or they will design the TC to syntonize (frequency synchronize) to the PTP domain time.
Hi,
As you mentioned that for BC one port needs to be slave and other to be master, if this is also the requirement for TC.
Please clarify if this criteria can be used to determine if a switch is BC or TC.
Can you please also mentioned the source of this argument? Thanks
TC ports do not have states. Transparent clocks are undetectable from within PTP.
Hi Douglas,
The articles you posted about IEEE 1588 are really educational. Here is a question to me.
I just started exploring more about PTP and different clocks associated.
It is my understanding that, ordinary, boundary clocks acts as master/slave devices, but not doing any residence time calculations, where the accuracy might have lag.
Which is why IEEE 1588v2 introduced a new clock called Transparent clock, wherein with the help of E2E/P2P delay mechanisms, devices are getting synchronizing accurately.
Please correct me, if am wrong. Thanks in advance !!!
You are correct that Ordinary Clocks and Boundary Clocks do not calculate residence time, however they do not need to. An ordinary clock is a one port device which does not queue messages for transmitting from another port. So as long as the PTP event messages are timestamped at the MII interface in the network stack, accuracy should be good. Boundary clocks recover the PTP domain time on the slave port. That same clock is used to create new Sync messages, with new timestamps, at the master ports.
Hi Douglas,
In a previous comment you said : “…Because residence time is a time interval, the TCs clock does not have to be synchronized to PTP time. The TC determines the residence time from the TC ingress timestamp from the TC egress timestamp. Since both timestamps are generated by the same clock, it doesn’t matter if that clock is offset from PTP time. The offset will cancel out…”.
This is not right. For example….suppose two people measure the distance of a runner using two different clocks, one clock is faster than the other, one person will measure Χ time and the other Y time for the same distance. The Time error if the clock for measuring the residence time is not syntonized to G.M is : Residence time (using G.M clock) x PPM (frequency difference between G.M and the other…in time base). For example for 1ms residence time and with 100ppm frequency difference the time error is 100ns. Am i wrong ?
I see someone was paying close attention. If the TC has a time offset from the time of the PTP domain, then it will not affect the determination of the dwell time of an event message in the TC. However, you are correct, in that if the frequency of the TC is off, then there will be an error in the estimate of the dwell time, which will be proportional to the frequency error times the dwell time. For most TCs, either the local oscillator is good enough to keep the frequency error small, or the typical dwell time is small, or both. However, some TC implementations syntonize the frequency of the local clock to the PTP domain, in order to minimize this error.
Hi,
I want to ask that in the case for boundary clock, is the follow up message computed as follows:
new follow up = old follow up + (departure new sync – arrival old sync)
Thanks.
Sync Follow_up message sent by a Boundary Clock are not directly created from messages received on the BC port in the slave state. Rather the BC system time is steered to the time received on the slave port, and new Sync and Follow_up messages are created based on the BCs clock, and transmitted on the master ports.
Hi,
We have a switch/router that has a clock crystal of 25MHz +/- 50 ppm and the requirement is to implement Boundary clock on the product. I am assuming the full PTP stack has to be implemented on the system CPU to get the full Boundary clock functionality.
Do you think it is feasible to run the switch software and the PTP Boundary clock software on the same CPU or should there be a separate dedicated CPU to run the PTP stack implementing BC. The ASICs and PHYs used on the platform implement 1588v2 in hardware.
My question Will the product be able to implement BC accurately.
– with the current clock or should it be more accurate like +/- 50ppb and should it be OCXO?
– does it need dedicated CPU to run the PTP BC algorithms
Thanks
Sindhu
The BC algorithms will most likely be able to run using a fraction of your main CPU without requiring a dedicated CPU. PTP is not that complicated for a modern CPU unless it is a very low end one.
I would need to know more about the timing requirements for the application that the BC is expected to support to know if you would need a better oscillator. The BC will add jitter to the PTP time transfer due to the short term instability of the oscillator, and due to the resolution of its time stamping counter. The asymmetries of the Ethernet PHYs also add a quasi static error. The end user will want to know the total worst case error it can expect each BC in the network to contribute to figure out if your BC will be good enough. The 25MHz +/- 50 ppm would probably be good enough for bank trying to meet the MIFID II 100 microsecond requirement through a few hops, but probably not for a switch supporting wireless backhaul that requires 1.5 microsecond total network error.
Hi Douglas,
I would like to ask a tricky question which confused me: For a grandmaster clock, when it contains more than one PTP ports but these ports are all in the master state, is it called an Ordinary Clock? Because the definition of the Ordinary Clock indicates that an OC only contains one PTP port. But in the case of the grandmaster clock with multiple PTP ports in the master state, these PTP ports are actually synchronized. Thx!
This is a tricky question, but an important one. As you correctly stated: an Ordinary Clock can only have one PTP Port. One possibility is to consider it a Boundary Clock that is currently in the Grandmaster state. In the International Telecommunications Union network timing working group (IUT-T Q13/15) standards the node is considered to be a Boundary Clock connected to an internally embedded Ordinary Clock in the Grandmaster state through a “virtual port”. Either of these are consistent with the standard. The only difference between these two interpretations is the steps removed value.
The node could also be a multiport PTP capable device where each port is an Ordinary Clock. If the ports are operating with unicast PTP, or if the ports are connected to isolated networks, then each port is Grandmaster in a different domain. Note that PTP Nodes are in different domains if the networks are isolated even if the domain numbers are the same. However in the case of multicast PTP, if the ports see each other’s Announce messages, i.e. connected networks in the same PTP domain, then all but one of the ports would go into the passive state, due to the BMCA.
Hello Douglas
Impressive stuff as always. Your blogs are as usual education and gives deep insights. I have a few questions related to the attributes in the Announce message generated by Boundary clock like the ‘ Time Source’
as Per the standard, time source is defined as
This information-only attribute indicates the immediate source of time used by the Grandmaster PTP Instance,
So do you reckon the time source attribute in the Announce message generated from BC should be that of the Grandmaster?
Lets say in for our sake of conversation , GM is distributing time in the PTP network through GPS . So should it be Ox20?
I agree. The BC is required to pass on the credentials of the GM. So whatever the GM states for time source, the BC is required to state as well.
PTP it should be frequency domain with profile G_8265_1. The IPs provided below are the grandmaster IPs and are defined on the core: