| Filename | Latest commit message | Latest commit date |
|---|---|---|
811ae206f5
Some checks failed
energy meters on real hardware / sink decode table · per-task energy and the GPU rail on macOS (push) Successful in 2m11s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Has been cancelled
jouleclaw public surface must stay documented / Public-surface audit (jouleclaw-rs) (push) Has been cancelled
energy meters on real hardware / RAPL and NVML on jetson-hub (push) Failing after 8s
energy meters on real hardware / sink decode table · RAPL on jetson-hub (NVML surveyed) (push) Failing after 6s
The liveness rule counts intervals and never looked at how long one lasted. A rail that steps twice a second steps in every interval once sampling slows to that cadence, and a contended host slows it just so. On an M3 Ultra the same rail, burned and sampled by the same code in one quiet process, was Frozen in 17 of 17 probes ticking at 25, 100 or 250 ms and Live in 12 of 12 at 500 or 800 ms. With four test binaries sampling at once, 6 of 20 runs cached Live for the process, on a rail every other crate on that host called Frozen, and in CI the status selected the counter. An IOReport interval now counts only within MAX_INTERVAL_TICKS (3) of the tick the probe asked for. A longer one shows which rails exist, and is otherwise no evidence either way: not its advances, not the interval, not its time. So the 300 ms window is 300 ms of intervals that count, or a burst beside one long interval would fill it. A probe that cannot sample near its cadence ends Frozen and falls back to its estimator: estimated, never over-claimed. Three, from interval streams recorded on real hosts and replayed under each cap. That rail under contention: Live in 57 of 80 streams with no cap, 13 at eight ticks, 9 at five, 2 at four, none at three. A RAPL counter that is live: Live in 10 of 10 on a quiet host, 9 of 10 with a spinning thread for every core, 2 of 10 with twice as many. Only IOReport's rails have the cap. RAPL, NVML and a process's counter publish at least as often as their probes tick, so sampling slowed by contention shows nothing a quiet probe would not. Capping them too made the tests that hold a process's counter to Live fail under load: 5 of 27 runs on an M5 Max with four busy threads a core, four of them on the counter's status. watch takes the tick the probe asks for. counter_run, the vendor counters', has no cap. standards-build's description of the job says so too. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| wai-conformance | ||
| workflows | ||