Towards telco-grade quality: Telecom GrandMaster performance validation in Red Hat OpenShift

Red Hat OpenShift 4.14.6 released the Technology Preview of the Telecom GrandMaster (T-GM) feature for Intel Timing Synchronization cards. Characterizing the performance of the T-GM functionality is key to better accommodate the requirements of Red Hat’s O-RAN partners and customers. To help support this milestone, we recently released a T-GM test suite that delivers test reports including specific T-GM key performance metrics according to ITU-T G.8272 specification.

Given this context, are you trying to validate the performance of your T-GM clock in OpenShift? Are you trying to understand the results obtained by Red Hat T-GM test reports? Are you just interested in learning about synchronization performance evaluation for telco use cases? In any case where the answer to any of these three questions is “Yes,” this blog post is for you.

Analyzing results represented in these reports is another activity of the test process and usually requires specific synchronization expertise. On one hand, the data included in the T-GM test reports validates if  Red Hat OpenShift under test is capable of functionally behaving as a T-GM. On the other hand, the test report includes specific T-GM key performance indicators to verify that the T-GM complies with the required performance T-GM class.

The guide available here details the interpretation of all data shown in Red Hat T-GM test reports, thus simplifying and improving the digestion of the key validation aspects of a T-GM for non-experts in the synchronization area.

Validate your OpenShift environment

The first category of tests that you can find in our T-GM test reports are aimed at providing the validation of the environment where the T-GM performance tests need to be executed. The results can confirm or rule out the environment where you plan to run the T-GM performance evaluation. In other words, the results of the validation environment section in our T-GM test report will tell you whether it is or isn’t worth it to take a look at the performance T-GM report.

Environment required to evaluate the performance of Red Hat OpenShift T-GM

A minimum set of hardware and software requirements follow:

• A Single Node OpenShift installation, with at least release 4.14.6 and the PTP Operator installed.
• A Red Hat certified Intel timing card capable of acting as a T-GM. Currently, E810-XXVDA4T with GNSS (WestPort Channel) and E810-CQDA2T with GNSS (Logan Beach) support such capabilities.
• A GNSS antenna with clear sight of the sky connected to the u-Blox ZED-F9T GNSS receiver of the Intel timing card capable of acting as T-GM clock (WestPort Channel or Logan Beach with GNSS receiver option).

Achieving telco-grade quality

Out of all the different telco-grade Key Performance Metrics (KPIs) included in the T-GM test reports, let’s focus on the synchronization golden KPI: the Time Error (TE). TE quantifies the phase deviation between the two clocks: a clock under test (or measurement) and a reference clock. TE is calculated by measuring the difference between the significant instants (or edges) of two clocks. The measurement, typically represented as a unit of time, represents the relative difference with respect to the phase of two clocks.

Even when the clock under test is considered to be synchronized to the reference clock, there are always errors that can be observed in the received synchronized clock instance.

The graph below shows the distribution of the TE introduced between the Digital Phase Locked Loop (DPLL) signal and the phase of the E810 PTP Hardware clock in a E810-XXVDA4T with GNSS. Looking at the graph below, we can provide the following initial observations:

Time Error T-GM KPI is within limits allowed by PRTC-A and PRTC-B classes

• The measured TE could vary over time. Because of this reason, it is important to confirm that TE is measured over a sufficiently long time period. A minimum test duration of 1000s under normal, locked operating conditions is recommended by ITU G.8272. And this is one of the reasons why we let the user specify the duration of the measurement.
• The measured TE can be negative or positive. A negative TE occurs when the measured significant instant of the clock under test arrives later than the one of the reference clock. A positive TE occurs when the measured significant instant of the clock under test leads the one of the reference clock.
• A key value of interest is the maximum absolute TE, which can be denoted as max|TE|. The max|TE| is a single value, representing the TE value that lies further away from the reference clock. In this case max|TE| is 2ns, which is well below the limits allowed by PRTC-A (i.e., within 100ns) and PRTC-B (i.e., within 40ns) classes.

For more details on other ITU-T G.8272 KPIs included in our T-GM test reports, such as Maximum Time Interval Error or the Time Deviation, please see a detailed guide here.  Red Hat continues to closely work with partners like Intel to drive telco-grade quality throughout the value chain. The Red Hat open source T-GM test suite helps to attain this milestone by verifying that high performance T-GM software is shipped with every OpenShift release.