From 4e46ae0b42b30d9b2dec957fd03e549125c08bc7 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Tue, 25 Aug 2026 15:19:52 +0000 Subject: [PATCH] re: my own probe is now the strongest freeze correlate phase_watch.py runs give a sharper tally than the earlier inducer test, because the only difference between the groups is one tool: pilot alone went clean to 936s and 1064s (2 runs), while pilot + phase_watch froze at ~70s, ~253s and ~126s (3 runs). Same boot path, same pilot, same mission. What phase_watch adds is find_mission(), which does TWO full sweeps of guest memory at startup plus ~130 small reads every 5s. The sweeps are the same shape as the heavy_read.py scans the earlier n=2 experiment implicated. Still correlation, not cause -- 3 vs 2, and the earlier inducer test produced a clean counter-example. But it is the best-supported version of 'the instrument provokes the freeze' so far, and it is my instrument, which makes it actionable. The cheap test is named: find_mission only needs to run once, so re-run the watch with the sweeps replaced by an address from a prior run. Freezes stopping implicates the sweeps; continuing implicates the per-sample reads. Cost so far: three attempts at observing a phase advance, all truncated inside four minutes. --- docs/re/mission-freeze-resume-spin.md | 35 +++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md index b5ff021f..647ed018 100644 --- a/docs/re/mission-freeze-resume-spin.md +++ b/docs/re/mission-freeze-resume-spin.md @@ -1182,3 +1182,38 @@ thread identity or behaviour carries across runs for free. **Net for the distribution experiment:** the healthy half now has two independent samples; the frozen half is **still uncollected**, because run 3 never froze. + +## 🟡 2026-08-25 — my own probe is now the strongest freeze correlate + +The `phase_watch.py` runs give a much sharper tally than the earlier +inducer experiment did, because the difference between the two groups is a +single tool: + +| probe attached | runs | outcome | +|---|---|---| +| pilot only | 2 | **clean to 936 s and 1064 s** | +| pilot + `phase_watch.py` | **3** | **froze at ~70 s, ~253 s, ~126 s** | + +Five runs, same boot path, same pilot, same mission. Every run carrying the +script probe froze inside ~4 minutes; neither run without it froze in ~16. + +**What `phase_watch` does that the pilot does not:** `find_mission()` performs +**two full sweeps of guest memory** at startup — one for the `.ssb` header, one +for every word equal to the code base — and then ~130 small reads every 5 s. The +full sweeps are the obvious suspect, and they are the same *shape* as the +`heavy_read.py` scans that the earlier n=2 experiment implicated. + +⚠️ **Still correlation.** Three-versus-two is suggestive, not causal, and the +earlier inducer test already produced one clean counter-example when the box was +loaded. But it is now the best-supported version of "the instrument provokes the +freeze", and it is *my* instrument, which makes it actionable rather than +academic. + +**The cheap test:** `find_mission` only needs to run once, and its result could +be passed in on later samples — so run the same watch with the sweeps replaced by +a hard-coded address from a prior run. If the freezes stop, the sweeps are the +cause; if they continue, the per-sample reads are. + +**Cost so far:** three attempts to observe a phase advance, all truncated inside +four minutes by a freeze the probe itself may be causing. The arrival transition +at ~143 s was caught only because it happens early.