cc5631a2f3
The prime suspect from the previous iteration was that the phase scheduler
simply is not running, which would have made every arrival result meaningless.
It is refuted.
timer_probe.py takes three equally-spaced snapshots of the 32 MB game heap with
no pilot -- exactly the condition where nothing had been observed to change --
and keeps words whose two successive deltas are both positive and agree within
12 %, so linear rather than merely noisy. 286 words qualify, with a large
cluster advancing in lockstep at 16.5 per second.
That rate is not a coincidence: the existing performance notes put Canary
playback on this box at roughly 14-19 fps, and the dominant counter sits inside
that band, so these read as per-frame counters.
Which gives a mundane explanation for six arrival-free runs. If the scheduler is
frame-driven and the title targets 30 Hz, game time advances at about 55 % of
wall-clock here, so the 168, 190 and 240 second runs covered roughly 92, 105 and
132 seconds of game time. Route_S02 schedules phase-1 arrivals at 90, 120, 170,
210 and 240, so the longest run passed the first two and came nowhere near the
last three. No model has to be wrong for the observations to be empty.
Kept at 🟡, not promoted: two links are assumed rather than measured -- that
these counters are frame counters, and that the game's tick is 30 Hz. The values
also do not fit a naive frame count, since the cluster read 14193 about 255 s
after emulator start, which matches neither 16.5 nor 30 per second, so their
origin is genuinely unknown and no counter is claimed to be the mission clock.
Next is one long run, ~350 s of probe, watching for a 0 -> n transition near
t = 163 s and 218 s wall, where the t = 90 and t = 120 route entries land at 55 %
speed. If 350 s still yields nothing, the frame-rate explanation is itself
refuted and the event-gated model returns as the front-runner. The ~210 s title
movie at boot is the binding constraint on how much game time one turn can
observe.
3.7 KiB
The mission clock is running — the runs were too short in game time
Status: 🔴 "the phase clock is stopped" is refuted; ✅ something advances linearly at ~16.5–17 /s; 🟡 the leading explanation for six arrival-free runs is now that they covered far less game time than wall-clock time; ❔ the counters' exact identity is not established.
🔴 Refuted: the clock is not stopped
mission-arrival-watch.md named this the prime suspect — every "no arrival" result was equally consistent with a scheduler that simply was not running, and nothing had checked.
tools/re-capture/timer_probe.py takes three equally-spaced snapshots of the
game heap (0xBC000000–0xBE000000, 32 MB) with no pilot, i.e. in exactly the
condition where nothing was observed to change, and looks for words whose two
successive deltas are both positive and agree within 12 % — linear, not merely
noisy.
actual gaps: 20.1s, 20.5s region 32.0 MB
linearly-increasing words: 286
rate histogram (/s): [(17, 111), (27, 27), (44, 19), (1, 10), (47, 10), ...]
va 0xbc4428a8 14193 -> 14519 -> 14863 16.5/s
va 0xbc65c948 14195 -> 14521 -> 14865 16.5/s
va 0xbc668648 14193 -> 14519 -> 14863 16.5/s (and many more identical)
286 counters advance steadily, a large cluster of them in lockstep at 16.5 /s. The guest is running. The stopped-clock explanation is dead.
🟡 What this probably means: the runs were far too short
16.5 /s is the emulator's frame rate, not a coincidence. The existing performance work records Canary playback on this box at roughly 14–19 fps, and the dominant counter rate sits squarely inside that band. These read as per-frame counters.
If the mission's scheduler is frame-driven and the title targets 30 fps, then game time advances at about 55 % of wall-clock here. Every run so far:
| run window (wall) | approximate game time |
|---|---|
| 168 s | ~92 s |
| 190 s | ~105 s |
| 240 s | ~132 s |
Route_S02.tbl schedules phase-1 arrivals at t = 90, 120, 170, 210, 240. So the
longest run reached roughly t = 132 of game time — past the first two
scheduled arrivals but nowhere near the last three, and the shorter runs barely
reached the first. That is a mundane and sufficient explanation for a string of
empty results, and it does not require the event-gated model to be wrong or the
timetable to be in frames.
It is 🟡 rather than ✅ because two links in it are assumed, not measured: that these counters are frame counters, and that the game's own tick is 30 Hz.
❔ What the counters are is not established
The value does not fit a naive frame count. The dominant cluster read 14193 at the first snapshot, roughly 255 s of wall-clock after emulator start — 14193 frames at 16.5 /s would be ~860 s, and at 30 /s ~473 s. Neither matches, so these are not simply "frames since boot". They advance in lockstep and at frame rate, but their origin is unknown and no claim is made about which one, if any, is the mission clock.
Next: one long run
The decisive test is now cheap in design and expensive only in wall-clock: run
the arrival watch for the longest window the turn allows (~350 s of probe after a
~210 s boot) and check for 0 → n around t ≈ 163 s and 218 s wall, which is
where the t = 90 and t = 120 route entries land at 55 % speed. If arrivals appear
there, the timetable is in game-seconds and the clock model is confirmed. If 350 s
still yields nothing, the frame-rate explanation is itself refuted and the
event-gated model returns as the front-runner.
The boot's ~210 s title movie is the binding constraint on how much game time a single turn can observe, and is worth attacking separately if this becomes the limiting factor.