Paired scaled-cache board trial: measured, keep disabled

run-board.py performs one cache-off arm followed by one cache-on arm against the same /nix/store/hxilq8jdlb0b8mj8jzmvhwsw9mwnr69y-k230-card-shell package. It preserves the normal system, Sway configuration, two fixture clients, Pixman auto policy, 13 injected acceptance cases, and each workload’s 24 independent drags. It uses the unchanged declared budget parser. Each arm has its own protected runtime, 540-second compositor limit, recovery timer, raw captures, public text reports, budget, session manifest, and restoration record. An acceptance failure is retained and the next arm still runs after normal shell and seatd restoration. A setup, collection, or restoration error stops the pair while retaining its partial files.

The runner was reviewed and then executed on the board; results follow below. No performance improvement is claimed. Injected input and native captures do not establish real-finger feel or optical latency. The result remains a measurement of task 4.2, not automatic acceptance; both budget gates and every interaction case must be reviewed.

On the reserved normal board, stage this runner beside the published card-shell-board-session.py, card-shell-acceptance.py, and card-shell-benchmark.py. Compare all four SHA-256 values against the reviewed source files before running. Use a fresh revision-specific output directory; the runner refuses to overwrite a prior attempt. An outer systemd deadline of at least 1,320 seconds covers both 540-second arm limits and restoration.

python3 /var/lib/k230/card-scaled-cache-tools-REVISION/run-board.py \
  --board --revision FULL_PUBLISHED_REVISION \
  --output /var/lib/k230/card-scaled-cache-REVISION

The operator must separately verify normal system identity and service, storage, Wi-Fi, and HTTPS restoration after the paired run. Keep raw/ captures and process-private.log protected on the board; review public exports before committing evidence. A failed attempt stays available in its own output directory. Task 4.2 remains open until physical evidence is collected, audited, and committed.

Physical paired result

Published producer revision ec838d9c38ffdecca3e45d72d58852b66f7c5ebc ran the same hxilq8… package with cache off, then on, on 2026-09-24 UTC: 00:30:09–00:31:54 and 00:31:54–00:33:40. Both arms observed all 13 injected interaction checks. Both still fail the declared CPU and tracking budgets. The benchmark workload, renderer, native 568×1232 RGB565 output, source fixture, normal kernel and accepted limits were unchanged. This is one ordered pair; it does not quantify run-to-run variation or every application’s behavior.

CPU limits remain 16.667 ms p95 / 33.334 ms maximum; the tracking p95 limit is 33.334 ms. The enabled mode increased p95 update CPU by about 11.4% with one card and 5.3% with two in this pair. It did not improve tracking cadence. Input-to-submit/present, release recovery and incremental memory passed in both modes. The enabled mode produced more submitted frames, so comparison is of the same input workload rather than a one-to-one frame pairing.

Cache use was observed: 10,132 cumulative sync hits, 2,216 misses and 10,506 fallbacks, with at most 776,240 cached pixel bytes and zero retained bytes in the final recorded cache row. These counters identify sync decisions, not submitted pixel samples or saved CPU. The enabled incremental session-memory peaks were 843,776 and 790,528 bytes, below the 64 MiB limit. The off mode emitted no cache diagnostic rows. Session manifests independently preserve the requested off/on policy. No instrumentation or accepted cost boundary was moved.

Decision: keep this cache off in the normal and experimental defaults. This pair does not establish a useful optimization for the required animated live-card workload. A targeted static-content case could behave differently, but it would not replace the live-card acceptance workload. The initial one-card input CPU spike remains a separate profiling target. Task 4.2 stays open, and this experiment does not satisfy image or real-finger acceptance.

board/comparison.json contains the condensed result. Each arm retains its acceptance, manifests, complete normalized telemetry, independently reproduced budget, repaint profile, and post-restoration session export. The coordinator verified all four producer hashes against the published revision and reproduced the budget reports exactly except for their generation timestamp. The profiles correlate all 662 submitted frames; neither frame-count nor cache-hit count is a claim of better responsiveness.

normal-restoration.json and its sanitized serial transcript independently confirm the same installed system, shell and seatd, Wi-Fi association and HTTPS, protected credential permissions, storage capacity and protected boot hashes. The boot ID is unchanged; this experiment did not reboot or flash. No physical finger or optical latency proof was obtained.

Native capture review

Eight hash-matched fixture captures are committed under each arm’s captures/: two visible cards, off and on, held drag, off and on, private state, off and on, and close timeout, off and on. The coordinator reviewed all eight: both synthetic parent/child images remain visible in the deck and held drag; private cards show no source pixels/title; the refused app remains with timeout feedback and recovery controls. These are native captures during injected input. The clients animate independently, so the off/on images are not frame-synchronized pixel-equivalence tests. The fixture’s visible buttons and unfinished visual style are the existing test shell, not the newer gesture-first design proposal or an acceptance of its UX.