How does PTP's best master clock algorithm choose a grandmaster, and what happens when that grandmaster loses its GNSS reference?
answer
- no vote, everyone compares
- Announce messages carry the candidates
- priority1 before clock quality
- clockClass changes in holdover
basics
~20 sEvery PTP clock compares the Announce messages it hears against its own data set, ranking priority1, then clockClass, clockAccuracy, variance, priority2 and clock identity. When the grandmaster loses GNSS its clockClass worsens, and a better-advertising backup can win.
solid answer
~50 sPTP's grandmaster is not elected by voting. Each clock that could be master sends **Announce** messages describing its grandmaster, and every port runs the **best master clock algorithm (BMCA)** — defined in IEEE 1588, whose data sets RFC 8575 models — on what it hears plus its own data set. Lower wins at each step: `priority1`, then the clock quality (`clockClass`, `clockAccuracy`, `offsetScaledLogVariance`), then `priority2`, then the clock identity as the final tiebreak; `stepsRemoved` picks the shorter path to the same grandmaster. Because every clock compares the same data, they agree, and each port ends up master, slave or passive. When the grandmaster loses GNSS it enters holdover and advertises a worse `clockClass`; a backup still locked wins — **unless** the operator gave the old grandmaster a better `priority1`, which is compared first and keeps it in charge.
go deeper
Recall that one grandmaster leads each PTP domain, that clocks pick it by comparing Announce messages, and that lower values win.
Explain the comparison order - priority1, clock quality, priority2, identity - and how each port ends up master, slave or passive without any election message.
Walk through a GNSS outage: holdover, a worse clockClass in Announce, failover to a locked backup, and how a careless priority1 setting blocks that failover.
Weigh deterministic failover against operator overrides: decide which attributes the team may touch, how backups are fed independently, and how unexpected grandmasters are detected.
## What a grandmaster is In the **Precision Time Protocol (PTP)**, defined by IEEE 1588 rather than by the IETF, a **grandmaster** is the clock at the root of a PTP domain: RFC 7384 describes it as a master that takes its time from a locally attached source, such as a GNSS receiver, rather than over the network. Every other clock in the domain synchronises, directly or through boundary clocks, to that one grandmaster. RFC 8173 (a MIB) and RFC 8575 (a YANG model) restate IEEE 1588-2008's data sets, which is where the attribute names below come from. ## What the clocks compare A clock that could be master sends **Announce** messages describing the grandmaster it represents. The receiving port compares them with each other and with its own **default data set**. The order below is IEEE 1588's; at every step the lower value wins, and later fields matter only on a tie: | Order | Attribute | What it expresses | |---|---|---| | 1 | `priority1` | the operator's override, compared before quality | | 2 | `clockClass` | traceability: locked to a primary reference, in holdover, free-running | | 3 | `clockAccuracy` | the accuracy the clock claims | | 4 | `offsetScaledLogVariance` | the clock's stability when not synchronised | | 5 | `priority2` | a second operator override among equal-quality clocks | | 6 | clock identity | a unique identifier: the deterministic final tiebreak | When two Announce messages describe the **same** grandmaster, IEEE 1588 uses `stepsRemoved` — the number of communication paths to the grandmaster, as RFC 8575 defines it — to prefer the shorter route. RFC 8575 also shows a `clock-class` default of 248, the default class IEEE 1588 uses when no other class applies, and a `slave-only` flag for clocks that must never become master. ## How the decision is distributed There is no election message and no central arbiter. The process runs on every port: 1. A port listens for Announce messages (RFC 8575's `listening` state). 2. It keeps the best Announce received and runs the comparison against its own data set. 3. It takes a state: **master** if its own clock is better than anything heard, **slave** toward the port carrying the best grandmaster, or **passive** where taking either role would create a loop. 4. If no Announce arrives within `announceReceiptTimeout` announce intervals (RFC 8575's `announce-receipt-timeout`), the port treats its master as gone and runs the comparison again. Because every clock compares the same advertised values by the same rules, they converge on one grandmaster without negotiating. ## When the grandmaster loses its GNSS reference Losing GNSS does not stop the grandmaster at once; its oscillator keeps time in **holdover**, drifting slowly. What changes is what it advertises: - In IEEE 1588's table, `clockClass` 6 means synchronised to a primary reference, and 7 means it was, but is now in holdover within its specification; further degraded classes follow if holdover runs long. - The new `clockClass` goes out in the next Announce messages. - A backup grandmaster still locked to GNSS advertises class 6. With equal `priority1`, it now wins at step 2, and the domain fails over to it as each port re-runs the comparison. - When GNSS returns and the original advertises class 6 again, the comparison may hand the role back, depending on the remaining fields. ## What operators get wrong - **The `priority1` trap.** `priority1` is compared before clock quality. Give the primary grandmaster a better `priority1` "to make it preferred", and it stays grandmaster while in holdover — or worse — because the backup never reaches the quality comparison. Use `priority2` for preference among equals. - **Trusting every Announce.** The algorithm believes what Announce messages say. RFC 7384 describes the rogue master: a device advertising better values wins the election and the domain follows it. Defences are to restrict which ports may become master, mark end devices `slave-only`, and authenticate where the profile allows. - **Not watching the parent data set.** Which grandmaster won is visible on every clock: RFC 8575 models `grandmaster-identity`, `grandmaster-clock-quality` and the grandmaster's two priorities in its parent data set, and RFC 8173 exposes the same as MIB objects. Alarm when the identity changes unexpectedly. - **One GNSS antenna for two grandmasters.** Redundant grandmasters fed by the same receiver fail together, and the comparison has nothing better to pick.
- Why is raising the primary grandmaster's priority1 a risky way to make it preferred?`priority1` is compared before `clockClass`, so a clock with a better `priority1` wins even when its quality has collapsed — for example in holdover after losing GNSS — and the healthy backup never gets compared on quality. Leaving `priority1` equal and using `priority2` expresses preference without overriding quality.
- What decides between two Announce paths that lead to the same grandmaster?The grandmaster's attributes are identical, so IEEE 1588 compares `stepsRemoved`, the number of communication paths between the clock and the grandmaster, and prefers the shorter route; remaining ties are broken by port identities.
- How does a defender stop a rogue device from becoming grandmaster?Configure end devices as `slave-only`, accept Announce messages only on ports that face legitimate masters, and monitor for unexpected grandmaster identities. RFC 7384 lists the rogue master among the threats and says a time-protocol security mechanism MUST let slaves verify that a master is authorised, which many PTP deployments have not provided.
saying these in an interview costs you the question
- PTP clocks hold an election and vote for the grandmaster.
- clockClass is compared before priority1, so quality always wins.
- A grandmaster that loses GNSS stops sending Announce at once.
- The clock identity is compared first, so the lowest MAC address wins.
- Higher priority1 values win the best master clock comparison.