Syplheed-Reborn/docs/re/guest-stalls.md

# The guest stalls, often — and the probe now detects it

Status: ✅ the stall witness works and is validated against independent
telemetry; ✅ it correctly discarded a run that would otherwise have been written
up as evidence; 🔴 stalls are frequent and early enough to threaten the whole
wave line of work; 🟡 the probe's own memory scanning is the leading suspect and
is untested.

## ✅ The witness works

`wave6_probe.py` locates a word that advances at frame rate and prints
`*** GUEST STALLED ***` on any sample where it fails to advance. Its first run:

```
tick witness at 0x11c225810, ~26.7/s
t=  14s craft=300 deployed=41  ARRIVALS=0 losses=0
t=  27s craft=300 deployed=41  ARRIVALS=0 losses=0  *** GUEST STALLED ***
   ... stalled for every remaining sample to t=313s
```

**Validated independently.** The pilot's own telemetry, which the probe never
sees, agrees: **35 distinct speed values across the entire log, and exactly 1 in
the last 400 lines**, against 236 in the first 400 lines of a healthy run. All
the variation is in the first ~50 s. The witness flagged the stall at t = 27 s and
the telemetry puts it in the same place.

## ✅ It earned its keep immediately

Without it, this run reads as *"no arrivals across 313 seconds with 300 craft
resident"* — a clean, quotable, and completely worthless result, since the game
was frozen for 90 % of it. That is exactly the failure the previous iteration
warned about, caught automatically on the first run after the fix.

**Operational rule:** a run whose witness reports a stall is discarded, and every
future write-up must state the witness result. Flat samples are not evidence
unless the witness says the guest was advancing.

## 🔴 Stalls are frequent and early

| run | stall onset | usable window |
|---|---|---|
| keep-out 1400 (previous) | ~255 s | ~255 s |
| keep-out 600 | player died 83 s, frozen after | 83 s |
| this run | **~27 s** | ~27 s |

Two of the last three long runs froze, one of them almost immediately. This is
consistent with the pre-existing freeze recorded elsewhere in the corpus, but its
frequency makes long observation windows unreliable — and long windows are
exactly what the arrival question needs.

## 🟡 Leading suspect: the probe itself

`docker/agent/AGENT.md` warns that a full memory scan "competes with the emulator
for every core under lavapipe", and the probes have grown heavier every
iteration. `wave6_probe` now reads the whole 32 MB entity heap **plus** a 1 KB
`pread` per craft — roughly 300 extra syscalls — every 12 seconds, while the
emulator is trying to render.

That is a plausible cause of the freezes and it has never been tested. It would
also be an uncomfortable one: it would mean the instrument has been degrading the
thing it measures, and that the "no arrival" results were collected under
conditions the game was struggling with.

**Test:** run the hunting pilot for 300 s with **no probe at all**, and read the
outcome only from the pilot's own log — distinct speed values over time. If it
does not stall, the probe is the cause and the sampling has to get much cheaper
(narrow the scan to the roster records' own region, sample less often, or read
only the craft bases already located rather than rescanning).

## Not settled this iteration

The multi-squadron kill-threshold test did not run: the guest froze before the
pilot destroyed anything, so there were zero losses and nothing to threshold.

---

# ✅ Confirmed: the probe was causing the stalls (2026-08-24)

The control needed no new decoding — hunting pilot, `SYLPH_KEEPOUT=1400`, 300 s,
and **no memory probe at all**, judged only from the pilot's own log.

```
last pilot timestamp: 299.4s
  t=  0- 60s  distinct speeds: 211
  t= 60-120s  distinct speeds: 257
  t=120-180s  distinct speeds: 250
  t=180-240s  distinct speeds: 241
  t=240-300s  distinct speeds: 200
```

Healthy through the entire run, with no decline in the final window. Against the
probed runs, which stalled at ~255 s, ~83 s and ~27 s and ended with **1** distinct
speed value across 400 log lines.

**The instrument was degrading the thing it measured.** `AGENT.md` warned about
exactly this — "the full scan competes with the emulator for every core under
lavapipe" — and the probes grew heavier each iteration until `wave6_probe` was
reading the entire 32 MB entity heap plus ~300 extra `pread`s every 12 seconds
while the game rendered.

**Strength of the claim:** the contrast is stark and the mechanism was predicted
in advance, but the control is **n = 1**. It is recorded as confirmed-enough to
act on, not as proven; a second clean control would settle it.

## What this costs

Every "no arrival" result in
[mission-arrival-watch.md](mission-arrival-watch.md) was collected while the
probe was running, i.e. under conditions the game was struggling with, and in
some runs after it had frozen outright. That does not make them wrong — the
elimination test at t = 163 s happened in a window the witness later showed was
live — but it does mean **none of them is as strong as written**, and the whole
arrival question deserves re-running with cheap sampling before any conclusion
is drawn from silence.

