Table of Contents
Beyond High Accuracy: The Need for Continuous PTP Time Synchronization
Precision Time Protocol (PTP) is a fundamental technology for high-precision time synchronization in networks where devices need to share a highly accurate time reference. Today, PTP is widely used in 5G transport networks, professional media and broadcast, industrial networks, power systems, and other timing-sensitive environments.
Precision Time Protocol (PTP) is a fundamental technology for high-precision time synchronization in networks where devices need to share a highly accurate time reference. Today, PTP is widely used in 5G transport networks, professional media and broadcast, industrial networks, power systems, and other timing-sensitive environments. In production environments, however, networks are not static. As network conditions and operational requirements evolve, operators may need to adjust PTP priorities, change message intervals, tune clock parameters, modify selected port settings.
Consider a professional media and broadcast production network, where large numbers of cameras, audio devices, and production endpoints use PTP to obtain a common time reference. During day-to-day production, endpoint connectivity can change frequently. Cameras may be powered off or disconnected when a production task ends, while additional cameras or other media devices may be introduced for new production requirements. As these endpoints come online or go offline, operators may need to enable, disable, or adjust PTP configuration on the corresponding switch ports.
These are normal network operations, but they raise an important question that is easy to overlook: when the PTP configuration on one port changes, will it affect time synchronization relationships that have already been established on other ports?
In a network serving large numbers of timing-sensitive endpoints, if a local PTP configuration change causes the entire PTP instance to reconverge, or even causes other previously synchronized ports to temporarily lose synchronization, a routine endpoint connection or disconnection can turn into a broader timing event.
Therefore, in production PTP networks, synchronization continuity during configuration changes is an important measure of operational stability alongside synchronization accuracy.
How Configuration Changes Affect PTP Time Synchronization
In some PTP implementations, changes to certain parameters cannot be applied directly to a running PTP instance. The configuration must be reloaded, and in some cases the PTP process must be restarted before the changes take effect. For a device that is already stably synchronized, this process can cause changes in the PTP clock or port state and may briefly interrupt an established timing relationship, after which clock selection, synchronization, and locking must be established again.
Take ptp4l in the open-source LinuxPTP project as an example. PTP profiles, clock attributes, message intervals, and interface-related parameters can be defined in configuration files and loaded when the ptp4l process starts. For parameters that cannot be updated dynamically through runtime management interfaces, editing the configuration file alone does not immediately change the behavior of the running instance. To apply the new configuration, the PTP configuration typically needs to be reloaded; in common deployment models, this may involve stopping the current ptp4l process and restarting it with the updated configuration.
In ordinary networks, a brief re-synchronization may have little visible impact. In networks with stringent requirements for both timing accuracy and service continuity, however, such an interruption matters.
In 5G transport networks, for example, PTP is widely used to provide high-precision timing references to base-station-side equipment, while the transport network itself is expected to deliver 24×7 communications services. In production, it is difficult to suspend an entire timing chain merely to change a PTP parameter, and maintenance windows with no service impact are limited. If a routine PTP configuration change requires the PTP process to restart while the network is already stably synchronized, the device may temporarily lose its upstream timing reference and go through synchronization and locking again. The resulting timing disturbance can also propagate along the timing chain to downstream devices.
For networks that require stringent timing accuracy, continuously operating synchronization chains, and limited maintenance windows, it is not enough for a device simply to regain synchronization eventually. Maintaining established timing relationships during routine configuration changes and avoiding additional synchronization interruptions are also important considerations for PTP maintainability and synchronization continuity.
How to Configure Hitless PTP on AsterNOS to Maintain Time Synchronization
To address synchronization interruptions that may be caused by PTP configuration changes, Asterfusion PTP switches running AsterNOS provide Hitless PTP Configuration. For supported PTP parameters, the device can update the configuration dynamically while maintaining the existing timing relationship, avoiding unnecessary PTP synchronization interruptions during routine configuration changes.
This means that even when a device is already stably synchronized and continuously providing a timing reference to downstream devices, operators can still adjust supported PTP parameters or port configurations as required. While the configuration is being applied and taking effect, the device continues to maintain the established timing relationship without having to go through a complete clock-selection, synchronization, and locking cycle again.
To verify Hitless PTP Configuration in a practical network, we built a multi-device PTP timing network and observed synchronization status and timing performance using both device-side PTP monitoring and a professional timing test instrument.
The test network uses a multi-stage PTP synchronization topology. The upstream device obtains its time reference from GNSS and distributes time downstream through PTP. The switch under test operates as a Boundary Clock in the timing chain, providing PTP synchronization to downstream PTP Slaves while configuration changes are applied. The topology is shown in figure below:
| Test Equipment | GM: CX306P-48Y-M |
| DUT: CX206Y-48GT-M | |
| Slave: CX206Y-48GT-M | |
| Test Center VIAVI5800 | |
| Software Version | AsterNOS-V5.2R017P01 |
During the test, Telemetry continuously collected the downstream PTP Slave’s Lock Status and Offset from Master, which were displayed in real time through Grafana. A VIAVI timing test instrument was also used to independently measure time error and further verify the device’s PTP synchronization performance.
Two different types of configuration changes were tested:
1. With the DUT operating stably and providing PTP synchronization to multiple downstream devices, one interface connected to a PTP Slave was shut down. This verifies whether a state change on a single PTP port affects other active PTP ports or established timing relationships on the device.
2. With the PTP network stably synchronized, the Announce message interval on a DUT Master port was changed. This verifies whether the device can maintain continuity of the established timing service while a PTP parameter is dynamically modified.
The results show that the PTP Slave was already stably synchronized before both configuration operations. During the interface shutdown and the Announce interval change, the Slave’s Lock Status remained stable throughout, with no observed loss of lock or re-locking caused by the configuration changes. At the same time, Offset from Master remained within its existing fluctuation range before and after both change points, with no obvious configuration-related excursion.
These results show that neither configuration operation caused an observable interruption to the established PTP timing relationship. Whether the change involved a PTP port state transition or a dynamic PTP message parameter adjustment, the other active PTP timing services remained stable.
In addition to using the Slave’s Lock Status and Offset from Master to verify synchronization continuity, we also used a VIAVI 5800 timing test instrument to measure PTP synchronization performance.
The Two-Way Time Error results show that time error remained stable during the measurement period, with no obvious abnormal timing deviation observed.
Further MTIE and TDEV analysis of the measurement data returned Passed results for both metrics. This indicates that the DUT not only maintains a stable PTP synchronization state, but also delivers stable timing performance.
Scope of Hitless PTP Configuration
It is important to note that not every PTP configuration change is expected to preserve the existing timing relationship. Changes to some PTP parameters inherently alter the timing topology, the set of eligible reference clocks, or the synchronization relationship itself.
Hitless PTP Configuration is therefore primarily intended for operational parameter changes that do not inherently require a change to the PTP domain, timing source, clock role, or timing architecture. Operations such as changing the PTP domain, switching the PTP profile, or deliberately selecting another timing source may require the PTP system to establish a new synchronization relationship.
| Configuration Category | PTP Attribute | Hitless Configuration Support |
| PTP Profile & Clock Mode | Profile（SMPTE 2059-2 / G.8275.1 / G.8275.2 / IEEE 1588v2 / AES67） | – |
| Clock Type（GM / BC / TC / OC） | – | |
| Clock ID | – | |
| Clock Source & BMCA | Clock Accuracy | √ |
| Clock Class | √ | |
| Priority1 / Priority2 | √ | |
| Transport & Timing Mode | Transport Mode（UDPv4 / UDPv6 / Ethernet） | – |
| Delay Mechanism（E2E / P2P） | – | |
| Clock Step Mode（One-step / Two-step） | – | |
| Source Address | – | |
| State Machine TLV Parameters | √ | |
| PTP Message Parameters | Sync / Announce / Delay Request message interval | √ |
| Minor Version | √ | |
| DSCP | √ | |
| PTP Port Operations | Add / Remove PTP Port | √ |
Conclusion
Network configurations are not static. In real-world deployments, PTP performance is defined not only by the synchronization accuracy a device can achieve in steady state, but also by how reliably it can maintain established timing relationships during network operation and maintenance. Hitless PTP Configuration extends this reliability into day-to-day operations. By allowing supported PTP parameters to be changed without interrupting synchronization, the network can maintain high-precision timing while gaining greater operational flexibility and timing availability.
Other PTP Blogs You Should Read
- What is PTP and How does it Work?
- All PTP Clock Types and How to Configure in Asterfusion
- PTP Profiles for Network Engineers: How to Pick the Best Profile
- AV over IP Switches Enable Cost-Effective Live Streaming Networks
- Why 10ns PTP Switches for Broadcast Are the Industry Gold Standard
- Why PTP Network Switches are Used in Financial Trading?
- PTP Design Best Practices for Media & Entertainment IP Networks
Real Case Study:
