Equinix Precision Time FAQs

Sign up for Equinix Precision Time in the Equinix Fabric portal. For instructions, see Order Precision Time with Fabric Connect.

Or contact your sales representative for help with ordering Precision Time services. For more information, see Order Precision Time Services.

If a Precision Time service was ordered through an Equinix sales representative, it can only be edited, deleted, or cancelled by an Equinix sales representative. The Equinix Fabric portal doesn’t provide online support for changes to orders created through the Equinix sales representative process. For more help, reach out to your Equinix sales representative.

You must wait 6 hours before making changes to a new order with the Provisioned status. This timeframe allows the invoice database to update its records and provide accurate pricing.

Make sure that all sub-customers are tagged/linked up. The Equinix sales team must ensure that this step is completed in the Salesforce system.

Equinix Precision Time is available in North America (including Canada and Mexico), APAC (including China, Japan, Australia, and Singapore), and EMEA (Europe). The service locations that are offered for a particular Precision Time instance depend on the country that was specified when the instance was created.

Time services are sourced from these locations:

• New York, Silicon Valley, or Toronto for North American services

• Hong Kong or Tokyo for APAC services

• Sydney for Australia services

• Singapore for Singapore services

• Frankfurt, London, or Amsterdam for EMEA services

For a list of Precision Time locations, see Service Locations.

Precision Time uses redundant GNSS (GPS) receiver-based time sources that are backed-up by Rubidium atomic clocks to ensure holdover accuracy. The GNSS receiver and antennas used in the Precision Time infrastructure have the capability to receive signals from multiple GNSS constellations, including GPS L1, GLONASS L1, BeiDou B1, Galileo E1, and QZSS L1. When used in concert, these time sources provide multiple levels of redundancy. The GNSS-enabled grandmaster clocks use Rubidium oscillators that can provide up to sub-microsecond accuracy when locked with the GNSS (GPS) source. Even with a loss of connectivity to the source, the service is able to maintain accuracy up to the sub-microsecond level.

The grandmaster that is visible to customers in the Equinix Precision Time service is a custom hardware-timestamped Grandmaster implementation that we have developed to meet the multi-tenancy needs of our service. Each Precision Time service has a unique process that serves it, with full isolation, over an Equinix Fabric virtual connection. (This also explains why you can adjust settings like the IP addresses, domains, and priority values to match your local environment – all the network and protocol configuration in the service is customized to your connection, and no protocol elements are shared with others.)

The only thing that's shared among different customer connections is the stable timebase for hardware timestamps. And at each Precision Time service site, we use multiple GNSS servers that are protected by anti-jamming and anti-spoofing measures, linked together with White Rabbit hardware. These servers create the stable timebase that all our Precision Time Grandmaster instances use.

Time servers are physical servers with high performance NIC cards where we create a pair of name spaces from two different servers. One is server is Time Server 1, and the other server is Time Server 2.

In a given Equinix Precision Time service location (for example, SV or NY), there are two redundant GNSS reference sources of time which feed time to the time server instances that you see in the right side of our Network Topology diagrams. Any timing server instance in a given Equinix Precision Time service location will use the same time source.

No, Time Server 1 in Location A (NYC) is different from the Time Server 1 in Location B (SV). They are geographically separate, providing you with true geo redundancy.

Yes, each time server receives time from a different GPS clock. One clock is in the New York City (NY) timing chain, while the other clock is in Silicon Valley (SV) from a different timing chain.

In this case, the GNSS reference time sources will be common. However, each timing server instance is isolated and does not share traffic with the other timing servers.

The Precision Time redundancy feature ensures that if all possible options to receive GNSS signals from GPS or other constellations are lost, the built-in Rubidium oscillator inside each grandmaster clock provides precise holdover to maintain accuracy of 1.5 milliseconds over a 24-hour period.

Equinix Precision Time includes a GNSS firewall technology that is integrated with its GNSS servers. When jamming or spoofing interference is detected, the GNSS link to Antenna is disabled, and time is served based on the Rubidium oscillator that is integrated inside GNSS servers. See Technical Concepts for more information.

Antennas can get dislodged or accidentally disconnected, which results in the entire loss of time synchronization. Unfortunately, this is a common occurrence. And GPS (GNSS) signals can be compromised intentionally or unintentionally by jamming and spoofing, which results in no time or incorrect time. This is another big problem. The U.S. presidential mandate released in February 2020 addresses this problem by asking the users of GPS services to mitigate these risks.

