What a published rate would have to cover

No rate has been published for E31 Network, and none will be until access opens. That is a deliberate choice rather than an oversight. A rate is a promise about what an hour of compute costs, and the program is not yet in a position to make that promise honestly. This article is about what such a rate would have to account for, so that when one is published a reader can judge whether it is reasonable.

The hours the meter counts

The rate would attach to the hours compute is held for a job: from the moment the request is granted and the compute is reserved, through the run, until the output is returned and the compute is released. Those are the rent and run steps in the life of a job. Submission is not metered. Waiting in a queue is not metered. Release is the end of metering, not a step that costs anything.

A published rate therefore has to cover the cost of the compute for exactly those hours, and nothing else. It cannot quietly include the hours a job spent waiting, because the design says those are free. It cannot include a minimum that charges for hours not used, because that would be a monthly commitment wearing an hourly label.

The hours the meter does not count

Compute in the pool is not running a job at every moment. Between one job's release and the next job's rent, it waits. Someone bears the cost of that waiting, and under the network's design it is the pool, not the team. A rate that is honest about this has to recover the cost of idle pool time from the hours that are metered, without pretending the idle time does not exist.

How much idle time the pool carries depends on how well mixed job sizes can be scheduled, and that is one of the problems the program has listed as unsolved. A job that needs eight GPUs for four hours beside a job that needs a few minutes is hard to pack without gaps. Until scheduling is better understood, the idle fraction is unknown, and a rate built on an unknown idle fraction would be a guess.

Moving the data

A job's data has to be staged where the compute is before the job can run, and the output has to come back afterwards. For a large dataset or a season of footage, moving the data is real work, and the program has said plainly that getting large datasets to where the compute is remains an open problem. A rate has to decide whether that cost sits inside the hourly figure or beside it, and the program has not made that decision in public.

Isolation and accounting

Each job runs isolated from other jobs while it runs, and what was held is accounted for afterwards in a form the submitter can read. Both of these cost something to provide. Isolation means compute cannot be shared as tightly as it otherwise might. Accounting means records are kept and returned. A rate that is too low to cover them would eventually have to cut one, and neither is optional in the design.

Why the program would rather wait

Each of the items above is a variable the program does not yet have a settled value for. Publishing a rate now would mean fixing those variables by assumption and then either honoring a figure that turns out to be wrong or withdrawing it. The preview has chosen instead to publish the shape of the arrangement, by the hour for the hours held with the meter stopped at release, and to leave the figure for later.

When a rate is published, a reader should be able to check it against this list: hours held only, no charge for queue time, idle pool time recovered honestly, data movement accounted for, isolation and accounting covered. A rate that meets those tests is one the design can support. A rate that does not is one the program should not have published.

For the current list of open problems, see what we have not solved yet. For how the program decides what it is willing to publish, see how the preview decides what to publish.