Blog

AsterNOS Hitless PTP Configuration: Maintaining Sub-Microsecond Sync During Runtime Changes

Beyond High Accuracy: The Need for Continuous PTP Synchronization

Precision Time Protocol (PTP, IEEE 1588v2) is foundational for high-precision timing across 5G transport, professional broadcast, industrial automation, and power grids. In production environments, networks are dynamic: media endpoints come online or go offline, base stations scale, and operators must routinely adjust PTP priorities, message intervals, or port configurations.

This raises a critical operational question: Does modifying a PTP parameter on one port disrupt established time synchronization on other active ports?

In mission-critical timing chains, if a localized configuration change forces the entire PTP instance to restart or re-converge, active ports will suffer temporary lock loss. In 24/7 networks, synchronization continuity during configuration changes is just as vital as steady-state synchronization accuracy.

How Configuration Changes Disrupt Traditional PTP (e.g., ptp4l)

In traditional LinuxPTP implementations (like ptp4l), many configuration changes cannot be applied dynamically at runtime. To update parameters like message intervals or priorities, operators must reload the configuration file or restart the ptp4l process.

This restart breaks active timing relationships:

  1. The device temporarily loses its upstream timing reference.

  2. Downstream Slaves drop out of locked state.

  3. The system is forced into a complete re-selection (BMCA), re-synchronization, and re-locking cycle, sending timing disturbance downstream.

Architectural Insight: How AsterNOS Achieves Hitless PTP Updates

To eliminate synchronization disruptions, Asterfusion switches running AsterNOS introduce Hitless PTP Configuration.

Unlike monolithic PTP daemons that require process restarts, AsterNOS decouples the PTP control plane from the hardware timing engine:

  • Dynamic IPC & Database Sync: Configuration changes made via CLI/REST API are updated dynamically in the system database and passed to the running PTP engine via non-disruptive IPC.

  • Continuous Hardware Clocks (PHC): The Physical Hardware Clock on the switching ASIC maintains its phase-locked loop (PLL) with the Grandmaster throughout the update, preventing any phase jumps or timing loss.

As a result, operators can modify supported PTP settings or toggle individual ports without interrupting active timing services on other interfaces.

Real-World Verification: Test Setup & Results

To evaluate Hitless PTP performance under live configuration changes, we deployed a multi-stage Boundary Clock (BC) topology:

Test Equipment

GM: CX306P-48Y-M

DUT: CX206Y-48GT-M

Slave: CX206Y-48GT-M

Test Center VIAVI5800

Software Version

AsterNOS-V5.2R017P01

Test Execution & Telemetry Results

While the DUT actively synchronized downstream devices, two live configuration changes were performed:

  1. Port Shutdown (Point 1 on Grafana Dashboard): Shut down an active port connected to a PTP Slave to test per-port isolation.

  2. Interval Modification (Point 2 on Grafana Dashboard): Dynamically changed the Announce message interval on an active Master port.

Key Telemetry Observations:

  • Point 1 (17:05 - Interface Shutdown): As shown on the timeline, shutting down a PTP port had zero ripple effect on other active ports. The Lock Status stayed locked at 1, and Offset from Master remained stable within ±5 ns.

  • Point 2 (17:10 - Parameter Change): Dynamically updating the Announce Interval caused no phase jump, no clock drift, and zero re-locking delay.

Independent VIAVI 5800 Performance Measurement

The VIAVI 5800 test instrument independently validated the physical time error output:

Both MTIE (Maximum Time Interval Error) and TDEV (Time Deviation) tests returned PASSED against ITU-T G.8273.2 masks, confirming that AsterNOS maintains strict sub-microsecond timing accuracy throughout live maintenance operations.

Scope of Hitless PTP Configuration

While operational parameters can be updated dynamically, changes that inherently alter the underlying timing architecture will naturally trigger a re-selection cycle (by design):

Configuration Category

Parameter Name

Hitless Support

Operational Impact

Clock Attributes

Priority1 / Priority2, Clock Class, Accuracy

Yes (Hitless)

Dynamic update; no state reset

Message Intervals

Sync / Announce / Delay_Req Interval

Yes (Hitless)

Adjusted on the fly without loss of lock

Port Operations

Add / Remove Port, Admin Up/Down, TLVs

Yes (Hitless)

Isolated to target port; zero impact on active peers

Architectural Changes

PTP Profile, Clock Type (GM/BC/TC), Domain ID

No (Re-sync Required)

Triggers BMCA re-election & re-lock cycle

Conclusion

In modern production networks, timing availability is measured not just in steady state, but during everyday maintenance. AsterNOS Hitless PTP Configuration bridges the gap between high accuracy and high availability, allowing network engineers to perform live parameter tuning and port changes with zero fear of timing disruption.

Keep reading