Equinix Precision Time service mitigates these risks with dual redundant timing architecture so that the loss of the antenna or the signal doesn't impact the service. In addition, Precision Time also uses atomic clocks (Rubidium oscillators) in its infrastructure to provide holdover for 24 hours, maintaining 1 microsecond accuracy . Lastly, in March 2022, Precision Time implemented anti-jamming and spoofing technology in all our timing infrastructure. This eliminates the GPS jamming and spoofing risks – unlike an antenna-based solution.

Also, the Precision Time service is offered securely through a private IP network. We provide network isolation with an end-to-end network path isolation by extending the Layer 2 domain all the way to the user environment through Private IP addressing (RFC 1918) using the Equinix Fabric port, which is a secure interconnection. In addition, the timing service is authenticated and secure, completely eliminating threats such as Distributed Denial of Service (DDOS) and NTP amplification through spoofed addresses, which are common problems for NTP consumers.

The Precision Time infrastructure is maintained in highly secured IBX data centers inside secure cages. There is no exposure to the outside world or accessibility to Public Networks. Also, Precision Time services are offered to users over the highly secure, dedicated, private Equinix Fabric network which also has no exposure to public networks or internets. In addition, Precision Time services are offered over private IP address spaces defined by RFC 1918.

Because the Precision Time infrastructure is maintained in highly secured IBX data centers inside secure cages, there is no exposure to the outside world or accessibility to Public Networks. Also, access is minimized because the Precision Time services are offered over private IP address spaces defined by RFC 1918.

All Precision Time infrastructure has complete access control, which is available to only a limited number of authorized personnel.

Each customer's service connection is isolated by a private network namespace which is connected to an individual VLAN ID. The VLAN provides isolation during the transport over Equinix Fabric. All our users' virtual connections on Fabric are isolated by VLAN.

Yes, in the EMEA region, you can choose either LD or FR as your service location.

Latency is not a big factor in the accuracy of time. Any delay in network transit is accounted for. However, for a user who is located in Frankfurt, it makes sense to use the local Precision Time service that is sourced from Frankfurt.

Auth0 is now integrated with Equinix Precision Time, adding authentication support for non-federated user identities. This provides an additional layer of security and integration when accessing various Equinix portals and products.

Your browser cache could be the problem. Clear your browser cache and try again. If login or authorization issues persist, raise a support ticket through your local Equinix Service Desk.

No, a single connection always goes to both time servers: 

Equinix Fabric does not support Spanning Tree Protocol (STP) on Fabric switches. Fabric ports are not enabled with STP. Hence, Equinix Precision Time doesn't currently support Active/Standby connectivity.

For PTP with the Standard service tier, only these subnets (netmask) values are allowed:

• /28 (255.255.255.240)

• /29 (255.255.255.248)

• /30 (255.255.255.252)

For PTP with the Enterprise service tier, only these subnets (netmask) values are allowed:

• /26 (255.255.255.192)

• /27 (255.255.255.224)

• /28 (255.255.255.240)

• /29 (255.255.255.248)

• /30 (255.255.255.252)

For NTP with the Standard service tier, only these subnets (netmask) values are allowed:

• /22 (255.255.252.0)

• /23 (255.255.254.0)

• /24 (255.255.255.0)

• /25 (255.255.255.128)

• /26 (255.255.255.192)

• /27 (255.255.255.224)

• /28 (255.255.255.240)

• /29 (255.255.255.248)

• /30 (255.255.255.252)

For NTP with the Enterprise service tier, only these subnets (netmask) values are allowed:

• /21 (255.255.248.0)

• /22 (255.255.252.0)

• /23 (255.255.254.0)

• /24 (255.255.255.0)

• /25 (255.255.255.128)

• /26 (255.255.255.192)

• /27 (255.255.255.224)

• /28 (255.255.255.240)

• /29 (255.255.255.248)

• /30 (255.255.255.252)

The Precision Time service is available in all locations where Equinix Fabric or Network Edge is offered with support for local or remote connectivity options. Currently, Precision Time does not support any other connectivity mechanisms.

You must have an Equinix Fabric port. If you don’t already have one available to use, you must order a Fabric port separately. This is a prerequisite for ordering Equinix Precision Time.

