Skip to main content

EmberRTOS RT

EmberRTOS RT is the real-time variant of EmberRTOS. It is the same immutable, transactionally updated foundation described in EmberRTOS (Standard), which covers the OS fundamentals, running a PREEMPT_RT real-time kernel in place of the general-purpose one. Use it wherever a workload has a hard deadline: motion control, safety interlocks, high-rate deterministic I/O, and PLC/SCADA or drive timing.

What "real-time" means here​

Real-time is not about being fast on average. It is about a bounded worst case. A control loop that is usually quick but occasionally stalls for milliseconds will still miss its deadline and can damage equipment or trip a safety function. EmberRTOS RT targets a worst-case wake-up latency of 100–200 µs under sustained load, and measures the worst case directly rather than reporting a comfortable average.

The real-time kernel​

Most distributions either don't ship a real-time kernel at all or gate one behind a paid enterprise subscription. PREEMPT_RT has been part of the mainline Linux kernel since 6.12, so a real-time kernel is now simply mainline kernel source compiled with CONFIG_PREEMPT_RT=y and RT-friendly options, rather than an out-of-tree patchset.

EmberRTOS builds and ships its own real-time kernel. That means the real-time capability is ours to tune and support end-to-end, not a third-party dependency. If a node is provisioned as RT but a verified real-time kernel cannot be resolved, provisioning fails safe and refuses rather than silently booting a general-purpose kernel under a real-time badge.

Measured performance​

EmberRTOS RT was booted on commodity 4-core Intel desktop hardware (not server-grade, not hand-picked), tuned, and measured under sustained load with the industry-standard cyclictest tool. Over a 300-second run, roughly 1.5 million samples, on the isolated real-time cores while the housekeeping core was saturated with hackbench plus CPU-burn load:

Real-time coreMinAvgWorst-case
Core 11 µs1 µs36 µs
Core 21 µs1 µs42 µs
Core 31 µs1 µs31 µs

Worst-case wake-up latency: 42 µs. Average: ~1 µs. Against the 100–200 µs industrial target, that is roughly 2.5× inside the tightest end of spec and nearly 5× inside the loosest, on unremarkable desktop silicon. Kernel 6.12.95 SMP PREEMPT_RT, cyclictest -m -p99 -i200.

A 42 µs worst case leaves better than 4× margin under a 200 µs control-loop budget, and still clears a 100 µs budget with room to spare.

Qualification note. The figures above come from a 5-minute characterization run. Production sign-off for a given hardware platform should include a 24–72 hour soak under representative application load to catch rare tail events. The measured result is well inside target, so this is a qualification formality rather than an open question about whether the target is met.

Tuning​

The real-time result depends on tuning as much as on the kernel. EmberRTOS RT applies the standard PREEMPT_RT tuning set:

  • Deep C-states disabled (processor.max_cstate=1, intel_idle.max_cstate=0): deep idle states add wake-up latency; this is the single biggest determinism win.
  • CPU isolation: housekeeping is kept on CPU0; the remaining cores are reserved for real-time work. IRQs and general load are pinned to the housekeeping core so the real-time cores stay clean.
  • IRQ affinity: device interrupts are steered off the real-time cores.
  • Watchdogs off, tick skew on: removes periodic jitter sources.
  • performance CPU governor and unbounded RT runtime: no frequency scaling or RT throttling on the hot path.

For a known deployment with a fixed core count, boot-time CPU isolation (isolcpus/nohz_full/rcu_nocbs across the upper cores) recovers the last few microseconds.

Enabling RT on a node​

The real-time variant is selected at provisioning time. During first-boot configuration, an RT flag on the configuration medium causes EmberRTOS to install the real-time kernel, apply the tuning above, and set the real-time kernel as the default boot kernel, inside the transactional snapshot, so it is atomic and reversible like any other change. A reboot activates it.

After boot, confirm the real-time kernel is active:

uname -v      # look for PREEMPT_RT
cat /etc/emberrtos/kernel-flavor   # -> rt

Validating on your hardware​

Latency depends on the specific machine, so EmberRTOS RT ships a self-contained live validation image, the real-time kernel plus a cyclictest-based jitter tool, that boots entirely in RAM (nothing is written to disk) and reachable over SSH. Boot it on a candidate machine and run:

jitter 300     # 5-minute worst-case latency test under load

The reported Max is that machine's worst-case wake-up latency. This is how you qualify a hardware platform before deploying EmberRTOS RT on it, and how the 42 µs figure above was produced.

When to use EmberRTOS RT​

Deploy EmberRTOS RT when the node must respond within a bounded worst-case time:

  • Motion control and servo/drive loops
  • Safety interlocks and protective functions
  • High-rate deterministic data acquisition
  • PLC/PAC runtimes (e.g. CODESYS) with cycle-time guarantees

For everything else, whether that's gateways, telemetry, container hosts, or general edge compute, use EmberRTOS (Standard), which avoids the tuning constraints (isolated cores, disabled idle states) that real-time determinism requires.

References​

  • The full methodology, comparison data, and appendices are in the EmberRTOS Real-Time Linux White Paper (build metrics, package audit, tuning specifics, and complete cyclictest results).
  • PREEMPT_RT / CPU isolation (kernel.org)