403a7639e11def4e82e851b40776b455baad2bd7
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Robert Allan JamesandClaude Sonnet 5
|
403a7639e1 |
Bracket std79 DoE trial loop with HB-ON/HB-OFF, capture real heartbeat CSVs
Every prior std79-doe.fth run's automatically-extracted CSV (scripts/extract_doe.sh) was silently empty -- g_doe_log_enabled (doe_log.c) defaults off, and nothing in the campaign ever called HB-ON. EXEC-STD79-DOE now calls HB-ON right before its trial loop and HB-OFF right after, so the per-heartbeat-tick physics/timing CSV (18 columns: tick_number, hot_word_count, avg_word_heat_q48, apic_ticks, per-VM heat_q48, etc.) finally covers the run's own window on all three architectures. Found and fixed two bugs along the way, one in a comment and one in the ad hoc QEMU orchestration script used to drive these runs (not part of this repo): - std79-doe.fth's own explanatory comment accidentally spelled out the literal "[HADES][DOE ]" tag string doe_log.c prefixes each row with -- the FORTH REPL's compile-time echo of that comment then matched scripts/extract_doe.sh's own extraction grep, corrupting the first extracted CSV row with comment text instead of real telemetry. Fixed by never spelling out the literal substring. - The harness script's completion-detection watched for "STD79-DOE: complete" anywhere in the log since before the whole capsule was fed, which matches the colon definition's own compile-time echo of that same string literal, not just the real end-of-run print. Without HB-ON the entire 27-trial run finished in a few seconds -- faster than one poll interval -- so the false match and the real one always landed in the same window and this never surfaced. HB-ON's added per-tick console I/O slowed real execution enough to expose it: the script sent BYE the moment compilation finished, truncating every trial after whatever point compilation had reached (aarch64 lost 9 of 27 trials this way on the first attempt). Fixed by feeding definitions and invocation as two genuinely separate connections, with the completion-watch window opened only after compilation is confirmed landed. Verified 27/27 trials correct on every architecture via the campcampaign's most distinctive result markers (both M*/M/MOD 18-19 digit values and the 2147483648 2/ result, all exactly 27 occurrences, zero faults) rather than exact substring reconstruction: HB-ON's async per-tick CSV printer and the trial loop's own console output share the same serial line with no locking, so CSV rows can splice mid-token into trial output on the wire (confirmed live -- cosmetic only, the underlying FORTH execution and values are unaffected). results-20260912-with-heartbeat-csv/ holds both the raw logs and their paired heartbeat CSVs; the earlier truncated runs' logs are kept too (never delete logs) as the record of how this was found. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo |
||
|
Robert Allan JamesandClaude Sonnet 5
|
8394e375d1 |
Reconfirm std79 DoE clean, 81/81, no code changes since §XVII (e51a8d2)
Plain reconfirmation rerun the day after both Stadium fixes landed
(O(ncells) scan fix + donor-floor fix). Same seed, single continuous boot
per architecture, all 9 identities simultaneously live throughout.
81/81 trials correct, 0 mismatches, shuffle sequence md5-identical to
every prior run since
|
||
|
Robert Allan JamesandClaude Sonnet 5
|
e51a8d229e |
Fix stadium_grant_quota() donor floor; rerun std79 DoE clean, 81/81 (FABRIC-3.md §XVII)
capsule_birth.c hardcoded every new VM's initial Stadium quota grant to split from Hera specifically. Since a grant always halves whatever the donor currently has, Hera's own free list converges toward empty after a bounded number of grants — independent of whether the Stadium as a whole still had spare capacity, since VMs she'd granted to earlier typically still held nearly all of their own share untouched. Past that point every subsequent VM birth's Stadium grant would be silently refused (soft-failed, non-fatal by existing design), even with plenty of capacity sitting idle elsewhere. Fixed by adding an O(1)-maintained free_count to StadiumVMQuota (incremented in stadium_evict(), decremented at both of stadium_admit()'s free-list-pop sites, set/adjusted in stadium_grant_quota()'s own split — this also let grant_quota drop its old O(free-list length) counting walk in favor of an O(1) read) and stadium_best_donor(), an O(live VM count) scan over quota slots returning whichever in-use VM currently has the most free cells. capsule_birth.c's birth path now splits from that VM instead of unconditionally vm_uuid_hera(). Verified with another full rerun of the 3x9x3 std79 DoE campaign from scratch — same discipline as the prior Stadium fix (any defect repair reruns the whole DoE from the top) — one continuous boot per architecture, all 9 identities simultaneously live throughout. 81/81 trials correct, 0 mismatches, DOE-RUN header sequence md5-identical to every prior run. aarch64 ~280s total (vs ~290s for the O(ncells)-scan fix alone — confirms no regression). Both known Stadium defects are now closed together on one clean campaign rerun. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo |
||
|
Robert Allan JamesandClaude Sonnet 5
|
9eff122090 |
Fix aarch64 Stadium/COOL O(ncells) scan; rerun std79 DoE clean, 81/81 (FABRIC-3.md §XVI)
Root cause of the 90+ minute aarch64 VM-birth stall found in §XV: stadium_admit()'s eviction-fallback scan iterated the entire stadium_ncells array filtered by owner, not the calling VM's own resident cells as its own doc comment claimed. Combined with stadium_grant_quota() always splitting from Hera's shrinking free list and stadium_word_dispatch() calling stadium_admit() per distinct word a VM's capsule executes, this compounded into a real O(n) blowup — catastrophic specifically on aarch64 because its -m 4096 (vs 1024 on amd64/riscv64) inflates the kmalloc heap kmalloc_init() bisects down to, which inflates stadium_ncells 4x (335,544 vs 83,886 cells, measured from boot logs). Fixed by threading a real per-VM doubly-linked resident-cell list (StadiumVMQuota.resident_head + stadium_resident_next[]/stadium_resident_prev[]) so the fallback scan is bounded by that VM's own resident count, not the global cell array size. Verified with a full rerun of the 3x9x3 std79 DoE campaign from scratch: one continuous boot per architecture, all 9 identities simultaneously live throughout (the 3-boot aarch64/riscv64 batching workaround is no longer needed). 81/81 trials correct, 0 mismatches, DOE-RUN header sequence md5-identical across all three raw logs. Identity 04's attach on aarch64, which stalled 90+ minutes before, now completes in ~34s; full boot-to-DoE-complete in ~290s. Corrects an earlier misreading (carried into §XV, std79-doe.fth's comments, and the project memory note) that described the symptom as a runaway "335,000+ cycles" dispatch counter — those were cell array indices, not an event count. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo |
||
|
Robert Allan JamesandClaude Sonnet 5
|
e2abc56306 |
3(arch) x 9(identity) x 3(rep) randomized full-factorial std79 DoE: 81/81 correct (FABRIC-3.md §XV)
Formal successor to §XII's ad hoc exerciser campaign, requested as a genuine randomized full-factorial design matching this project's own DoE methodology (capsules/doe.4th's Fisher-Yates shuffle), and written entirely in FORTH per explicit request -- not host-orchestrated shell scripting. experiments/std79-doe/std79-doe.fth: builds a 27-cell (9 identity x 3 replicate) run matrix, Fisher-Yates shuffles it with a fixed seed (matching doe.4th's own default), then dispatches each of the 24 exerciser test cases directly into the target identity's own live VM via VM-EXEC -- no console USE redirection, no per-trial host interaction. The zuse case runs as directly-compiled native code (RUN-TEST-NATIVE) rather than VM-EXEC targeting "Hera" herself: VM-EXEC's own vm_state_push/pop only saves rsp/exit_colon/ecw_nesting, not input_buffer/input_pos, so a self-targeting call while this capsule's own vm_interpret call is still mid-line would risk exactly the class of bug the idle-tick reentrancy guards exist for. amd64: all 27 trials ran with all 9 identities simultaneously live in one boot -- clean, zero mismatches. aarch64: hit a real, uninvestigated bug attaching all 9 simultaneously -- the 6th live VM's birth stalled for 90+ minutes at 100%+ CPU with a Stadium COOL-dispatch counter already at 335,000+ cycles, versus tens of thousands at the same checkpoint for earlier identities. Not root-caused here (flagged in FABRIC-3.md for later); worked around by splitting into 3 boots of 3 simultaneously-live identities each, every boot sharing the same seed so the master 27-slot shuffle is identical, filtered per boot by a new ACTIVE-LO/ACTIVE-HI range (EXEC-STD79-DOE's signature: seed lo hi -- ). run_id is always the slot's true position in the master shuffle, so trial order stays comparable across boots -- standard DoE blocking. riscv64: same 3-boot pattern, clean. Grand total: 81/81 trials correct, 0 mismatches, across all three architectures, all nine identities, all three replicates. Also flagged (FABRIC-3.md §XIV, not fixed): attaching several WIREBIND identities near-simultaneously (whether via rapid hotplug or all present from boot) causes the kernel to silently detect only some of them -- confirmed at the host/QMP level that every device was genuinely present. Worked around throughout this campaign by attaching one identity at a time with confirmed waits; real hardware hotplug could hit the same gap, so it's a genuine robustness concern, not just a test-harness inconvenience. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo |