Guaranteeing Determinism Takes More Than Just TSN

Time-Sensitive Networking is a set of IEEE 802.1 standards that extends ordinary switched Ethernet with bounded latency and traffic isolation, while staying compatible with the devices already on the network. Two parts of it matter here: a shared time base across all devices, and the Time-Aware Shaper, which divides each cycle into scheduled slices and opens the link to a given traffic class only during its own slice.

The Promise of TSN, and the Condition Attached to it

Time-Sensitive Networking has become the standard answer to determinism via Ethernet, and it has certainly earned that position. The Time-Aware Shaper opens a hardware-enforced window for your real-time traffic and holds everything else back while it is open. Background load on the link cannot delay a frame that makes it into that window.

The condition is in that last clause. TSN protects a frame that is ready on time. But that says nothing about whether an application will provide the data on time. It is also unforgiving about the difference: a frame handed to the network interface after the window has closed is not delivered slightly late, it has to wait for the next cycle.

So TSN does not create determinism by itself. It creates a hard deadline that your application is now responsible for meeting. Missing the window turns a small timing weakness on the application side into a full-cycle delay. We wanted to see what that costs in practice, so we measured a publisher-to-subscriber path under CPU load, under background network traffic, and under both at once, rather than on an idle bench.

Why an Ordinary Application Misses the Window

General-purpose operating systems are built to share a machine fairly among many processes. They are not built to hit a fixed point in time to microsecond accuracy. When an ordinary application asks to be woken at an exact point in time so as not to miss a cycle boundary, the operating system gets close. But close for a general-purpose scheduler is coarser than a tight transmission window.

The frame therefore arrives a little late, and keeps arriving a little late, cycle after cycle. In our measurements, an untuned application with the gate enabled missed its window on the large majority of cycles even under idle conditions. Every miss cost close to a full cycle of latency.

That produces a result most teams do not expect. Switching TSN on for that application, with a tight window, did not improve its latency. It was substantially worse than leaving TSN off. The network layer behaved exactly as designed in all of those runs; it protected a window the application never reached in time.

Both Layers, or Neither

The two layers fail in opposite directions:

• An application with correct timing but no gate cannot stop background traffic from delaying its frame once the frame is competing for the wire. Network isolation is a network mechanism, and scheduling discipline does not substitute for it.
• A gate behind an application with no timing discipline protects a window that nothing arrives in, so the guarantee gets paid for and never used.

Only with both of these layers in place did we measure low latency and zero missed deadlines under simultaneous CPU and network stress. The two are not just separate improvements that add to each other. Each one is what makes the other useful.

The Missing Link Nobody Sells You

Consider who supplies what. TSN vendors sell the network guarantee, and they deliver it. Operating systems supply the ingredients for the application-side guarantee, but only the ingredients. You still have to know which ones exist, which ones matter for a cyclic task, how to configure them, and how to keep that configuration correct as the application grows.

The settings are not obvious either. The behaviour responsible for most of the lateness we measured is a sensible default for general-purpose software and the wrong default for a control task, and nothing warns you about it. You either know about it beforehand, find it by measuring, or you do not find it at all.

That distance between "the operating system can do this" and "somebody on this project knows how" is where deterministic communication projects stall. The work is specialised, easy to get subtly wrong, and invisible under light testing. It is also nobody's product, which is why industrial application teams, who are rarely staffed for it, end up owning it anyway.

How Xentara Solves it For You

Xentara takes over and controls the application's execution timing. A real-time task track runs with the correct scheduling and timing configuration applied automatically on the core you assign it, so there is no setting for the developer to find, no scheduling code in the application, and nothing that quietly stops being correct later in the project.

The periodic trigger is also anchored to absolute clock time instead of counting a fixed interval forward from process start. That matters more than it sounds. A gate schedule is a repeating pattern on a synchronised clock, and an application driven by a free-running interval has no guaranteed phase relationship to that pattern, so it can drift out of alignment over a long run. Keeping it aligned is otherwise application code that somebody has to write and maintain. On Xentara the runtime supplies it out of the box.

The Setup

We built a benchmark to test this in practice. A transmitting system and a receiving system exchange messages on a 1 ms cycle, and we timestamp the moment of transmission and the moment of reception at the application. Our comparison value is true end-to-end latency: that transit time plus the wake-up delay of the sending task. The wake-up delay has to be included. Latency measured from the moment a task happens to start running hides the delay we are investigating.

The testbed consists of two physical nodes connected via a single TSN-capable Ethernet switch, as illustrated below. The publisher node is an Advantech IPC-603MB industrial embedded computer equipped with an Intel Core i5-10500E processor. The processor features six cores and twelve threads with Hyper-Threading, and a shared 12 MiB L3 cache. Network connectivity is provided by an Intel i225-V 2.5 Gbit/s NIC with hardware timestamping and TSN support. The system runs an x86-64 Linux environment with the PREEMPT_RT kernel, version 6.12.74.

The subscriber node is a BeagleBone AI-64 equipped with two ARM Cortex-A72 cores. Each core has a private 64 KiB L1 data cache and a 96 KiB L1 instruction cache, while both cores share a 1 MiB L2 cache. The processor does not provide an L3 cache or a hardware mechanism for cache partitioning. The BeagleBone runs an ARM64 PREEMPT_RT kernel, version 6.6.127-rt-arm64-k3-r50.

Both nodes connect to the TSN switch via 100 Mbit/s Ethernet links. The switch is a Hirschmann BOBCAT BRS20 running HiOS-2S firmware 10.3.06. It implements IEEE 802.1Qbv gate schedules and IEEE 802.1AS time synchronization, and provides ingress classification by IP DSCP codepoint and by IEEE 802.1D/p priority. Routing traffic through a switch, rather than a direct cable, is representative of a real industrial deployment.

Our Measurements

Four configurations were tested under four load conditions, 10,000 messages each. "Standard application" here means an ordinary application with no real-time timing configuration. The CPU load is artificial background work on the cores not reserved for the real-time task. The network flood shares the sender's transmit interface with the real-time stream, so the two compete before either reaches the network.

All values are mean true end-to-end latency in microseconds, and lower is better. On a 1 ms cycle, anything approaching 1000 means the message effectively missed its cycle.

Adding TSN to a standard application made things worse under every condition we tested, by roughly a full cycle, because the application keeps missing its guaranteed transmission slot and has to wait for the next one. Xentara without TSN shows the opposite weakness: it copes with CPU load but not with network contention, since correct timing cannot protect a frame that is already competing for the wire. Only the combination stays low throughout. Under CPU load alone the two Xentara columns are level, which is what you would expect, because with nothing else contending for the link the gate has nothing to protect against.

If you are validating your own system

• Measure how late your task actually wakes up, not only how long the frame takes to arrive. Latency measured from the moment your task happened to start running hides the delay you are looking for.
• Judge the result on jitter and worst case rather than on the average, because a system can post a respectable mean with an unstable tail underneath it.
• Run the test under the load the machine will really see. Almost none of this shows up on an idle bench.

The Takeaway

TSN makes the network deterministic. Determinism on the application side is a separate problem, and that is the part Xentara covers. Our best results needed both, and neither on its own came close. Before you trust a gate in production, confirm your application can meet it under realistic load.