## The fix: sample ~4 orders of magnitude less

The full rescan is nearly all waste. After the first scan the craft bases and
their roster links are already known, so a sample only needs the **hull word at
each known base** — 300 × 4 bytes ≈ 1.2 KB, against 32 MB.

`wave7_probe.py` does that: one full enumeration at the start, then cheap hull
polling, with a full rescan only every ~90 s to catch anything genuinely new.
That is 3–4 heavy scans per run instead of 25.

Implemented, **not yet run** — so the claim that it stops the stalling is
untested, and the next run must report the witness before anything else.

---

# ✅ The cheap probe does not stall the guest (2026-08-24)

First run of `wave7_probe.py` — one enumeration, then hull polling, full rescan
every 90 s:

```
TOTAL candidate-up=1 down=19 stalled samples=0
```

**Zero stalled samples across the whole run**, against three consecutive heavy-probe
runs that stalled at ~27, ~83 and ~255 s. The fix works, and the previous
iteration's confirmation is now supported from the other direction as well.

The guest is also visibly healthier: **19 losses against 8** in the heavy-probe
run of comparable length. Starving the emulator was suppressing the very activity
the probe existed to watch.

---

# The single-word witness gives false positives (2026-08-24)

Status: 🔴 the witness as first written is unreliable; ✅ the contradiction that
exposes it is in its own output; ✅ replaced with a majority vote, not yet run.

A run with the cheap probe and a bound pilot produced this:

```
t= 30s deployed=41 up=0 down=1 ... *** GUEST STALLED ***
t= 75s deployed=41 up=0 down=1 ... *** GUEST STALLED ***
t=151s deployed=40 up=0 down=2 ... *** GUEST STALLED ***
TOTAL down=16  stalled samples=13
```

**Thirteen samples flagged as stalled while recording losses in the same
samples.** A frozen guest cannot destroy craft, so those flags are false
positives, and the run was in fact healthy — 16 losses over 290 s.

The cause is the selection rule: it took **the first word** in a 4 MB window
whose rate fell in a plausible band. Plenty of counters advance intermittently —
a buffer index, a per-event tally — and one of those satisfies the test while
saying nothing about whether frames are being rendered.

`timer_probe.py` had already done this correctly and the lesson was not carried
over: it collected **286** linearly-advancing words and looked at the *rate
histogram*, where a dominant cluster sat at ~17 /s.

**Fixed:** `wave7_probe.py` now collects every candidate, keeps the modal-rate
cluster, samples up to 32 of them, and reports a stall only when **fewer than
half** advance. It also says `RUN UNVALIDATED` when no witness is found at all,
because an earlier run printed `stalled samples=0` with `tick witness: NONE` —
a witness that does not exist cannot report zero stalls.

Not yet run, so the majority rule is unverified.

## What this costs

The stall counts quoted for earlier runs came from the pilot-log speed analysis,
not from this witness, so they stand. But any run judged **only** by the
single-word witness is unreliable in both directions, and the "0 stalled samples"
that validated the cheap probe came from a run where the witness may equally have
been a lucky pick. That validation should be repeated with the majority rule.

---

# The majority vote is better, the threshold was wrong — and freezes persist (2026-08-24)

Status: ✅ the multi-witness vote produces a usable graded signal; 🔴 the
"fewer than half" threshold is wrong; 🔴 **freezes still happen with the cheap
probe**, so the earlier "0 stalled samples" validation is superseded.

## The run

```
tick witnesses: 185 candidates, modal rate 93/s, using 31

t= 15s  down=1  *** GUEST STALLED (11/31 witnesses moved) ***
t= 45s  down=1  *** GUEST STALLED (11/31) ***
t= 90s  down=1  *** GUEST STALLED ( 4/31) ***
t=138s  down=1  *** GUEST STALLED ( 8/31) ***
t=168s  down=0  *** GUEST STALLED ( 1/31) ***
t=183s  down=1  *** GUEST STALLED ( 0/31) ***
t=198s … t=289s  down=0   *** GUEST STALLED (0/31) ***  (every sample)
TOTAL down=7  CONFIRMED arrivals=0
```

## ✅ Graded output is the improvement

Unlike the single-word witness, this says *how many* agree, and the number tells
a coherent story: 11 → 9 → 7 → 4 → 1 → **0**, with the drop to zero at t = 183 s
coinciding exactly with the last loss. From t = 183 onward the guest really is
frozen — 0 of 31 counters advance and nothing is destroyed for 106 s.

## 🔴 The threshold was wrong

Flagging a stall at "fewer than half" marked the entire run stalled, including
samples where craft were being destroyed. **11 of 31 advancing is a healthy
guest**, not a stalled one.

