Each of the four crates' `nvml_hardware` tests carries its own oracle: the
plausibility rule rewritten from the rule itself, in f64, from `nvidia-smi`
rather than the crate's own sampling, so that `energy-hardware.yml` on
jetson-hub checks the crate against an independent implementation and not
against itself. That only holds while the oracle encodes the rule the crate
implements, and all four still had the old conflation:
if rate_w > 1.5 * c || draws_w.iter().any(|d| *d > 1.5 * c) { return false }
jcp-energy's included — #185 fixed that crate's implementation and left its
oracle behind, so since then the two have disagreed about what a draw reading
past the board's own limit means. On jetson-hub's RTX 4050 the disagreement
is masked: that counter runs persistently at 4-30x the board's draw, so the
implementation reaches `Implausible` by the rate bound and the oracle reaches
it by the broken reading, and they agree on the verdict for different
reasons. It would surface on a board whose counter is sane and whose
telemetry spikes — the implementation would judge on the surviving reading
and say `Live`, the oracle would say `Implausible`, and the test asserts they
agree.
So the oracles now drop a draw reading past the limit, and only that reading,
and answer `Unjudgeable` when nothing usable is left — with a `Verdict`
variant for it and an arm in the mapping each test makes against the crate's
own status. The run's verdict is the most severe of its GPUs', as the crates'
now is, so a definite overrun outranks an indeterminate.
These tests are all `#![cfg(target_os = "linux")]`, two of them also behind
`--features nvml` and one behind `--features cuda`, so none of them compiles
in a default build on this machine; checked for aarch64-unknown-linux-gnu
with each crate's own feature.
Co-Authored-By: Claude Opus 5 <[email protected]>
b739eb26ef