Why Standard Ethernet Fails Real-Time Systems (And What TSN Does About It)

Qbit Labs — Wed, 01 Jul 2026 09:05:22 +0000

If you've ever built a real-time control system on top of standard Ethernet, you've probably hit this wall:

Everything looks fine in testing. Then in production, under load, timing goes wrong in ways that are genuinely hard to debug.

That's not a bug in your code. It's Ethernet doing exactly what it was designed to do — deliver packets eventually, with no hard guarantees on when.
For web apps, that's fine. For a robotic arm, a radar system, or an autonomous vehicle's control loop, it's a fundamental mismatch.

The problem with "fast enough"
Standard Ethernet is fast. But fast ≠ deterministic.
Jitter, variable latency, and traffic bursts are baked into how standard Ethernet works. When you share a link between control traffic and bulk data, your critical packets compete for the same queue — and there's no mechanism to guarantee they win.
IEEE recognised this and developed the Time-Sensitive Networking (TSN) standard suite — a set of 802.1 amendments that bolt deterministic behaviour onto standard Ethernet without replacing the infrastructure.

What TSN actually adds
A few key standards worth knowing:
802.1AS (gPTP) — Precision time sync across all nodes, sub-microsecond accuracy. Every device on the network shares a common clock.
802.1Qbv (TAS — Time-Aware Shaper) — Divides the link into time slots. Critical traffic gets its own slot, guaranteed, regardless of what else is on the wire.
802.1Qav (CBS — Credit-Based Shaper) — Smooths out bursty traffic so high-priority streams get consistent bandwidth.
802.1CB (FRER) — Frame replication across redundant paths + duplicate elimination at the receiver. Fault tolerance without custom failover logic.

802.1Qci — Per-stream filtering and policing. One misbehaving node can't starve the rest of the network.
How this looks in hardware
Implementing TSN in software adds latency and CPU overhead — defeating the point. The right approach is hardware offload.
The Qbit Labs QEP-T001 is a PCIe NIC that does exactly this — a hardware-accelerated TSN endpoint for industrial PCs and embedded hosts.

The transmit path: Host → PCIe DMA → Traffic Buffers → CBS/TAS Shaping → FRER Replication → Egress Timestamping → MAC → Wire
The receive path: Wire → Ingress Timestamp → Stream ID + Filter → FRER Duplicate Elimination → DMA → Host
A central gPTP state machine handles sub-microsecond sync with a 1 PPS output via SMA connector for hardware clock reference.
Because it's all offloaded, the host CPU sees a normal NIC — no real-time kernel patches, no busy-polling required.
Who actually needs this

Industrial automation — multi-axis motion control, PLC networks, SCADA
Automotive — in-vehicle Ethernet for ADAS, sensor fusion, drive-by-wire
Defence / aerospace — deterministic comms for radar, avionics, sensor arrays
AVB/media — audio/video bridging where sync actually matters

The build vs. integrate question
If you're prototyping TSN from scratch — writing your own gPTP stack, CBS scheduler, FRER logic — expect months of work before you're close to spec-compliant.
A pre-verified TSN endpoint with clean, documented RTL lets you skip that and focus on the actual system you're building.

TSN is already shipping in automotive ECUs, factory controllers, and defence platforms. If you're working on anything that needs deterministic networking, worth a look at what's available before rolling your own.
Questions or building something in this space? Drop a comment — happy to dig into specifics.

DEV Community: Qbit Labs

Why Standard Ethernet Fails Real-Time Systems (And What TSN Does About It)