Yes, it is possible. Technically, one port can serve multiple connections. In the case of a reseller, this port can belong to the reseller, and each connection on it can belong to different sub-customer.

Accuracy is measured as the maximum divergence between the time delivered by the service and Coordinated Universal Time (UTC).

The Equinix Precision Time team has set up their own global service level agreement (SLA) monitoring platform which continuously monitors the SLA levels for Precision Time service locations. We also extensively check or take feedback from our customers to ensure they are meeting Accuracy SLA numbers. Based on our own Global SLA monitoring data and feedback from customers, the typical accuracy for synchronization levels achieved by real users is:

• NTP – 30-100 microseconds or less, for the 99.9^th percentile, depending on the network performance at every level

• PTP – 1-10 microseconds or less, for the 99.9^th percentile, depending on the network performance at every level

The Precision Time service is provided over Equinix Fabric, which is a "non-PTP aware" network. You might see a mean path delay in the order of microseconds or milliseconds (in certain metros). However, both PTP and NTP account for the mean-path delay and control the synchronization precisely.

The Precision Time service is provided over Equinix Fabric, which is a "non-PTP aware" network. Jitter conditions can keep changing on the Fabric. Therefore, you might see a mean path delay that varies a lot, compared to when you connect through a non-Fabric network.

Test simulation to explain the delay in Ping/ICMP recovery:

A single device (TOR) was used on the user side during failover testing. The device had a bonded/aggregated interface (two physical ports) with an Active/Standby configuration. The test NTP client was connected to the TOR device. Failover was simulated only on the user side.

Ping/ICMP recovery results with NTP:

• The NTP sync failure time is directly proportional to Ping/ICMP recovery time, which averages ~2.5 seconds.

• The ping recovery delay on a redundant ECX connection without Multicast is the result of the ARP Reachable timeout.

• The recovery time depends on the side which issued the traffic, ICMP ping. We tested ECX failover with the ping issued from the client, A-side, and from the time server, Z-side.

Here are the formulas for Total Recovery Time calculation, with the timelines defined:

• Trm – Total recovery time (in seconds) when the ping was issued from the time server.

• Trc – Total recovery time (sec) when the ping was issued from the client. This is not dependent on ARP caching, but it's also part of the Trm time.

• ARPt – ARP cache time to expire at the moment when failover happened. Could be up to 38 sec for the Ping application. (38 seconds = 30 Base_Reachable_Time + 5 Delay + 3 x Probe)

