Files
LithosAnanake/logs/20260912-195858/amd64/host-sample-amd64-20260912-195858.csv
T
Robert Allan JamesandClaude Sonnet 5 c8ba8832c4
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
Fix N-RUNS/START-REP hardcoded constants; N-REPS increase blocked on reservoir cost, not a bug (FABRIC-3.md §XXIII)
Two real bugs found and fixed while attempting to raise N-REPS from
3 (both harmless only by coincidence at N-REPS=3, since 3 happened
to equal the hardcoded/literal values):

- N-RUNS was `27 CONSTANT`, not derived -- now `N-ID N-REPS *
  CONSTANT N-RUNS`.
- START-REP's run_id decode used a literal `3 *` where it meant
  `N-REPS *` (confirmed against EXEC-STD79-DOE, the serialized
  baseline, which correctly uses N-REPS for the same decode).

Re-verified at N-REPS=3 (amd64): byte-identical to the already-
verified baseline -- 193s, 0 faults, 99/99 tokens every identity,
K conserved on all 656 rows.

Raising N-REPS to 6 was then tested and found to cause real, silent
data loss at full 8-identity scale (rajames 0/198, 00 66/198, 01/02
99/198, 03-06 fully complete) -- same failure class as §XXI defect 2,
just past the budget again since doubling N-REPS roughly doubles
total MSG-SEND volume (24->48).

Measured the reservoir's replenishment directly rather than assume
from source: 40 sends drained it from 21735 to 1; 300s of pure idle
time (zero further sends) brought it back to 2049 -- real, but only
~6.8 units/s, meaning a full refill would take on the order of 53
minutes against a campaign's few-hundred-second runtime. Raising
N-REPS further needs a cheaper per-send cost or an explicit top-up,
not reliance on ambient decay.

Reverted N-REPS to 3 (fixes kept, they're correctness fixes
independent of the value) rather than commit a silently-lossy result.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
2026-09-12 20:03:21 -04:00

1.6 KiB

1epoch_selapsed_sqemu_utime_jiffiesmem_used_kbmem_available_kbswap_used_kb
217892575381024337129705968582664
317892575436024946689645012582664
4178925754811024601969679484582664
5178925755316024599769679704582664
6178925755821025142129625468582664
7178925756326025285569611124582664
8178925756831025476529592028582664
9178925757437025427329596948582664
10178925757942025164249623256582664
11178925758447025134369626244582664
12178925758952025221849617496582664
13178925759457025329569606724582664
14178925759962025265129613168582664
15178925760467025658449573836582664
16178925760972025267209612960582664
17178925761477025117489627932582664
18178925761982025229089616772582664
19178925762487025205569619124582664
20178925762992025207369618944582664
21178925763497025392369600444582664
221789257639102025432809596400582664
231789257644107025405049599176582664
241789257649112025635089576172582664
251789257654117025382049601476582664
261789257659122025076409632040582664
271789257664127025298169609864582664
281789257669132025381489601532582664
291789257674137025338569605824582664
301789257679142025260489613632582664
311789257684147025358809603800582664
321789257689152025386729601008582664
331789257694157026059209533760582664
341789257699162025843769555304582664
351789257704167025870609552620582664
361789257709172025640369575644582664
371789257714177025914129548268582664
381789257719182025479649591716582664
391789257725188025581089581572582664
401789257730193025600169579664582664
411789257735198023375249802156582664