Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

eoc-meter: say where the sampler-re-reads property is actually pinned #262

Merged
dcharlot merged 1 commit from fix/meter-freshness-note into main 2026-10-16 04:54:30 -04:00
Conversation 0 Commits 1 Files changed 1 +12
dcharlot commented 2026-10-15 01:08:12 -04:00
Owner
Copy link

The GPU-freshness report explains why a rise the oracle saw is not one the probe must have seen, but it does not say what still covers the property that assertion was reaching for. The obvious next reader therefore 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; probe_with_one_die_live_and_one_frozen_is_frozen does the same.

Proven by mutation, not asserted

path:     rail_liveness::tests::probe_with_a_single_batch_jump_is_frozen
baseline: rc=0   passed=1 failed=0     <- it actually ran
mutated:  rc=101 passed=0 failed=1
          "sample 1: the record is not what the rule was handed"

The mutation makes the fake hand a cached first reading at every sample (|i| Some(sample(i)) -> |_i| Some(sample(0))), which is exactly the defect the removed assertion was aimed at. It is caught 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.

🤖 Generated with Claude Code

The GPU-freshness report explains why a rise the oracle saw is not one the probe must have seen, but it does not say what still covers the property that assertion was reaching for. The obvious next reader therefore 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; `probe_with_one_die_live_and_one_frozen_is_frozen` does the same. ### Proven by mutation, not asserted ``` path: rail_liveness::tests::probe_with_a_single_batch_jump_is_frozen baseline: rc=0 passed=1 failed=0 <- it actually ran mutated: rc=101 passed=0 failed=1 "sample 1: the record is not what the rule was handed" ``` The mutation makes the fake hand a cached first reading at every sample (`|i| Some(sample(i))` -> `|_i| Some(sample(0))`), which is exactly the defect the removed assertion was aimed at. It is caught 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. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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
Details
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 20s
Details
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m47s
Details
standards workspaces build + test / macOS energy backends (pull_request) Failing after 2m42s
Details
standards workspaces build + test / eoc-rs (eoc/eoc-rs, -p eoc-meter --features cuda, eoc-rs, linux) (pull_request) Successful in 2m17s
Details
4d745abf6b 
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]>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!262
No description provided.