jouleclaw: bound a GPU energy counter from below, not only above #341

Merged

dcharlot merged 1 commit from fix/gpu-counter-under-reports into main 2026-10-19 21:21:43 -04:00

Conversation 0 Commits 1 Files changed 3 +238 -10

2026-10-19

Transaction Science

jouleclaw: bound a GPU energy counter from below, not only above ...

`GpuPlausibility` judged an NVML cumulative-energy counter against the board's
own telemetry in one direction only. Its three verdicts were `Plausible`,
`CounterOverRate` ("ran faster than the board can draw") and
`BoardTelemetryUnusable`. Nothing caught a counter reading **low**.

That is the wrong direction to guard. By this family's own doctrine (jcp/SPEC
§5): "Under-reporting is the unsafe direction at a ceiling, because it admits
work the budget cannot cover." A counter running fast fails safe — it spends a
budget sooner. A counter reading low is graded `HwShunt` and then spends an
energy ceiling it is not measuring. jouleclaw/SPEC §1.3 already refused a
counter "republished in lumps", but nothing implemented it: such a counter
*advances*, so the sustained-advance liveness probe calls it live while it
accrues a fraction of the energy.

`CounterUnderRate` closes it, bounded by the **same** board telemetry the
ceiling bound already uses, so no threshold is invented:

    floor = (mean_usable_draw - GPU_DRAW_SLACK_MW) / GPU_UNDER_FACTOR

The slack comes off the draw *before* the division, so the floor collapses to
zero at or below 5 W of mean draw: on an idle board a correct counter accrues
almost nothing, and refuting it would be noise rather than a finding. The
factor is deliberately looser than `GPU_DRAW_FACTOR` because the draw readings
are one-second averages, so a bursty load idle between samples really does
integrate to less than its sampled mean. The verdict carries the yardstick it
was judged against, so the judgement can be re-made against a different factor.

It ranks **above** a proven overrun: both refute, but only this one admits work
a budget cannot cover, so where one GPU of a probe over-reports and another
under-reports, the under-report is what an operator must act on. Among two
under-reporting GPUs the ordering is by shortfall, not by rate.

Two things found while doing it, beyond the reported gap:

- **`_ => CounterLiveness::Live` in the verdict mapping** meant a newly added
  verdict would silently become *live* — and "unrecognised verdict is
  admissible" is the unsafe default. That match is now exhaustive, so a future
  arm must be graded deliberately or the crate does not compile.
- **The wiring was untested.** The existing test covered
  `plausible_gpu_counter` and the over-rate path through `GpuWatch::liveness`,
  but a verdict that never reaches `CounterLiveness` changes nothing. Added a
  test driving an under-reporting GPU through the probe, whose discriminating
  half is the *same slow counter beside an idle board* — which must stay live,
  because nothing about the counter changed, only the yardstick.

`mode_for` needed no change: `Implausible` already falls back to the vendor
power integral and grades `ModelBased`, so the fix completes itself once the
verdict exists and maps. SPEC §1.3 now states the bound is two-sided, that it
refutes and never verifies, that an indeterminate is not hardware-graded, and
that it must not fire near idle. Doc comments that described the bound as
one-directional are corrected.

Figures throughout are the jetson-hub RTX 4050's own, as the existing test's
already are.

Co-Authored-By: Claude Opus 5 <[email protected]>

04086d2e38

• View at this point in history

2026-10-19 20:26:38 -04:00