The cause is the cluster choice. The modal rate here was **93 /s**, far above the
~16.5 /s frame rate `timer_probe` measured — those are subsystem counters that
tick in bursts, so most are idle in any given 15 s window even while the game
runs. Selecting the modal cluster was convenient rather than principled.

**Fixed:** prefer the cluster whose rate falls in the frame-rate band (8–40 /s),
falling back to modal only if none exists, and flag a stall only when **zero**
witnesses advance — the signal the data actually supports. Not yet run.

## 🔴 Freezes are not eliminated by the cheap probe

This run used the cheap probe and still froze, at t ≈ 183 s. So the previous
iteration's "0 stalled samples" — which came from the unreliable single-word
witness — cannot stand as validation.

What the evidence now supports: the no-probe control ran 300 s clean (n = 1), the
heavy probe froze at 27–255 s, and the cheap probe froze at 183 s (n = 1). Cheap
sampling plausibly helps but **does not remove the freeze**, and with n = 1 on
each arm it is equally possible the freeze is stochastic and the control was
lucky. Recorded as unresolved rather than resolved in the probe's favour.

**Consequence:** the usable window per run is roughly 3 minutes, sometimes less,
whether or not the probe is cheap. Any experiment needing longer than that has to
survive a freeze or be redesigned around one.

---

# Witness attempt 3: the search window was too narrow (2026-08-24)

Status: 🔴 still unreliable; ✅ cause identified; ✅ bind failure separately
diagnosed and fixed.

The frame-rate-band selection ran, and still flags stalls in samples where craft
are being destroyed:

```
tick witnesses: 96 candidates, using 5 at 24/s (frame-rate band)
t= 30s down=1 *** GUEST STALLED (0/5 witnesses moved) ***
t=156s down=1 *** GUEST STALLED (0/5) ***
t=236s down=1 *** GUEST STALLED (0/5) ***
TOTAL down=11  stalled samples=7
```

**Five witnesses is not a vote.** And a counter genuinely running at 24 /s cannot
fail to advance across a 15 s sample — it would gain ~360. So these are bursty
counters again: they moved during the 3 s calibration and then stopped.

The cause is mine: when the witness was bolted into `wave7_probe` the candidate
search was narrowed to a **4 MB** window, while `timer_probe` — which found a
clean 17 /s cluster — searched the **whole 32 MB** region and found 286
candidates. Narrowing was never justified; it was just cheaper to write.

**Fixed:** search the full region once at startup (a one-off cost, not per
sample), and warn explicitly when fewer than 8 witnesses are available so a weak
vote is visible rather than silently trusted. Not yet run.

This is the third attempt at this witness. The pattern in all three failures is
the same — a shortcut in *selecting* the witness, not in the voting logic — and
each was caught only because the flagged samples contradicted the loss events in
the same output. That internal contradiction is the real check and is worth
keeping in any future version.

## ✅ Separately: the bind failure is fixed

Three consecutive bind attempts failed and the session **aborted rather than
flying unattended**, which is the behaviour added last iteration working as
intended. The cause: `entities2 self` finds the player by *motion* between two
samples, so a craft sitting still at mission start is invisible. The session now
holds the throttle for 3 s before each attempt. Verified — the next run bound
immediately and produced 11 losses.

---

# ✅ The witness is validated (2026-08-24, fourth attempt)

```
tick witnesses: 6500 candidates, using 32 at 21/s (frame-rate band)
t= 15s down=0
t= 30s down=1                       <- loss, NOT flagged
t= 45s down=0  *** GUEST STALLED (0/32 witnesses moved) ***
t= 60s … t=211s  down=0  *** GUEST STALLED (0/32) ***   (every sample)
TOTAL down=1  stalled samples=12
```

**Zero contradictions.** The single loss falls in an unflagged sample; every
flagged sample has no losses. That is the internal-consistency check the three
previous versions each failed, and it passes here.

What made the difference was searching the **whole 32 MB region** rather than a
4 MB window — 6500 candidates instead of 5, with a clean cluster at 21 /s
matching the measured frame rate.

## 🔴 But the freeze is now clearly the dominant problem

Onset across runs: **27, 45, 83, 183, 255 s** — median around 83 s. This run
froze at 45 s and produced exactly one loss, so it is useless for the arrival
question even though the instrument finally works.

The usable window is one to four minutes and unpredictable. Fourteen of fifteen
runs have gone into the arrival question and it still has no answer, largely
because of this.

## The probe is still not cheap

Worth being honest about: "cheap probe" was never that cheap, and the witness
made it worse. It still reads 32 MB to enumerate at startup, another 32 MB every
90 s to rescan, and the full-region calibration added **two more 32 MB reads**.
The freeze at 45 s came immediately after that calibration.

Trimmed: calibration now samples **8 spread windows of 512 KB** (4 MB total,
still covering the whole span) rather than reading everything twice, and the
rescan interval is doubled to 180 s. Not yet run.