Real-time workload
Compute work that must answer at the moment it is asked: robot control, live perception, safety functions, interactive tools. None of it belongs on E31 Network.
· 2 min read
IN SHORT
A real-time workload is compute work that must produce its answer the moment it is asked, such as robot control, live perception for a moving machine, safety functions, or a tool a person is waiting on. E31 Network does not take real-time work and is not designed to. It stays on dedicated local infrastructure, edge devices, or the team's own systems; the heavy, occasional work around it becomes a job.
A real-time workload is compute work that must produce its answer at the moment it is asked, within a window set by the physical or human process it serves. Robot control loops, live perception for a moving machine, safety functions, and interactive tools a person is waiting on are all real-time workloads. None of them belong on E31 Network.
Why it matters
The distinction between real-time and batch is the most important line in the network's design, because getting it wrong is dangerous in one direction and wasteful in the other. Send a control loop to a shared queue and the machine it controls stops being safe. Keep a retraining run on the machine's own hardware and that hardware has to be sized for the biggest run it will ever do.
Drawing the line cleanly also gives a team a plan. The live part of a system, the part that perceives, decides, and acts in the moment, stays on dedicated local infrastructure, on edge devices, or on the robot itself. The heavy, occasional part, such as retraining the model, evaluating a new version, or processing the footage the live system recorded, becomes a job.
How it works on E31 Network
E31 Network does not take real-time workloads, and the design does not aim to. It is being built as hourly compute for batch and asynchronous jobs: training, inference that can wait, simulation, and processing. It is not robot control infrastructure, not a facility control plane, not an autonomous-system runtime, and not an edge control platform.
The test the design applies is whether the work can wait for a queue. If it must answer now, it stays with the team. If it can run tonight, it can run on the network. A job on the network may sit in a queue before it starts, runs unattended, and returns its output when it finishes, none of which is compatible with a loop that has to close in the moment.
The practical pattern is a split. A fleet of robots keeps perception and control local, and the forty hours of camera footage those robots recorded becomes a processing job. A live assistant keeps its interactive path on the team's own systems, and the evaluation suite that scores a new model version runs as a batch. The workloads page lays out which side each kind of work falls on.
Related terms
Questions this raises
- Could the network ever handle a control loop if it were fast enough?
- No, and the design does not aim for it. A job may wait in a queue, runs unattended, and returns its output at the end, none of which fits a loop that has to close in the moment. Speed is not the issue; the shape of a job is.
- Where should the real-time part of my system run?
- On infrastructure the team controls and that sits with the machine: dedicated local servers, edge devices, or the robot's own compute. Teams that want AI compute in their own rack for this have Czar, Element 31's sealed appliance, as the sibling product.
- What part of a robotics system is a network job?
- The heavy, occasional work: retraining the perception model on new footage, evaluating a candidate model before it ships to the fleet, processing the camera footage the robots recorded, or running a sweep of simulations. None of that needs to answer now, so all of it can wait for a queue.
KEEP READING