Laundry Queue

What these numbers actually show

The idle-machine result above is a real, assumption-independent check that the code does what the rules say: wait-forever alone produces minutes of a machine sitting idle while someone waited behind an absent front; eject and move-back-one both produce zero. That's not sensitive to how aggressive the lateness assumptions are — it's the direct consequence of those two policies actively resolving a stuck front-of-queue reservation, and wait-forever never doing anything about it.

move-back-one's p90 and max wait times sit far above its own median, while eject's don't — a long tail, not just a higher average. The reason is mechanical: nothing in the rule limits how many times in a row one reservation can be swapped backward. A more realistic lateness assumption would shorten that tail, but wouldn't remove the mechanism that produces it — the rule has no safeguard against a long run of bad luck, independent of how likely that run is.

eject's apparently low "extra wait paid by self" isn't because ejecting is cheap — it's a measurement gap. An ejected reservation is simply gone from this simulation's data the moment it happens, so no further cost is ever counted against it. The real cost (losing your place entirely, rejoining from the back) is exactly what ADR 0005 already argued against in words; this page's numbers don't measure that cost's size, since nothing here follows a reservation past the point it's deleted.

None of this settles, or is being used here to argue, which policy is fairest. That argument is ADR 0005's and README's, made on grounds this simulation can't touch — what cost is acceptable to impose on someone for stepping away, not how many minutes it costs on average.

Limitations of this simulation

• The lateness assumptions are deliberately aggressive (see "Assumptions" above) — this inflates whatever compounds over repeated attempts (move-back-one's tail, most of all) more than it inflates one-shot outcomes.
• It measures efficiency, not fairness. Every metric here is a count or a duration — none of them represent whether something was an acceptable thing to do to someone.
• No fault injection — this is volume and randomness over normal use, not deliberate crashes or network faults (see ADR 0010 for how this compares to the canonical form of this technique).
• Only one seed per policy is ever played back above — the one closest to that policy's own mean swap count — not the full spread of 50.

A direction this surfaced, not a decision to build it

The long-tail finding suggests a real question for a future iteration of this app: should the queue cap how many consecutive times one reservation can be swapped backward before some other mechanism takes over — for example, routing it into the existing cross-machine "earlier machine" offer instead of an indefinite in-place swap? This page doesn't answer that; it's recorded as a possible second-phase direction in plan.md, not a scoped feature.

Full detail behind this reading: ADR 0011.