Skip to content
All articles
Telecom and WAN

How we test PTP and SyncE: holdover, asymmetry, a lying clock

Alexander Zemskov 4 min read
How we test PTP and SyncE: holdover, asymmetry, a lying clock

A switch for the transport network arrives with a datasheet line: IEEE 1588v2, boundary and transparent clock, SyncE, G.8275.1. That line says the protocol is in the firmware. It does not say what the box does when the uplink is full, when the grandmaster goes silent, or when it keeps talking and hands out the wrong time. The radios below believe whatever the box sends.

The bench

The device under test carries time: a boundary clock in aggregation, a node without PTP support in between, a cell-site router at the edge. Our generators emulate PTP on both sides: one or two grandmasters upstream with the profile, domain and Announce attributes of your design, the slave clocks of the radios downstream. SyncE runs alongside with ESMC quality levels. On the same ports the generator carries user traffic in your classes, up to line rate on 1G, 10G and 100G, 400G and faster per project. This is the sync item of the transport class on the 5G and mobile core page.

One limit: the bench has no dedicated timing analyser yet. We see protocol states, messages and the delay of every packet on one generator clock. Time error in nanoseconds against the class limits of the box (ITU-T G.8273.2) and drift in holdover need that analyser; full timing analysis is agreed per project, with the instrument named in the plan.

What we check

  • Profile and defaults: G.8275.1 or G.8275.2, domain, multicast address, message rates; whether the box locks and how long it takes
  • Best master selection: two grandmasters with different clock class, one degraded on cue; which one the box picks, how fast, whether it flaps
  • Holdover: the grandmaster goes silent under load; the state the box enters, the clock class it announces downstream, the relock
  • A source that lies: a good clock class and a time step of seconds; whether the box passes the step to the radios
  • PTP under load: delay variation of PTP messages through nodes without PTP support at steps such as 30, 70 and 100%
  • Path asymmetry: one-way delay in each direction under your load, on one clock
  • SyncE: the switch to the backup reference when the primary drops to DNU, and the time of that switch

What usually breaks

Path asymmetry. PTP splits the round trip in half, so it assumes equal delay both ways. Under load that rarely holds: video fills downstream, upstream is almost idle, the queue builds on one side. Each microsecond of asymmetry shifts the clock by half a microsecond. In a typical project a hop without PTP support adds 3 µs more delay downstream than upstream at 70% load: 1.5 µs of time error from one hop, the whole ±1.5 µs that neighbouring TDD cells share. The link had passed every throughput test, so nobody measured it.

Second: defaults that differ. One box runs the G.8275.1 domain, the next ships with the G.8275.2 domain, or they disagree on the multicast address. The downstream box never locks and runs on its own oscillator while traffic flows. On the bench that is a lock that never comes, found in the first hour.

Third: holdover that tells nobody. The grandmaster goes silent, the box enters holdover and keeps announcing the clock class it had while locked. The radios carry on as if time were good until the drift shows up as interference. Worse is a source that stays up and sends the wrong time, as in our story about the clock nobody checks. Lock lost because PTP shares a queue with user traffic is in the 5G transport post.

What is in the report

Lock time and state per scenario. Best master choice and switchover time. A holdover timeline: event, state, announced clock class, relock time. PTP delay variation per load step. One-way delay per direction and the time error the asymmetry implies, marked as computed. SyncE switch times. Every sync item is marked as a check with emulated PTP; with a timing analyser in the project, time error against class limits gets its own section. Configuration, firmware and profile settings, so the vendor can repeat any item.

Where to start

Send us the switch or router model, the firmware and the sync plan: profile, grandmasters, the clock chain and the budget per hop. We answer with a draft test plan: the items, the bench layout and the dates. The report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.

Written by

Alexander Zemskov

Alexander Zemskov leads network and security testing at TEST4NET, an independent, vendor-neutral testing lab in Yerevan, Armenia. With 19+ years in performance and load testing on IXIA, Spirent, Keysight, Xena and Xinertel platforms, he runs NGFW, WAF, IPS, DLP and SASE evaluations for telecom operators, banks and system integrators.

Blog

Keep reading