P4: test the admission gate directly — sealed prediction 1 cannot be scored by sweeping slots (memory 1%, CPU 66-70% at 256 slots)

Aperta
  • Qualcosa non va?
#6 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, shell, typescript
Ambito
infrastructure, performance, testing

Direzione di ricerca

Read deploy/microvm/predictions.json §7.4 and remote-worker/internal/vmpool/config.go to understand the sealed criterion and admission gate; do not edit the pinned predictions file. Decide whether to test a deliberately undersized budget or find the host’s real ceiling, then inspect analyzeLadder in experiments/src/microvm-density.ts and its existing tests. Done means a bounded experiment produces a real gate refusal that the existing scorer can evaluate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Sealed prediction 1 ("Replenishment binds on process/memory count before CPU") is currently INCONCLUSIVE — its scorer needs a threshold crossing on memory or process count, and the metal run never produced one: hostCpuFraction stayed ~0.001 flat and Σ PSS never exceeded 0.41 GB, even at 128 resident microVMs (c=64, the top of the tested ladder). What was observed (CPU demonstrably never bound, knee is replenishment-bound) is consistent with the prediction's direction but is explicitly not a scored result per deploy/microvm/predictions.json §7.4's falsification criterion.

Why this matters (and why it's ranked last)

  • This is a completeness item, not a throughput/latency blocker: nothing measured so far suggests memory or process count binds before replenishment does, and the stated goal (throughput-optimized sandbox service) doesn't obviously need this scored to make near-term engineering decisions. It matters for long-horizon capacity planning at extreme density, and for closing out the sealed prediction set honestly (2 supported / 0 falsified / 2 inconclusive / 1 not evaluable — this is one of the two inconclusive ones).
  • On a 754 GiB, 72-cpu host, reaching an actual memory/process ceiling at the current ~3 MB PSS/VM unit cost would require a very large sweep (extrapolated back-of-envelope: on the order of 10^5 resident VMs by memory alone) — this is a long-running, resource-intensive experiment, which is the other reason it's ranked last.

What's already known / where to look

  • deploy/microvm/predictions.json — prediction 1's exact wording and falsification criterion ("falsifiedBy": "CPU saturating at or before the memory gate first refuses"). Do not edit this file — it's SHA-256 pinned and enforced by pnpm -C experiments exec vitest run microvm-predictions; it was sealed before the first rung specifically so predictions can't be adjusted to fit results.
  • Scoring logic: analyzeLadder in experiments/src/microvm-density.ts (detectKnee internally) — it scores structurally from a RungSample ladder's own fields (hostCpuFraction, pssBytes, processCount, etc.), so a new sweep just needs to produce records with a real crossing in one of those fields for the existing scorer to pick it up; no scorer changes should be needed.
  • Admission control: remote-worker/internal/vmpool/config.go's MaxCommittedBytes/MemoryReserveBytes gate — this is the actual thing that would refuse admission before a real OOM, and it's configured, not derived from the host's physical RAM (flagged elsewhere as a value that can be "configured inert" if sized wrong for the host). Scoring this prediction meaningfully requires either raising this budget toward the host's real ceiling and sweeping until something gives, or deliberately sizing it low enough to force a crossing on purpose (a different, and arguably less interesting, experiment).

Open questions for the spec

  1. Is the goal to find where this host would actually run out (raise MaxCommittedBytes toward the host's real ceiling and sweep c/D until something gives), or to test the admission-control gate itself (deliberately undersize the budget and confirm it refuses cleanly rather than free-running into an OOM)? These are different experiments with the same prediction as a side effect.
  2. Given the scale involved (potentially tens of thousands of resident VMs to find a real ceiling), is there a cheaper proxy — e.g., artificially inflating VMOverheadBytes or GuestRAMBytes to force a crossing at a much smaller VM count, trading realism for a tractable sweep size?
  3. Does pid_max (4194304, per the E10 rung records' limits field) or another kernel limit bind before memory does at any tractable scale, and is that itself worth knowing even if it's not what the prediction asks about?

Suggested scope for a first cut

A design decision before any run: pick the "test the gate" framing (open question 1) as the tractable first cut, since it's a bounded experiment (deliberately undersized budget, confirm clean refusal) rather than an open-ended search for a real-hardware ceiling.

Part of rossoctl/moca-experiments#3 (P4 epic: next experiments after the metal STOP).

Lingua principale
Shell
Stelle
0
Fork
1
Merge medio
6h 16m
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rossoctl/moca-experiments

Tutte le issue di rossoctl/moca-experiments

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.