Queue
Where a submitted job waits when the compute it asked for is not yet free. The meter does not run while a job is queued, and a job that can wait is a job suited to the network.
· 2 min read
IN SHORT
A queue is where a submitted job waits until the compute it requested is free. On E31 Network the meter does not run while a job is queued; a team would pay only for hours compute is held and running. The queue also defines the network's boundary: work that can wait for a queue belongs here, and work that must answer now stays on the team's own systems.
A queue is the place a submitted job waits when the compute it asked for is not yet free. Jobs sit there until capacity comes available, and a job that can wait in a queue is, by definition, a job suited to the network.
Why it matters
Queues are what let a shared pool stay busy without being oversized. Without a queue, the pool would need enough capacity to start every job the moment it arrived, which means idle hardware most of the time. With a queue, the pool can run close to full and absorb bursts by letting some jobs wait.
Queues also set the boundary of the whole model. The test for whether a workload belongs on the network is whether it can wait for a queue. Robot control, live perception, safety functions, and interactive tools cannot, so they stay on dedicated local systems. Retraining, footage processing, simulation sweeps, and evaluation runs can, so they become jobs.
How it works on E31 Network
In the design, a submitted job that cannot start immediately goes into a queue until compute is free. The meter does not run while the job is queued; a team would pay for the hours compute is held and running, not for the hours spent waiting. When capacity opens, the compute is held for the job, the meter starts, and the job runs.
The request a job declares includes when it must be finished. That deadline is what tells the network how long a job can afford to wait. "I need compute tonight to retrain my model" describes a job that can sit in a queue for the afternoon. A job that must start right now is not a network job.
The program has been open that queue scheduling is not solved. Mixed job sizes are the hard case: a job that needs eight GPUs for four hours beside a job that needs a few minutes, and a fair way to order them. Exactly what a job must declare to be scheduled well is still being worked out, and the design partner program exists partly to find out. The design partners page describes what the program is looking for; intake is not yet open.
Related terms
Questions this raises
- Does a queued job cost anything?
- No. As designed, the meter starts when compute is held for the job and stops when the job finishes, and time spent in the queue falls outside that window. A team would pay for rent and run, not for the wait.
- How does the network decide which queued job runs next?
- This is not settled. The program lists fair scheduling of mixed job sizes among the things it has not solved, and exactly what a job must declare to be scheduled well is still being worked out. No ordering rule is published and none should be assumed.
- What if my job cannot afford to wait?
- Then it is not a network job. The design is explicit that work which must answer now, including control loops, live perception, and interactive tools, stays on dedicated local infrastructure or the team's own systems. Work that can run tonight can run here.
KEEP READING