Worst-case execution is a different discipline

A control loop is judged by its worst iteration. A throughput workload is judged by its average one. These are not two settings of the same dial. They are different engineering disciplines, with different instincts and different definitions of a good result, and modern robotics puts them on the same physical node.

That a wide-area round trip cannot sit inside a control budget is settled, and it belongs to another argument. The local problem is the more interesting one, because it looks solved. The compute is on the machine. The wire is short. The loop closes without leaving the chassis. And the machine can still miss its deadline, because a throughput workload sharing the node takes determinism from the control path through mechanisms nobody wrote down and nobody intended.

Worst-case execution is a discipline rather than a tuning exercise. Most of what it requires is a list of things you agree not to share.

Two definitions of good on one node

The control path's requirement is a bound. Stop authority, interlocks, and motion limits have to respond inside a fixed time, every cycle, under every condition the machine will encounter. A late response is not a slow response; it is a wrong one. The metric is the worst observation over the life of the system, and the average is beside the point.

The inference plane's requirement is throughput. Perception and policy models want large batches, deep pipelines, big working sets, and an accelerator kept as close to fully occupied as scheduling allows. Every one of those techniques improves throughput by making the tail worse. Batching in particular trades worst-case latency for utilization directly — that is not a side effect, it is the mechanism.

So the two workloads do not merely differ. They optimize in opposition. A scheduler asked to serve both by splitting the difference hands the control path a distribution when what it needed was a ceiling.

How a throughput workload steals determinism

The theft is rarely visible in the code. The control path can be unchanged byte for byte and still take longer to run, because most of what determines its execution time is not in its own instruction stream.

Cache and memory bandwidth. A model's working set is large by design, and it evicts everything else. The control task's data is no longer close, so identical instructions take longer to execute. Memory bandwidth has no notion of priority either: a task that saturates it slows every other task on the package, whatever the scheduler believes about their relative importance.

Shared interconnects and device queues. The links between host and accelerator, storage queues, and network interface queues are first-come structures underneath whatever ordering software imposes on top. A small control message queued behind a large transfer waits for the transfer, not for its own urgency.

Interrupt load. High-rate sensor ingest generates interrupts at a rate set by the sensors, and each one takes cycles from whatever was running. The control task's timing becomes partly a function of how many streams are live.

Power and thermal management. Clocks move underneath you. Sustained accelerator load heats the package, the governor responds by lowering frequency, and the control loop's compute time changes without a line of code changing. Its worst case now depends on ambient temperature and on the load history of the preceding minutes. Inside a sealed enclosure on a hot floor, that is not a corner case.

Allocators and reclamation. Any runtime that reclaims memory in bulk introduces pauses whose length depends on heap state, which is to say a distribution rather than a bound. General-purpose allocators have a version of the same problem on their slow paths under fragmentation. A control path that allocates has an unbounded term in it.

Priority inversion. A high-priority task blocked on a resource held by a low-priority one runs at the low-priority task's schedule. This is thoroughly understood and still endemic, mostly because the shared resource is usually not an obvious lock. It is a logging pipeline, a driver's internal mutex, a shared arena, a device everyone happens to touch.

Accelerator work does not preempt. On the timescales a control loop cares about, a dispatched kernel runs to completion. Preemption granularity belongs to the hardware and the runtime, not to the priority assigned by an operating system. Whatever else needs the device waits for what is already on it.

The tail is the only part that matters

Every mechanism above shares the property that makes it dangerous: it is nearly invisible in average-case measurement. Each event is occasional, each costs little on its own, and the mean barely moves. What changes is the shape of the far end of the distribution, which is the only part a control engineer is permitted to care about.

Worse, these events are not independent of the situation. The inference plane works hardest when the scene is complicated. The scene is complicated when there are people, clutter, and motion. That is exactly the moment the control path's response time matters most, which means the interference is correlated with the hazard rather than spread evenly across the shift.

A demonstration that the loop is fast is therefore not evidence about the loop's bound. It is evidence about the loop's average, under whatever conditions the demonstration happened to create.

What separation actually requires

Priority is a scheduling policy, and scheduling policy has no authority over a memory controller, a cache, a thermal budget, or a device queue. Real separation means partitioning execution resources rather than prioritizing within a shared pool: the control path owns what it runs on, so its timing is not a function of what the inference plane is doing. That costs capacity, and the capacity is what the bound is purchased with.

The relationship between the two has to be one-way as well. The control path never blocks on the inference plane — no synchronous call, no shared lock, no waiting on a queue the inference plane fills. Requests arrive as advice on a non-blocking channel, the control path takes the most recent one and proceeds, and advice that arrives late is simply not used. Authority runs in the other direction and only in the other direction.

The fail posture then has to be correct with the inference plane absent, not merely degraded from a healthy state. The test is blunt: remove it entirely and confirm the machine still holds its limits and still stops on command. A design that survives that test has no hidden dependency left to discover at an inconvenient moment.

The last requirement is a matter of habit more than of mechanism. The model is loading, the model has crashed, and the model is slow are ordinary states with defined handling, not incidents. A system that classifies them as exceptions will be exercising its exception paths for the first time on the day one of them happens mid-shift.

Measuring the claim honestly

A worst-case claim cannot be validated by running the happy path, because the happy path is the case already believed. The honest practice is adversarial. Saturate the inference plane with a realistically large model at a realistic input rate. Let the enclosure reach thermal steady state instead of measuring a cold box briefly. Add the device contention, the ingest interrupt load, and the storage traffic a working shift produces. Then measure the control path, and report the worst observation rather than the typical one.

A campaign like that has to sweep rather than sample, because the worst case appears at particular alignments of load, temperature, and timing that a short run will miss. And the result has to be read for what it is: an observed maximum, not a proof of a bound. That is the deeper reason for partitioning. When resources are separated by construction, measurement confirms a property the design already argues for. When they are shared, measurement is the whole argument, and it is an argument a longer run can always overturn.

The split has to be architectural

In E31 Network's edge node, the determinism split is being designed as a structural property rather than a convention: separate execution resources for the control path, a one-way relationship in which control holds authority, and a fail posture that does not consult the inference plane at all.

The payoff is not only timing. If a model's execution can perturb the control path's worst case, then every model update is a change to a timing property, which makes every model update a safety question, which means updates move at the speed of re-argument. Separate them and a model update is a change in capability and nothing else. The discipline of separation is what buys the freedom to iterate.