• TORt – Failover time on the TOR device, client’s A-Side. Could be up to 2 sec, and depends on the moment when failover happened. (This is the switchover time on the client router from primary connection to secondary connection, or the other way around. (1 second to detect failure + 1 second to failover)

  Other considerations:

  • DOWN to UP interface transition time plus MAC learning time.

  • Enabled STP also adds additional time during the transitory states: listening, learning, and forwarding.

  • Equinix Fabric doesn't support STP and recommends disabling STP on the device port connected to ECX.

• ECXt – Time for MAC learning on the ECX side during failover, 1 to X sec.

• EPT_Switch – Time for MAC learning on Arista switches, up to 1 sec.

Trc = TORt + ECXt + EPT_Switch

Trm = ARPt on the time server, for the case when ARPt on server > Trc as calculated above.

Trm = Tc for the case when ARPt< Trc.

PTP and NTP both support the User Datagram Protocol (UDP).

• The typical UDP ports for PTP traffic are 319 (Event Message) and 320 (General Message).

• The official UDP port for NTP (used by ntpd and ntpdate) is 123.

Hardware timestamping is used to synchronize the PTP hardware clock to the time server clock. With this feature, packets are timestamped before they enter the kernel or user space. This avoids any delays caused by kernel or user space processing. PTP works best with the hardware time stamping support on NIC.

Software timestamping is used to synchronize the system clock to the server clock. This approach is used mainly by NTP.

Precision Time provides end-to-end PTP support from the grandmaster clock to the client for multicast configurations. Equinix Precision Time supports multicast with redundant servers to ensure auto-failover and auto-fallback.

Users can now set their PTP domain in the PTP Advanced Configurations settings in the portal. New connections default to Domain 0. (Previously, the default PTP domain setting was 30.)

Equinix Precision Time was initially launched with a pre-set domain value of 30, mainly so that it could be differentiated from the user’s own PTP equipment, which is probably already using domain 0. The selection of domain 30 doesn’t indicate any lack of traceability.

Our service includes redundant GNSS feeds at multiple locations, so traceability isn’t an issue. Each metro that provides the service has GNSS servers (with Rb oscillators) in two separate buildings, connected via White Rabbit, and sent to Timing Servers which drive the timing feeds that our users receive over Equinix Fabric.

Since the launch of Equinix Precision Time, we‘ve provided users the ability to change the domain and priority fields, packet rates, and receive time in PTP/TAI or ARB/UTC timescales. (Some of our users might still be using domain 30, though.)

Yes, Equinix Precision Time is compliant with SMPTE 2110-10 / PTP IEEE 1588.

You can use the following Equinix Precision Time (EPT) server settings to set up the client-side priorities and clockClass:

• EPT Server Priority1 – 128

• EPT Server Priority2 – 128

• EPT Server clockClass – 13

Equinix Precision Time uses the default TTL setting, which is 64 for multicast PTP packets. Refer to the setting in PTP which controls this TTL. However, the TTL setting is not set explicitly.

The Precision Time service is provided over Equinix Fabric, which is a "non-PTP aware" network.

You can use a variety of PTP tools for Linux systems. The most common tools:

• ptp4l

• ptpd

• sfptpd (requires Solarflare NIC)

• Domain Time II (Greyware)

• Timebeat

See the Sample Configurations for basic PTP client settings.

• Accuracy SLA – 50 microseconds or less, depending on the network architecture and other factors in the deployment. Typically, the accuracy is up to 5-10 microseconds . If you consume service locally within the same metro, the accuracy might be up to 1-2 microseconds.

• Availability SLA

  SLA	Requirements to Meet SLA	Comments
  99.9%	You must have and use at least one Fabric port.	You can choose to connect to any available service location as described in Service Locations.
  99.999%	You must create two separate Precision Time service connections using each Fabric port.	For each of your service connections, you can choose to connect to any available service location as described in Service Locations. Connecting to two different service locations will help achieve an additional level of geo-redundancy.

See Prerequisites for information about NIC server support.

Precision Time service is provided through a private, secure, and dedicated interconnection within virtual routing and forwarding (VRF) to two private Equinix servers. An authentication mechanism is not necessary, although MD5 support is available for NTP Enterprise configurations.

A 1 Gbps port is sufficient. Precision Time connections have a low bandwidth requirement.

You can use a variety of NTP tools for Linux systems. The most common tools: 

• ntpd

• chronyd

• ntpdate

See the Sample Configurations for basic NTP client settings.

Stratum 1 NTP servers put their time source (such as GPS) in the RefID field, but Equinix Precision Time (EPT) controls the time a bit differently than a standard Stratum 1 server. EPT manages the traceable time sync outside the NTP service. This means that EPT doesn’t have a refclock, even though its time is in sync.

This means EPT achieves better redundancy through the White Rabbit feeds that synchronize our Timing Servers that provide the service. Also, EPT can isolate the services going to each EPT user to ensure that their traffic is kept private. The null RefID is just a side effect of that.

Note: A null or blank RefID doesn’t affect the quality of the service in any way.

• Accuracy SLA – Equinix Precision Time does not guarantee any SLA for NTP service. However, the service is typically accurate up to 1-10 milliseconds, depending on the network implementation.

• Availability SLA

  SLA	Requirements to Meet SLA	Comments
  99.9%	You must have and use at least one Fabric port or virtual device.	You can choose to connect to any available service location as described in Service Locations.
  99.999%	You must use two separate Fabric ports, or virtual devices, created on primary and secondary Fabric networks. You must create two separate Precision Time service connections using each Fabric port or virtual device.	For each of your service connections, you can choose to connect to any available service location as described in Service Locations. Connecting to two different service locations will help achieve an additional level of geo-redundancy.

Yes, for support purposes, Precision Time now monitors performance and collects data from both the Timing Server and Service Level Objective (SLO) monitoring servers in remote IBX data centers. Alerts are generated and can be sent to support teams for analysis, when requested through a Support case. Alarms are triggered when SLO thresholds are breached, or when outages threaten Precision Time performance, so that potential problems can be addressed before they become issues.

For technical issues, you can Submit a Trouble Ticket in the Equinix Customer Portal. The status of existing tickets can be checked in Support > Support Case History on the Equinix Customer Portal. See Support for more information.