At most 44.36 per cent idle

Throughput per epoch and stage is recomputed from register.json in the fixed snapshot of 2026-09-05T09:26:42Z; the published medians come from statistik.json in the same snapshot; the window ends at the pulse timestamp of 2026-09-05T10:35:54Z. The load proxy, the additional measurement load and the core-equivalent plan are taken from a project delivery that draws on records outside the eight public files and cannot be recomputed from them; they are marked as such where they appear. No prices, vendors or purchase options are part of this entry.

Over sixty hours the machine was measuring something for at least 55.64 % of the time. The rest is an upper bound on idleness, not a measurement of it — and the plan that clears the backlog and sustains supply is put at 26 of the 60 cores available, in a scenario band of 8 to 68 that carries no probability.

Between midnight on 3 September in the operator’s local time, two hours ahead of UTC, and 10:35:54 UTC on 5 September — a window of 218,154 seconds, a little over sixty hours — the measuring machine was occupied with measurement for at least 55.64 % of the time.

That leaves 44.36 %. That figure is an upper bound on idle time, not a measurement of it, and the distinction governs everything below.

Why it is a ceiling, not a reading

There is no continuous CPU telemetry behind that figure. It is assembled: the intervals of completed register runs, taken as start time plus recorded duration and so including the work between stages, plus documented measurement work that sits outside those intervals — 8,833 seconds of baseline probes and a progress run — plus one observed interval from the pulse that carries no terminal verdict. The interval already running when the window opened is cut off at the boundary rather than counted whole.

Two things have to hold for that sum to be a floor, and neither can be checked from the public files. The pieces must not overlap, or occupancy would be counted twice; the project record states that they do not. And the pulse interval is counted as occupied even though no verdict closed it, on the grounds that the machine was observed measuring during it. Both rest on records outside the eight published files.

Granting those, 55.64 % is a floor on occupancy assembled from things known to have happened, and 44.36 % is therefore a ceiling on idleness. Building, maintenance, corrections and calibration can occupy the machine without appearing in any of those intervals. The true idle share is somewhere at or below 44.36 %, and the export does not say where.

Counting only the sequential tests, the proxy is 51.59 %. The difference between the two proxies, taken over the window, comes to almost exactly the 8,833 seconds of documented additional work — which is what that gap should be, and it is the work no register entry accounts for.

Three throughput figures, three definitions

The register supports more than one answer to “how fast does this machine play games”, and the answers differ enough to matter.

The short stage agrees with itself: 137.87 against 138.3. The long stage does not: 27.26 against 53.7, near enough to a factor of two.

Neither number is wrong. They are different statistics over different populations. The field durchsatz_mischwert holds a median of the ten most recent time-occupied stages of that kind, and for the long stage that window straddles the change in measuring conditions — six measurements from T-0040 to T-0052 between 53.7 and 54.7, four from T-0064 to T-0067 between 27.1 and 27.4. A median of six older values and four newer ones lands among the older ones, so the published figure still shows the state before the change, and will keep showing it until enough new long stages accumulate to move it.

A third aggregation gives a third answer: pooling every long stage in the register, regardless of epoch, gives 30.71 games per minute. It answers a third question — what the long stage has averaged across the whole record — and is no better than the other two for the questions they answer.

The one thing none of this establishes is why long-stage throughput is about half what it was. The register marks an epoch change for measuring conditions at T-0062, and the later figures fall on the other side of it; what the label covers, the export does not say, and neither the order in time nor this entry supplies a cause.

What the plan actually needs

The project’s demand estimate is expressed in physical core-equivalents — a load quantity, not a machine configuration and not a vendor’s virtual CPU.

Clearing the existing backlog is put at 12 core-equivalents, in a band from 5 to 28. Sustaining the expected supply of new candidates is put at 14, band 4 to 41. Doing both is put at 26, band 8 to 68. The machine has 60 physical measurement cores.

The combined band is not the sum of the other two — 5 and 4 make 9, not 8; 28 and 41 make 69, not 68 — because it comes from varying the same assumptions together rather than from adding two separately varied results.

Those bands need reading carefully. They are not confidence intervals and carry no probability. They are what the estimate produces when the plan assumptions are varied across their ranges — how many candidates are waiting, how many arrive per week, how many core-hours each consumes. The calculation also assumes that 80 % of wall-clock time is usable — an operating target rather than an observed figure — and that throughput stays as it is. The figures it holds fixed are the epoch-3 ones: 137.87 for the short stage and 27.26 for the long, the lowest of the three long-stage answers above. That choice matters. Had the published median of 53.7 gone in instead, the long-stage part of the estimate would have come out at close to half — and the total demand per candidate about a quarter lower. And with the cause of the drop unknown, holding throughput fixed is an assumption rather than a projection.

The reading, marked as one

Taken together the central case fits inside what exists: 26 needed against 60 available, with the machine occupied for at least 55.64 % of a sixty-hour window. On that reading the scarce thing is not cores. It is candidates to test and automation continuous enough to keep the queue fed.

That is an operating interpretation, and it is worth being explicit that timestamps alone do not prove it. It is also worth noting that the upper end of the combined band — 68 — exceeds the 60 cores present, so the same estimate that says there is room also says there is a scenario in which there is not.

What this does not say

It does not say the machine was idle 44.36 % of the time. That figure is the largest idleness consistent with the intervals that are documented, and unrecorded work would reduce it.

It does not say 53.7 games per minute is wrong. It is the median the contract specifies, computed as specified. It is not a throughput figure for epoch 3, and using it as one would overstate what the long stage currently achieves by about a factor of two.

It does not say 60 cores are enough. The central scenario fits; the upper scenario does not, and neither is a measurement.

And it does not say anything about what hardware to buy. No prices, no vendors and no configurations appear in the delivery this entry draws on, and none appear here.