Keeping time across a distributed network is harder than it sounds. The OpenInfra Foundation is now out with StarlingX 12.0, and precision timing support is one of its headline additions.

This is the first major release of 2026 for StarlingX, the open-source distributed cloud platform used by Verizon, Vodafone, T-Systems and KDDI for 5G and O-RAN infrastructure.

StarlingX 12.0 builds on the 11.0 update that came out in November. StarlingX is a fully integrated cloud infrastructure platform that combines the Linux kernel, Kubernetes, OpenStack and Ceph for edge and distributed cloud deployments. Key new features in StarlingX 12.0 include:

• Consolidated OIDC authentication: A single OpenID Connect proxy replaces a fragmented dual-database system, unifying authentication across all platform interfaces.
• NetApp storage support: NetApp is now supported as a standalone storage backend or in combination with Ceph.
• Unified Software Management improvements: Backup and restore operations require fewer steps and avoid restarts and full reinstalls.
• PTP Partial Timing Support (PTS): Precision timing can now be distributed across deployments where not every node has PTP-capable hardware.

“Prior to PTS, such nodes would either rely on software timestamping with unpredictable error, require local GNSS (Global Navigation Satellite System), or be excluded from precise-timing workloads altogether,” Matt Peters, senior director of cloud engineering at Wind River, told Network World.

PTP Partial Timing Support extends precision timing to mixed-hardware deployments

Precision Time Protocol is the mechanism distributed systems use to synchronize clocks to sub-microsecond accuracy across nodes. It underpins 5G radio access networks, O-RAN deployments and a growing range of industrial and financial applications. Until 12.0, StarlingX required PTP-capable hardware on every node in a deployment, making phased hardware rollouts and mixed-fleet environments difficult to support.

“Partial Timing Support (PTS), aligned with ITU-T G.8275.2, allows only a subset of the network elements to be PTP-aware while still distributing time to nodes that lack full PTP hardware capability,” Peters said.

The accuracy tradeoff under PTS is defined by the standard. ITU-T G.8275.2 sets a bounded maximum time error of plus or minus 0.5 milliseconds, accepting the presence of non-PTP-aware segments and uncorrected packet delay variation (PDV). Where NIC-level hardware timestamping is available, StarlingX uses it to reduce PDV. Where it is not, Peters noted that timing accuracy is relaxed but bounded rather than uncontrolled.

Compared to Full Timing Support, PTS trades nanosecond or sub-microsecond precision for deployment flexibility. “Application latency is not materially impacted, but time determinism and phase precision are lower,” Peters said. 

StarlingX exposes tunable PTP parameters including servo behavior, thresholds and holdover settings, letting operators optimize timing for specific network topologies and PDV characteristics.

Precision timing demand extends well beyond telecom

The PTS addition matters most in deployments that cannot absorb a full hardware refresh before enabling precision timing. Peters identified where demand for PTP support is strongest outside of telecom.

“Beyond telecom, the earliest and strongest driver of PTP adoption has been industrial automation, where time-based control, robotics, machine vision, and TSN require sub-microsecond coordination across distributed systems,” Peters said. “Power grids and utilities are another major driver, using PTP for synchrophasors, protection relays, and fault analysis where microsecond-accurate, traceable timestamps are critical to grid stability.”

Financial services represent additional demand, particularly for high-frequency trading and regulatory timestamping. Peters also cited autonomous and smart transportation systems, where sensor fusion and coordinated decision-making depend on consistent time across nodes.

User authentication gets a single point of control

Prior to 12.0, StarlingX operators managed users across two separate databases. One was a Keystone database for StarlingX APIs and CLIs used to manage infrastructure. The other was an OIDC database for Kubernetes APIs and CLIs covering both additional infrastructure management and hosted application management. Any change to user privileges had to be replicated across both systems.

The 12.0 release consolidates all authenticated endpoints behind a single OpenID Connect proxy.

Broader enterprise positioning reflects growing interest outside telecom

StarlingX has its roots in telecom, but the project has always targeted broader use cases, from industrial IoT across factory floors to retail systems spanning thousands of locations to large data center deployments. 

The 12.0 release explicitly positions StarlingX as a general-purpose distributed cloud platform, and Waines said that reflects existing momentum rather than a new direction.

“Whether you’re a company looking for a VMware alternative, a factory that reached the stage of starting to modernize their infrastructure, a company in Europe who needs a powerful platform while also prioritizing digital sovereignty, StarlingX delivers the base functionality that you need,” Waines said.