PTP Grandmaster Explained: How BMCA Elects the Network's Master Clock
Every PTP network has exactly one clock in charge — the grandmaster — and nobody appoints it by hand. The clocks hold an election instead. Each candidate advertises a scorecard in its Announce messages, every device runs the same comparison in the same fixed order, and the whole network converges on the same winner. This article explains that election in plain English: what is on the scorecard, the order it is read in, a worked three-clock election, and the one setting that can accidentally keep a failing clock in charge.
The short answer
A PTP network elects its leader. The leader is called the grandmaster: the one clock whose time everyone else ultimately copies. No server assigns the job. Instead, every clock that is allowed to lead periodically sends out an Announce message — a short advertisement that says, in effect, "here is how good my time is." Every device that hears those adverts runs the same comparison, called the Best Master Clock Algorithm, or BMCA, and scores the candidates in the same fixed order. Because everyone reads the same adverts and applies the same rules, everyone reaches the same answer, and the network organises itself into a tree with the grandmaster at the root and time flowing downhill.
Think of it as an election where the candidates publish audited CVs and the voters are machines that cannot disagree about the counting rules. There is no campaigning and no judgement call: the first line of the scorecard that differs between two candidates decides between them, full stop. That also means the election is completely predictable — if you know the scorecards, you can work out the winner on paper before you plug anything in. This article shows you how: what each line of the scorecard means, a worked election between three clocks, what happens when the winner fails, and the design choices that decide whether your backup clock ever actually gets its turn.
Why an election at all?
Because a network with two clocks in charge is worse than a network with one mediocre clock in charge. If half your switches copy time from one source and half from another, the two groups drift apart, and the thing PTP exists to give you — one shared "now" that a trading system, a mobile network or an industrial controller can trust — is gone. So the design goal is not just "pick a good clock." It is "every device picks the same clock, automatically, including after a failure, at 3 a.m., with nobody watching." An election with published scorecards and identical counting rules is how you get that. A hand-configured "this one is the master" flag cannot react when that box dies; an election re-runs itself.
The election runs continuously, per PTP domain (a domain is just a numbered timing neighbourhood — clocks only elect among candidates in their own domain). Each port of each device listens, compares, and settles into one of three states: master (I serve time out of this port), slave (I take time in through this port — a device has at most one of these), or passive (I can hear an equally good path here, so I stay quiet to keep the tree free of loops). The result is a tree, never a web: time has exactly one route into every device.
The Announce message: a candidate's published scorecard
A clock that wants to be considered sends Announce messages on a steady interval. The message does not carry the time itself — the Sync messages do that job, and they only start flowing once the election is settled. Announce carries identity and quality: who the candidate's grandmaster is (often itself), how far down the tree it sits (a counter called stepsRemoved — 0 means "I am the root"), and the scorecard of the grandmaster it is advertising. Every field on that scorecard is a claim the candidate makes about its own time. Nothing in the protocol checks the claim is honest — which is one reason timing networks treat an unexpected new Announce source the way a security team treats an unexpected new login.
Here is the scorecard, in the exact order BMCA reads it. The rule at every line is the same: lower wins, and the first line where two candidates differ ends the comparison.
| Order | Field | What it means, in plain English |
|---|---|---|
| 1 | priority1 | A number from 0 to 255 that you, the operator, set. It is your override: "whatever the quality says, prefer this one." Default is usually 128. |
| 2 | clockClass | What kind of source the clock is traceable to. A clock locked to a primary reference such as GNSS advertises class 6. If it loses that source and is coasting within its holdover limits, it drops to class 7 — still usable, visibly degraded. A clock with no external reference at all advertises the default class 248. |
| 3 | clockAccuracy | How close the candidate claims its time is to the true time, as a coded category (within 25 ns, within 100 ns, within 1 microsecond, and so on; the code for "unknown" is 0xFE). |
| 4 | offsetScaledLogVariance | How steady the candidate's clock is — its jitter and wander, expressed as one number. Accurate-but-wobbly loses to slightly-less-accurate-but-rock-steady here, because a wobbling master wobbles the whole tree. |
| 5 | priority2 | A second operator-set number, 0 to 255 — a finer tie-breaker you control, used only when the quality lines above are all exactly equal. |
| 6 | clock identity | The candidate's unique 8-byte identity, usually derived from a MAC address. Nobody chooses this to win; it exists so that two perfectly identical scorecards still produce exactly one winner, everywhere, with no coin toss. |
One more comparison sits behind the scorecard: when a device hears about the same grandmaster through two different ports, the path with the smaller stepsRemoved — fewer boundary clocks between it and the root — is preferred, and the other port goes passive. That is what keeps the tree shallow and loop-free.
A worked election: three clocks, one winner
Imagine a small trading-floor network with three clocks that all announce in the same domain, and nobody has touched any priority settings, so priority1 and priority2 are 128 everywhere:
| Candidate | priority1 | Class | Accuracy claim | What it is |
|---|---|---|---|---|
| Clock A | 128 | 6 | Within 100 ns | GNSS grandmaster appliance, antenna healthy |
| Clock B | 128 | 6 | Within 100 ns | Second, identical GNSS appliance — the backup |
| Clock C | 128 | 248 | Unknown | Core switch free-running on its own oscillator |
Clock C loses first, and it is not close: priority1 ties at 128, so the comparison moves to class, where 6 beats 248 immediately — accuracy and stability are never even read. Between A and B the scorecards are identical line after line, so the decision falls all the way to line 6, the clock identity, and the lower identity wins. Deterministic — every device reaches the same answer — but arbitrary: swap appliance B for a replacement unit with a different identity and the "winner" can flip. Real designs do not leave their primary-versus-backup choice to a tie-breaker they do not control, which is exactly what priority2 is for: set A to priority2 100 and B to priority2 110 and A now wins at line 5, every time, for a reason written in the configuration.
The priority1 trap: an override that outranks quality
Now the subtle part, and the reason this article exists. Notice the order again: priority1 is line 1. Clock class — the line that says "I have lost my satellite signal and I am coasting" — is line 2. Line 1 is read first. So if you set your primary appliance to priority1 10 and its backup to priority1 20, the primary does not just win on day one. It keeps winning on the bad day: its antenna fails, its class drops from 6 to 7, and the election never cares, because the comparison between the two appliances ends at priority1 before class is ever looked at. Your healthy backup sits there with perfect satellite lock, politely losing to a clock that is coasting.
Sometimes that is genuinely what an operator wants — a primary with a very good oscillator can be the best source for hours in holdover, better than re-rooting the whole tree. But it should be a decision, not an accident. The alternative design is to leave priority1 equal on both appliances and express the preference in priority2 instead: now a degraded primary (class 7) loses to a healthy backup (class 6) at line 2, the tree re-roots automatically, and priority2 only arbitrates when both are equally healthy. Neither design is wrong. Picking one without realising you picked it is how timing incidents are born.
When the winner fails: the election re-runs itself
Failover needs no monitoring system and no script. Every device expects Announce messages to keep arriving; when they stop — in the default profile, after a receipt timeout of three missed Announce intervals — the silent candidate is struck off the list and BMCA simply runs again on whoever is left. The old grandmaster's boundary clocks pick the new winner as their parent, re-serve time down their branches, and the tree re-forms around the new root, usually within seconds. The same machinery handles the gentler failure: a grandmaster that stays up but degrades re-advertises itself with a worse scorecard (class 6 becoming 7 is the classic case), and the network re-elects around the new facts — provided, per the trap above, that nobody pinned it with priority1.
During the gap, nothing has any new time to copy, so every clock coasts on its own oscillator. How far it drifts in those seconds is its holdover quality, and it is why the failover question and the holdover question are really the same question asked twice. (The holdover planner linked below lets you put numbers on exactly that drift.)
One honest complication: not every PTP profile uses this exact scorecard order. The telecom profiles (the G.8275 family used by mobile networks) run an alternate BMCA that adds a per-port local priority into the comparison, because phone networks need topology to matter more than the default rules allow. The election idea is identical; the counting rules differ by profile — one more reason two PTP devices must agree on their profile, not just their domain, before they can agree on a grandmaster.
Four election mistakes that actually happen
1. Pinning with priority1 without meaning to. Covered above: the override outranks the degradation signal, so the backup never takes over. Decide which behaviour you want, then set the priorities that produce it.
2. A domain mismatch. Elections are per-domain. A grandmaster announcing in domain 24 and switches configured for domain 0 are not in disagreement — they are in different elections, and the switches will elect one of themselves (class 248) and free-run, looking for all the world like a grandmaster failure.
3. Announce messages filtered away. PTP rides on multicast (or negotiated unicast, depending on profile). An access list, a multicast filter or a profile mismatch that quietly eats Announce messages produces clocks that cannot see any candidate — so they conclude they are the best clock available and start serving their own time. The symptom is several small "grandmasters," one per isolated pocket.
4. Leaving the primary/backup choice to the identity tie-break. Identical appliances with identical settings still elect a winner — the one with the lower identity — and a hardware replacement changes that identity. Express the preference in priority2 so the design survives a swap.
Checking a live election is one command on most platforms — show ptp clock and its parent/grandmaster companions (the exact wording varies by vendor) print the local scorecard, the current grandmaster's identity, and stepsRemoved. Read them on two different switches: both should name the same grandmaster. If they do not, you do not have a tuning problem, you have two elections.
Try it yourself
Put the election's neighbours to work, free, in your browser. The PTP/SyncE timing simulator models a whole multi-hop timing tree — build the tree this article describes, then fail the grandmaster and watch the error accumulate while the tree re-roots. The PTP timing budget calculator adds up the error each hop of that tree contributes, so you can see what the election's winner is really worth by the time its time reaches the last leaf. And if the failover gap is the part that worries you, the holdover explainer linked in the related guides below works through the coasting maths in plain English.
- The grandmaster is elected, not configured into existence: every clock that could lead sends Announce messages describing itself, and every PTP port runs the Best Master Clock Algorithm (BMCA) on what it hears, so the whole network agrees on one winner without a central referee.
- BMCA reads the scorecard in a fixed order — priority1, then clockClass, clockAccuracy, offsetScaledLogVariance, priority2, and finally clock identity as the tie-breaker — and the comparison stops at the first field that differs. Lower wins at every step.
- priority1 is checked before clock quality, so a low priority1 pins a clock as grandmaster even after it loses its satellite signal and degrades. Leaving priority1 equal lets quality decide, so a healthy backup takes over when the primary drops from class 6 to class 7 in holdover.
- When a grandmaster goes silent, the election re-runs automatically after the Announce receipt timeout (three missed Announce intervals in the default profile), boundary clocks re-root to the new winner, and every clock rides its own oscillator — its holdover — for the gap in between.