Red Hat Enterprise Linux delivers deterministic performance for time-sensitive networking

The industrial world runs on timing and consistency. In manufacturing and operations, a predictable outcome isn't a nice-to-have; it's the core promise of the industrial system itself. Whether you're managing complex motion control or critical process loops, network communication must be reliable and predictable.  Time-sensitive networking (TSN) is the essential evolution of Ethernet that brings determinism and a guaranteed delivery schedule to a standard open industrial network.

But here's the reality check for information technology (IT) and operations technology (OT) leaders: TSN is great for the wire and hardware, but it's only as good as the software stack running on the devices at the edge. A jittery operating system can ruin a perfect TSN network before a packet ever leaves the device. Things like hardware interrupts, cache swapping, or even heavy application use (like AI or video management) can significantly impact the OS's ability to build and deliver packets in that crucial, repeatable fashion.

At Red Hat, we understand the needs of Industrial and we know how important it is to be at peak performance. So we set up tests to prove it. We recently completed a hands-on technical validation, in collaboration with Intel, to demonstrate how Red Hat Enterprise Linux (RHEL) and Red Hat Device Edge deliver the precise, deterministic performance required for industrial TSN.

Red Hat Enterprise Linux for real-time performance

Our core approach to tackling this challenge is centered on two elements:

1. A real-time kernel: A tuned operating system designed to use a deterministic scheduler to ensure critical tasks execute in fixed time bounds. Guaranteed predictable execution of high-priority workloads by controlling interrupt handling, resource locking, and context switching.
2. Scalable, common OS: A single OS that scales from heavy-duty server-class machines to constrained far-edge devices, capable of running soft PLCs, I/O blocks, and advanced analytics wherever they’re needed. It includes the industrial drivers required for efficient TSN performance.

A common OS platform is a huge win for both IT and OT, providing significant efficiencies in design, architecture, cybersecurity, and management across the entire industrial automation stack. Red Hat’s commitment to open standards and open source ensures the integrity of TSN’s open interoperability charter.

The testing grounds: Test bed layout and setup

We designed a two-part test to clearly show the impact of enabling TSN on a standard RHEL platform when faced with real-world network congestion. The test was designed to show consistent performance and reduced jitter for industrial workloads when TSN is enabled on RHEL.

Hardware and software 

The test consisted of two identical IPCs with TSN capable network interfaces running the real-time version of RHEL.

• System: iEi Tank-XM811 (2 units)
• CPU: 13th Gen Intel(R) Core(TM) i9-13900TE
• Network interface: Intel Corporation Ethernet Controller I225-LM (rev 03)
• Operating system: RHEL 9.6
• RTC-Testbench: An open source real-time and non-real-time traffic validation tool for converged Ethernet networks. It simulates an Open Platform Communications (OPC) unified architecture (UA) stack.
• Programmable logic controller (PLC):  A Codesys soft PLC loaded with an application that burns up CPU cycle times and mirrors data back through the network.  

The testing concept

The RTC-Testbench includes a reference application that generates traffic and checks the timing of packets. It also works with a mirror application (codesys soft plc is acting as a data mirror). 

• Machine 1 (reference): Configures Ethernet, generates time-critical OPC UA traffic, checks the response, and logs results.
• Machine 2 (mirror): Configures Ethernet, reads the traffic, mirrors it back via a codesys soft PLC, and generates non-time critical traffic.

The prerequisite for the testbench is that it relies on IEEE 802.1AS generalized Precision Time Protocol (gPTP) to provide a reliable time reference down to sub microseconds for all RHEL edge-control nodes on the TSN sub-net.

Setup and optimizations

The setup included critical optimizations to ensure the test was running in a controlled, real-time environment. This involved using kernel boot parameters for CPU isolation and running the reference and mirror scripts on those isolated CPUs.  

Ethernet controller: Intel Corporation Ethernet Controller I226-IT (rev 04)
Subsystem: ASRock Incorporation Device 125d
BIOS TCC mode = on
L3 cache allocation = enabled
Intel speed shift intel_pstate = disabled
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 4fa00000 (32-bit, non-prefetchable) [size=1M]
Memory at 4fb00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 9c-6b-00-ff-ff-01-17-86
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

The data before and after TSN

Our test used a consistent, standing load of one OPC UA packet per millisecond (1ms) as the time-critical, real-time data. The non-critical "network disturbance" was simulated by transferring a large 1GB FTP file between the two machines.

We looked primarily at two key metrics:

• Average OPC UA RTT (Round Trip Time) data: The overall average delivery time.
• Max OPC UA RTT jitter: The largest deviation from the mean RTT. High jitter is the killer of predictable industrial control.

What the data really tells us

We got some interesting results from these tests.

Test 1B: No TSN 

• While the average packet delivery remained stable, the Max Jitter jumped dramatically to 2684 µsec when the 1GB FTP transfer started
• Looking at the visual data, the maximum round trip time for the OPC UA traffic spiked significantly and stayed there for the duration of the transfer. This level of jitter is absolutely unacceptable for a deterministic industrial workload

Test 2B: With TSN 

• With TSN enabled, the Max Jitter was drastically reduced to a mere 67 µsec.
• The system achieved no discernible spikes or outliers in its real-time traffic delivery.
• The price of this determinism? The non-critical FTP data transfer rate dropped from 158.3 MB/Sec to 89.4 MB/Sec

The results are unambiguous: TSN works by sacrificing non-critical traffic to significantly reduce the jitter for time-critical, real-time data transmissions, providing a deterministic system with no outliers.

The bottom line for IT and OT leaders

We’ve shown that RHEL has the foundation (the real-time kernel and certified drivers, available and included with all RHEL and Red Hat Device Edge offerings) to meet the exacting standards of TSN. This isn't just about moving data, it's about guaranteeing predictable control for motion, process, and discrete applications. For manufacturing, this means:

• Risk reduction: You can confidently mix critical and non critical traffic on a single wire without fear that a large data transfer (like pushing a new AI model or running an inventory scan) will compromise your critical control systems.  More importantly, as your device and load on the industrial network increase over time you can be confident your critical system performance is preserved.
• Simplicity and efficiency: You reduce the complexity of managing disparate network stacks. A common OS that scales from the smallest sensor interface to the largest server class machine streamlines design, operations, and patch management.
• Open future: By relying on open standards (TSN) and open source (RHEL or Red Hat Device Edge), you avoid vendor lock-in and ensure interoperability as your industrial automation needs evolve.

Combined with TSN hardware, Red Hat Enterprise Linux delivers the consistent, reliable foundation that your most critical industrial workloads require. It's time to build your edge on a foundation you can trust.

Stop by the Red Hat booth at SPS 2025 in Nuremberg, or reach out to the author, to engage in conversations on this topic.