What Makes a Master the Best?


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.
  1. 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.
  2. 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.
  3. Clock Accuracy: This is an enumerated list of ranges of accuracy to UTC, for example 25-100 ns.
  4. 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.
  5. 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.
  6. 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.

Comments