eoc-meter: a GPU rise the oracle saw is not one the probe must have seen #250
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/eoc-meter-gpu-freshness"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
the_production_probe_hands_the_rule_what_the_oracle_readsfailed once on an otherwise green tree — the only failure of that job across 309 commits:The assertion behind it does not hold. The oracle's two reads bracket the probe's samples, so a rise it saw can fall entirely outside the probe's own window. GPU energy is activity-driven, not a clock — it rises only while the GPU works — so on a shared host another process's short burst lands between the oracle's first read and the probe's first sample as readily as inside it. The observed delta is about one tick's worth. One value is therefore no evidence of a sampler that is not sampling.
The same block already reasons this way one branch over: a rail that held across the bracket is reported with
freshness is NOT asserted on it. Andsandbox-meter's equivalent prints its GPU-hold case rather than asserting it. This applies that reasoning to the case where the rail moved — the count of distinct values is reported either way, and nothing is asserted from it.Every other assertion is untouched, including the one that each handed sample lies within the oracle's bracket.
What this gives up
A sampler that cached one reading and handed it back repeatedly would no longer be caught here. What covers a rail that does not advance is the liveness machinery —
the_liveness_probe_never_reports_a_frozen_rail_as_live,the_ioreport_meter_is_never_available_on_a_frozen_cpu_rail. Restoring a sound version of this particular check means driving GPU work inside the probe's own window so a rise is guaranteed to be there to see; that is a larger change than this one.Verified on the IOReport host
17 of 17
macos_ioreporttests and all 80 eoc-meter lib tests pass. That run took the held branch, so it exercises the paths around this change rather than the rare case itself — which by construction cannot be forced, since under deliberate GPU load the probe sees the movement too.🤖 Generated with Claude Code
`the_production_probe_hands_the_rule_what_the_oracle_reads` failed once on an otherwise green tree -- the only failure of that job across 309 commits: ("GPU Energy", 0) moved 1508467856154491 -> 1508467860032551 across the oracle's reads, but every one of the 20 samples the production probe took read [1508467856154491] The assertion behind it does not hold. The oracle's two reads *bracket* the probe's samples, so a rise it saw can fall entirely outside the probe's own window. GPU energy is activity-driven, not a clock: it rises only while the GPU works, so on a shared host another process's short burst lands between the oracle's first read and the probe's first sample as readily as inside it. The observed delta is about one tick's worth. One value is therefore no evidence of a sampler that is not sampling. The same block already reasons this way one branch over -- a rail that held across the bracket is reported with "freshness is NOT asserted on it" -- and sandbox-meter's equivalent prints its GPU-hold case rather than asserting it. This applies that reasoning to the case where the rail moved: the count of distinct values is reported either way, and nothing is asserted from it. Every other assertion is untouched, including the one that each handed sample lies within the oracle's bracket. What this gives up: a sampler that cached one reading and handed it back would no longer be caught here. The liveness tests are what cover a rail that does not advance (`the_liveness_probe_never_reports_a_frozen_rail_as_live`, `the_ioreport_meter_is_never_available_on_a_frozen_cpu_rail`). Restoring a sound version of this check means driving GPU work inside the probe's own window, so a rise is guaranteed to be there to see; that is a larger change than this one. Verified on the IOReport host: 17 of 17 `macos_ioreport` tests and all 80 eoc-meter lib tests pass. That run took the held branch, so it exercises the paths around this change rather than the rare case itself, which by construction cannot be forced. Co-Authored-By: Claude Opus 5 <[email protected]>