eoc-meter: say where the sampler-re-reads property is actually pinned #262
2026-10-15
eoc-meter: say where the sampler-re-reads property is actually pinned
Some checks failed
energy meters on real hardware / RAPL and NVML on jetson-hub (pull_request) Successful in 44s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 20s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m47s
standards workspaces build + test / macOS energy backends (pull_request) Failing after 2m42s
standards workspaces build + test / eoc-rs (eoc/eoc-rs, -p eoc-meter --features cuda, eoc-rs, linux) (pull_request) Successful in 2m17s
The GPU-freshness report left a comment explaining why a rise the oracle saw is not one the probe must have seen. It did not say what still covers the property that assertion was reaching for, so the obvious next reader restores a hardware assertion and reintroduces the flake. It is covered deterministically, per sample, by the scripted probes: `probe_with_a_single_batch_jump_is_frozen` drives `GPU Energy` to a different value at every sample and asserts each one is exactly what the rule was handed, and `probe_with_one_die_live_and_one_frozen_is_frozen` does the same. A sampler that cached one reading fails those on sample 1, on every host, with no dependence on what the hardware happens to do. So the earlier claim that the report gave up that coverage was wrong: it gave up nothing, and driving GPU work inside the probe's window to restore a hardware assertion is unnecessary. The comment now says so, and says why no sound hardware witness exists on the CI host anyway -- its CPU rails are frozen and its GPU rail is activity-driven. Comment only; no behaviour change. Co-Authored-By: Claude Opus 5 <[email protected]>