Five Minute Facts About Packet Timing
By Doug Arnold.
This is a very brief introduction to the Best Master Clock Algorithm. For a more detailed description refer to the more detailed post: BMCA Deep Dive.
A key to the resiliency of the Precise Time Protocol is the Best Master Clock Algorithm, or BMCA. The BMCA allows a clock to automatically take over the duties of Grandmaster when the previous Grandmaster loses its GPS, gets disconnected due to a switch fault, or for what ever reason is unable to continue as Grandmaster.
To understand how this works consider a day in the life of an Ordinary Clock. Recall from a previous post that an Ordinary Clock can be designed such that it is capable of acting as either a master or a slave. The states that this clock can be in are shown in the state diagram below:
After power up the first thing the clock does is “listen”, in other words it look for Announce messages from the PTP general multicast address. An Announce message contains the properties of the clock which sent it. If the Ordinary Clock sees an Announce message from a better clock it goes into a slave state, or passive if it is not slave capable. If the Ordinary Clock does not see an Announce message from a better clock within the Announce Time Out Interval, then it takes over the role of Grandmaster. This runs continuously so master capable devices are constantly on the look out for the possible loss of the current master clock. For this reason it is critical that the Announce Time Out Interval be set longer than the Announce Interval in your network. If you don’t then master capable devices will keep jumping to the conclusion that the master has gone away and they need to take over. Its like a bunch of political pundits on a talk show who never listen and keep talking over each other.
OK. So I have already used up two of my five minutes and I still haven’t told you what makes one master better than another. Let’s get right to it. The list below shows the criteria in order of precedence.
- Priority One Field: This is an 8-bit user settable value. The lowest number wins. Normally this is set at 128 for master capable devices and 255 for slave only devices. However, if you want to overrule the normal selection criteria you can change Priority 1 and create any pecking order you wish.
- Clock Class: This is an enumerated list of clock states. For example a clock with a GPS receiver locked to Universal Coordinated Time has more class than one which is free running and set by hand to your wrist watch. There are also states for various levels of holdover when a clock which had a GPS receiver lost the connection.
- Clock Accuracy: This is an enumerated list of ranges of accuracy to UTC, for example 25-100 ns.
- Clock Variance: This a complicated log scaled statistic which represents the jitter and wander of the clocks oscillator over a Sync message interval. In fact it so complicated that if you can accurately determine it for a clock then you get three credits toward a degree in mathematics.
- Priority 2 Field: You guessed it, another user settable field. The main purpose at this low end of the decision tree is to allow system integrators to identify primary and backup clocks among identical redundant Grandmasters.
- Source Port ID: This is a number which is required to be unique, and is usually set to the Ethernet MAC address. Essentially this is a coin toss which is guaranteed to break a tie.
One last complication is Steps Removed. If two boundary clocks are getting their time from the same Grandmaster, then the one which is connected to the Grandmaster through fewer Boundary Clocks is better. Transparent clocks don’t contribute to steps removed because they are, … well transparent.
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.
Hi Sir,
I’m trying to implement Multicast PTP for LTE backhauling. In my tests i have faced with an interesting situation. We have a topology like follows:
GM -> BC1 -> BC2 -> BC3 -> BC4 -> DelayMeasurementDevice
The point, when i check the PTP status of BC4, it shows the GM clock id as correct, but it shows the parent clock as BC1 rather than BC3 !! But even in that case, its aware of BC3 and BC2. (There is a command which is called ‘neigbours’ and they are listed there)
I couldn’t figure it out what is causing this. Your assistance will be very much appreciated. (Sorry for grammer mistakes)
You are correct that something is not right. IF the GM fails or loses connection to the network, then BC1 might take over as GM, if it is the best remaining clock, but then it should distribute its own clock ID. Alternatively BC1 may be failing to updates its parent data set. IEEE 1588-2008 calls for clocks to populate the parent data set with their own attributes on initialization, and then replace them with them later with the master it synchronizes to. Perhaps this is not properly implemented in BC1. Are all of the BCs the same make and model? If not then it would be interesting to switch the order of the BCs and try again.
Hi Douglas,
I’m studying PTP protocol. I want to know the rules to set a node as Grandmaster, i.e., the requirement of a node to be Grandmaster-capable. Can you answer this question to me? Thanks a lot.
First, any Ordinary Clock or Boundary Clock can, by design, be grandmaster capable. It assumes the role of grandmaster for the network if there are no “better” clocks. Clocks discover each others properties by the fields in each clock’s Announce messages. A master capable clock sends Announce messages if it does not receive Announce messages from a clock with better properties. The properties are in order of precedence:
1. Priority 1 (8 bit configurable field)
2. Clock Class (does the clock have a GNSS receiver, is it locked, etc)
3. Clock Accuracy (chosen from defined performance bands in the standard)
4. Clock variance (i.e. the stability of the local oscillator)
5. Priority 2 (8 bit configurable field)
6. Clock ID (unique id number, often the Ethernet MAC address)
Hi Douglas
i have one question. Why we have 2 user config Priorities ( P1 & P2 )? Suppose we have two T-GM in a ring both are connected to GNSS, if we keep T-GM one P1 as 126 it will be GM now if we lose GNSS on this GM will the BC’s switch to T-GM no 2? how we can make it revertible ? thanks
Why do we have two priority fields? When assessing whether one clock is better than another one, the Priority 1 field is considered before looking at any of the properties of the clock like accuracy, etc. The priority 1 field is configured by an operator who wants to select the priority of the clocks herself, rather than letting the protocol do that automatically by comparing clock properties.
The priority 2 field is only considered after the clock properties, so it only matters if the clock properties of clocks are identical. The purpose is for the operator to choose which identical clock will be primary and which will be backups.
Since the Best Master Clock Algorithm runs continuously, the network will always revert to the best clock, even if it was unavailable for a while, or not the best clock for a while. For example clock A has a better oscillator than clock B, but is otherwise identical. Clock A will be the grandmaster. However, if clock A loses lock to GPS for a while it will degrade its clock class, and Clock B will take over. If Clock A recovers lock to GPS it will become the best master again.
Is there any sync connectivity model for the 5G network
Hello All,
I was reading this blog and have some queries regarding Grandmaster selection.
Lets say, I have Two Grandmaster clocks in my network and my devices are receiving PTP time through both the clocks.
In this case, devices should select Grandmaster based upon Clock parameters (such as Priority1, class, accuracy etc.)
Given that below are the parameters of Grandmaster clocks, which clock shall be elected as the Best Grandmaster clock ?
(I need to understand how the values are compared and selection takes place)
Grandmaster clock 1:
Prority1 : 128
class : 6
accuracy : 32
offset (log variance) : 65535
Priority2 : 127
Grandmaster clock 2:
Prority1 : 128
class : 248
accuracy : 48
offset (log variance) : 65535
Priority2 : 128
If you are running PTP in mulitcast mode, then slaves clocks do not have to decide which GM to sync to, since the GMs will do that automatically. All GMs which are not the best clock will go passive and not send sync and announce messages.
If you are running unicast PTP, then a node on the network can ask for, and receive sync and announce messages from as many GMs as it wishes. What does it do with the timing information that shows up? Whatever it wants, since it will not effect other clocks on the network. The slave clock could ensemble the time corrections, run a voting algorithm or select the best GM.
By the way the BMCA works as a prioritized list of attributes. First the Priority1 fields are compared. If a GM1 has a lower Priority1 field than GM2, then it is “better” regardless of the other clock attributes. If the two GMs have the same Priority1 field, then the one with the lower Clock class number wins, etc. So in your exmple GM1 is considered best, due to its lower clock class value. Note that GM1 also has a better accuracy value, but that is not considered once there is a difference in class values.
Hello Douglas,
Thanks for your swift reply ….
Further to my question, I want to know if there is any way with which we can control Grandmaster clock election in a network setup ?
For e.g: In a network setup, One Grandmaster clock is connected and all devices are treating it as a best Grandmaster.
Now by any means if any rogue Grandmaster gets connected in a network, there are chances that this rogue Grandmaster can become Best GM for entire network setup.
Is there any security mechanism in PTP to deal with such situation ? such as statically defining a list of Grandmasters on devices, so that only GM from that list will be eligible to get elected as a Grandmaster ?
Hi,
I’m studying 1588 and am currently looking at the BMCA. I was wondering what will happen if a GM fails…
Do I understand correct that it can take quite a while before the network settles on a new GM? (As every bridge will only accept a new vector after the announce receipt timeout expires, this can cascade into quite a delay before the new GM is known in every bridge or end-station)
Or is there a mechanism that speeds up this re-election?
Good question. If the bridges are Transparent Clocks, the the switch over to a new GM will be relatively quick, one announce receipt time out plus two announce intervals for foreign master qualification. This might be something like 5 seconds, depending of the profile, or PTP configuration. If the bridges are Boundary Clocks, then the transition time for the BC connected to the new GM will be as above. Each BC in a chain from that
Case 1: All bridges are TCs. The switch over will require 1 announce receipt timeout, for the new GM to go from PASSIVE to MASTER, then two announce intervals for the slave to perform foreign master qualification on the new master. All this typically takes about five seconds, but depends on the announce interval and announce receipt time out settings.
Case 2: All bridges are BCs. In this case the BC attached to the new GM, will take about five seconds as above. Each down stream BC will take two announce intervals to qualify the new master, but in the mean time will continue to send its holdover time on its master ports.
If their is a time difference between the old master and the new master, then it will take the BC network awhile for all of the servo-loops to settle down. The TC network will make the time step immediately since they perform no averaging.
Dear Mr.Arnold,
I have read the whole IEEE 1588 V2, and I believe I understand most part of it. However, there is still a question that I cannot understand:
In multicast scenario, at the very beginning of a PTP network when OC/BC need to discover each other, do every OC/BC broadcast a Announce message?
If so, then the 1st Announce message of BC is carrying the clockInfo of itself, which may change if the GM is not itself.
After that, if the BC finds out it is not the GM, it will update the parentDS, and its next Announce message will be carry the clockInfo of the GM.
So can we say the PTP network need multiple cycle to finally settle the tree structure?
Did I miss something is the document?
Hope my question is clear enough.
Best,
Mario
Hi Douglas
Thank you for all the information.
Could you tell me wether or not devices with a priority 1 >128 are also considered as a Master or not?
I find some conflicting information about this. Should it be =<128 or =<255 ?
Thank you very much
Best regards
EC
A PTP Port can be in the MASTER state with any value of priority 1.
A PTP port cannot be in the SLAVE state unless it has a Clock Class of 128 or higher. Perhaps that is the source of the confusion.
In a packet capture of PTPv2 messages, is there a field that identifies a device as the GM?
No. That would be useful though.
Here is what you can do. If an Announce message has a stepsRemoved value of zero, then it is from the Grandmaster, rather than a Master port of a Boundary Clock. Every PTP message contains the clockIdentity field. So you can determine the clockIdentity of the GM when you see an Announce with stepsRemoved = 0. Any message with that same clockIdentity is from the GM.
It’s even easier if you have PTP Track Hound, the free PTP message capture tool which will identify the GM if the computer running it is in the same communication path as the GM. See: https://www.meinbergglobal.com/english/sw/ptp-track-hound.htm
I’m confused about Announce Message.
Who sends the announce message and who evaluates own state and change it.
Thank you Douglas
Best Regards.
When ever a master capable Ordinary Clock receives an announce message it compares the clock properties listed in the received Announce message to its own to see if the Announce message is from a better or worse clock. It is from a better clock than the receiving clock will be in either the SLAVE or PASSIVE state. If it is from a worse clock, the receiving clock will become the Grandmaster, and start sending Announce, Sync and possibly Follow_Up messages.
Boundary clocks are similar but have to compare all of the Announce messages received on the all the ports.
Thanks for your answer.
I have so many questions about PTP.
One of them ;
Is master clock can manage multiple slaves via dummy hub. I think hub is like Transparent Clock in standart.
Hello Douglas,
I have a network which looks like this:
Endstation1-Bridge1(GM)-Bridge2-Bridge3-Endstation2
| |
Endstation3
Endstation 3 is connected to both bridge1 and bridge2 (With two PTP interfaces)
Now, there is a link failure between Bridge1 and Bridge2.
Then what will happen? Bridge1 will think it is still the grandmaster as it will not receive any announce message from other candidates (i.e. bridge2 and bridge3).
And on the other hand, bridge2 and bridge3 will choose a new grandmaster as bridge1 is disconnected.
Or Endstaion3 will be acted as a relay instance? is it possible?
How the situation will be handled? How these two grandmaster’s situation will be resolved.
Please enlighten me.
If the two-port endstation 3 forwards PTP messages, then there will be a single Grandmaster. Otherwise the network form two PTP networks with different Grandmasters.
This is a really great article. Thank you for making the BMCA mechanism so palatable for beginners at PTP. I enjoyed the humor that came out of nowhere; ” In fact it so complicated that if you can accurately determine it for a clock then you get three credits toward a degree in mathematics.”
Would it be okay to use some content from this article for a presentation to some clients if I gave you credit for it and cited your article?
I’m learning tonnes from your articles, thanks Doug!
I’m curious to know a bit of a “black box” approach to the log variance question. What inputs does it rely on to evaluate itself? How can a clock know its own jitter and wander? Doesn’t this break Segal’s Law? Is it only possible to measure this if connected to the time source, or can the clocks evaluate themselves even when “offline” from GPS etc, and running on their internal oscillators?
How often does the logvariance recalcualte itself, is it continuous? (thinking of reaction time after a severe fault)
For a bit of background to my question:
I am looking into a project that needs a fair amount of robustness, and the time sources will be often unavailable. I read your article about using tripple redundancy, the 802.1AS standard also gives an example using redundancy with two GMs. My next question is then: Can’t a single domain do the job? Surely with the log variance in place, the GMs can announce that they have a lot of jitter/wander and another GM capable clock will fill its shoes in less than 5 seconds. Isn’t that redundant enough? I can’t see the need for the added complexity.
Usually the manufacturer sets a constant value for the logScaledVariance based on the short term stability of the oscillator. It does not get updated dynamically.
Hello Everyone,
I would like to know how to get the below clock properties from both grandmaster and boundary clocks.
1. Clock Class
2. Clock Accuracy
3. Clock Variance
4. M-S Phase Lag (Mean)
5. M-S Delay (Mean)
6. S-M Delay (Mean)
7. Steps Removed
Although there is a set of management messages defined by IEEE 1588, they are optional and many implementations do not support them. So you would have to look at the proprietary management interfaces available for specific products. I should point out a few things:
1. Clock Class, Accuracy and Variance are fields that appear in every Announce message. They refer to the clock properties of the Grandmaster, which might not be the device that is transmitting them, such as with a downstream Boundary Clock.
2. Steps removed also appears in every Announce message, and is incremented by every Boundary Clock that the time transfer travels through. Transparent Clocks to not change the steps removed.
3. The PTP Port in the slave state has all of the information to determine offset and delay to the master port it receives time from. The master port does not have enough information to do this, unless it has some extra information exchange with the slave port as part of a monitoring function. These monitoring functions are generally vendor specific.
4. PTP, like NTP, assumes that the M-S and S-M delays are the same.
IEEE 1588 defines a set of management messages. However, these messages are optional and not always implemented. So often one would have to look at the proprietary management interface of each PTP capable product.
I should point out a few import point here:
1. Clock Class, Accuracy and Variance are fields in every Announce message. They refer to the properties of the Grandmaster, not necessarily of the PTP Node transmitting the message, such as with a down stream Boundary Clock.
2. Steps removed starts as zero at the Grandmaster and is incremented by each Boundary Clock in the network path to the slave. This is a field in the Announce message. Note that Transparent Clocks do not update this field.
3. PTP slave ports have all of the timestamps needed to determine the offset and delay from the master port. The master port does not have enough information to determine this, unless there is an additional monitoring function. These monitoring functions are vendor specific.
4. PTP assumes the the M-S delay and the S-M delay is the same. Otherwise there is not enough information to determine the slave clock offset.
Hello There,
I have a question regarding the last tiebreaker of the BMCA ( the MAC address).
Is the clock’s port with the lowest or highest MAC address will win the election? Assuming for sure that the clocks are identical.
Thanks
This is an interesting question as it brings out two important points.
First, it is actually the PortIdentity of the PTP Port that issued the Announce message, not the MAC address. PortIdentity consists of the portNumber and the clockIdentity. We compare the clockIdentity values first. The lowest number is considered better. If the clockIdentity is the same, then we compare the portNumber. The latter can happen when the Announce messages come from different PTP Ports of the same Boundary Clock. A clockIdentity is required to be globally unique and you have to get the number from the IEEE Registration Authority.
The IEEE Registration Authority is also responsible for giving out Ethernet MAC addresses, which also have to be globally unique. One of the ways for creating globally unique clockIdentity values is to base them off the MAC address of the Ethernet port used by that particular PTP Port. The clockIdentity is the 48 bit MAC address in the most significant bits of the 64-bit clockIdentity. The remaining 16 bits are chosen to maintain global uniqueness. This is common practice, but not universal. An organization can get number ranges from the IEEE Registration Authority for the clockIdentity values that are not also used for MAC addresses. So don’t assume that all clockIdentity values are based on MAC addresses.
Thank you Douglas for your answer and detailed explanation!
From what I have seen, Meinberg Clocks use EUI-64 method (Extended Unique Identifier where the 48 bits (12-hex-digit) MAC address will be split in two halves (6 hex digits each), and then Insert FF:FE in between the two, creating the Clock Identity with a total of 16 hex digits (64 bits).
Would you please confirm this observation, and correct me if I am mistaken.
Thank you again
You should know that this method for creating EUI-64 values from EUI-48 values is now deprecated by the IEEE Registration Authority. This is what the IEEE RA says:
Mapping an EUI-48 to an EUI-64
Mapping an EUI-48 to an EUI-64 is deprecated. The mapping is described here
for historical reasons.
Mapping an EUI-48 assigned with an MA-S/OUI-36 or MA-M assignment to an
EUI-64 potentially creates a duplicate of an EUI-64 assigned with a different
MA-S/OUI-36 or MA-M. The IEEE RA has taken appropriate actions to mitigate
creation of duplicates based on this mapping but, to protect the integrity of
EUI-64 identifiers, this mapping is deprecated.
Some standards have described how an EUI-48 value could be mapped to an
EUI-64, as follows: Let the six octets of the EUI-48 be labeled eui48[0]
through eui48[5]. Let the eight octets of the mapped EUI-64 be labeled
eui64[0] through eui64[7]. The following mapping has been described:
eui64[0] = eui48[0]
eui64[1] = eui48[1]
eui64[2] = eui48[2]
eui64[3] = FFhex
eui64[4] = FEhex or eui64[4] = FFhex
eui64[5] = eui48[3]
eui64[6] = eui48[4]
eui64[7] = eui48[5]
In other words, the EUI-64 value was generated by inserting either the value
FF-FEhex or the value FF-FFhex in between eui48[2] and eui48[3].
Hello.
In IEEE Std 1588-2008, figure 28, the part 2 of BMC is described.
I will move from the start:
1) suppose that StepsRemoved of A and B are within 1 (go down via |A-B| B, i.e. B is better (go left);
3) decision diamond box says “Compare ID of Receiver of A and Sender of A”
May be we should check that B is correct, i.e. “Compare ID of Receiver of B and Sender of B”?
I mean, why should we care about correctness of A, if on the next step we are going to choose B as the better master (“Return B better…”)
Good question. The diagram in Figure 28 of IEEE 1588-2008 seems to be more complicated than it needs to be. The reason for this is that some of the early implementations of PTP would sometimes send Announce messages to themselves. So extra logic was created to detect this and remove those from consideration in the BMCA.