jcp-energy: compare two threads' energy within one span, so host load no longer decides the test #179

Merged

dcharlot merged 12 commits from ci/energy-tests-load-independent into main 2026-10-07 21:21:28 -04:00

Conversation 0 Commits 12 Files changed 1 +94 -14

dcharlot commented 2026-10-07 09:33:17 -04:00

Owner

Copy link

jcp-energy's two_threads_burning_meter_more_than_one no longer depends on host load. It failed intermittently on the shared macOS runner, and with it the "macOS energy backends" check.

Cause. The test measured one thread in one span and two threads in a second span, then compared the figures. Energy per CPU-second depends on which cores and clock each span gets, so under load the two-thread span could read lower than the one-thread span (0.59 J against 0.92 J).

Fix (test only). Both threads burn within one span. A per-thread oracle reads each thread's own energy count across its burn. The span's figure must be at least the two counts added together, and more than either one alone. That bound is stronger than the old cross-span comparison.

Evidence.

• 20 of 20 runs passed under one spinner per core.
• It fails when the meter reports only the calling thread.
• The full jcp-energy suite passes.

Scope. This pull request no longer changes any probe's tick. The tick floor in proof-cascade, sandbox-meter, eoc-meter and jouleclaw-energy is handled by the pull request that keeps each tick's wall cap and asserts that the tick spun. jcp-energy's liveness::burn has the same shape and can follow that approach.

🤖 Generated with Claude Code

jcp-energy's `two_threads_burning_meter_more_than_one` no longer depends on host load. It failed intermittently on the shared macOS runner, and with it the "macOS energy backends" check. **Cause.** The test measured one thread in one span and two threads in a second span, then compared the figures. Energy per CPU-second depends on which cores and clock each span gets, so under load the two-thread span could read lower than the one-thread span (0.59 J against 0.92 J). **Fix (test only).** Both threads burn within one span. A per-thread oracle reads each thread's own energy count across its burn. The span's figure must be at least the two counts added together, and more than either one alone. That bound is stronger than the old cross-span comparison. **Evidence.** - 20 of 20 runs passed under one spinner per core. - It fails when the meter reports only the calling thread. - The full jcp-energy suite passes. **Scope.** This pull request no longer changes any probe's tick. The tick floor in proof-cascade, sandbox-meter, eoc-meter and jouleclaw-energy is handled by the pull request that keeps each tick's wall cap and asserts that the tick spun. jcp-energy's `liveness::burn` has the same shape and can follow that approach. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 8 commits 2026-10-07 09:33:17 -04:00

jcp-energy: compare two threads' energy within one span, not across two ... eeaea3234c

two_threads_burning_meter_more_than_one metered one thread's 200 ms of
CPU in one span and two threads' in a second span, then required the
second figure to be larger. The CPU work in each span is fixed by the
threads' own CPU clocks, but its energy is not: it follows the core type
and clock the scheduler gives each span. On the loaded macOS runner one
thread read 0.92 J and two threads 0.59 J, and the check failed though
the meter counted every thread.

Both threads now burn in one span, and a per-thread oracle (the tests'
own proc_pidinfo PROC_PIDTHREADCOUNTS read of each thread's energy
count) reads each one's rise across its burn. The span's figure must be
at least the two rises added up, and more than either one's alone. The
figures compared cover the same work at the same time, so host load
cannot move one against the other. The check is stronger than before:
it bounds the figure by both threads' whole counts, not only by another
span's figure. A meter that reads only the calling thread fails it.

Test-only change; no production code changed.

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

jouleclaw-energy: end the child window on the child's energy, not 300 ms ... 85aab0239c

the_process_counter_meters_this_process_and_nothing_else let a busy
child run for a fixed 300 ms of wall time and required its own counter
to rise 0.2 J. How much CPU a child gets in 300 ms depends on host load:
on the loaded macOS runner it spent 0.12 J and the test failed, though
nothing about the counter under test was wrong.

The window now lasts until the child's own count, read independently,
has risen 0.2 J, and at least 300 ms. A loaded host stretches the window
but always leaves 0.2 J of the child's work in it, twice the 0.1 J
ceiling on what this process may meter meanwhile, so the child-exclusion
check still has the same margin. A child that has not spent 0.2 J in
20 s fails the test: it did not work, or the host is too loaded to
tell.

Test-only change; no production code changed.

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

proof-cascade: the probe tick burns its whole 25 ms of thread CPU ... 2641dead72

The liveness probe's tick burned 25 ms of the probing thread's CPU time
but gave up after 500 ms of wall time. On a loaded host that runs the
thread for under 5% of a core, the cap cut the tick short: on the macOS
runner an interval held 12.4 ms of thread CPU, under the tests' 12.5 ms
floor, and the host_status_calls_*_frozen tests failed. In production
the same cap made the probe's work per interval, and so its verdict,
depend on host load.

Production change: the tick is bounded by thread CPU time only. It ends
once the thread has burned the whole 25 ms, however much wall time that
takes. Against a thread CPU clock that stops moving it ends after 10,000
spin rounds in a row without the clock moving, a count of the thread's
own work rather than of wall time. An unreadable clock still falls back
to 25 ms of wall time.

Tests: R1 (each_tick_burns_the_probe_tick_of_thread_cpu_time) now
requires 25 ms of thread CPU from every tick. Its escape clause for a
tick that hit the wall cap is gone; that clause let a tick that only
slept for 500 ms pass. The R2 floor is unchanged, and its message no
longer cites the cap.

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

jcp-energy: the probe tick burns its whole 25 ms of thread CPU ... 7fc2315ab0

The liveness probes' tick (liveness::burn_tick, which the per-process,
IOReport and RAPL probes all use) burned 25 ms of the probing thread's
CPU time but gave up after 500 ms of wall time. On a host that runs the
thread for under 5% of a core, the cap cut the tick short. A probe that
burns less between samples can see a live counter hold, and call it
frozen. The meter's verdict then depends on host load. This is the
defect fixed in proof-cascade's tick, in this crate's own copy.

Production change: liveness::burn is bounded by thread CPU time only.
The tick ends once the thread has burned the whole 25 ms, however much
wall time that takes. Against a thread CPU clock that stops moving it
ends after 40,000 spin rounds in a row without the clock moving, a count
of the thread's own work rather than of wall time. With no readable
thread clock it still spins 500 ms of wall time, as before; the constant
is renamed PROBE_TICK_NO_CLOCK_WALL for that remaining role.

Tests: assert_ticks_burned drops its escape clause
(`|| wall >= TICK_WALL_CAP`) and requires 25 ms of thread CPU from every
tick. The real-probe test requires a whole tick of CPU per interval
unconditionally, where it allowed half a tick whenever a tick was slow.

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

jouleclaw-energy: the probe ticks burn their whole 25 ms of thread CPU ... 0a17079912

Both liveness ticks in this crate had a 500 ms wall-time cap. One is
liveness::burn_thread_cpu, used by the shared probe (the per-process,
RAPL and NVML counters). The other is apple_ioreport's own
burn_thread_cpu, used by the IOReport rail probe. Each burned its tick of
the probing thread's CPU time, but gave up after 500 ms of wall time. On
a host that runs the thread for under 5% of a core, the cap cut the tick
short. A probe that burns less between samples can see a live counter
hold, and call it frozen. The meter's verdict then depends on host load.
This is the defect fixed in proof-cascade's tick.

Production change: both are bounded by thread CPU time only. A tick
ends once the thread has burned the whole amount, however much wall time
that takes. Against a thread CPU clock that stops moving, it ends after
liveness::STUCK_CLOCK_ROUNDS (40,000) spin rounds in a row without the
clock moving, a count of the thread's own work rather than of wall time.
With no readable thread clock each still spins its amount of wall time,
as before. The wall_cap parameter and PROBE_TICK_WALL_CAP are gone; the
tests that passed a cap to the burn as a hang guard pass only the CPU
amount now.

Tests: apple_ioreport's assert_tick drops its escape clause
(`|| wall >= TEST_TICK_WALL_CAP`) and requires 25 ms of thread CPU from
every tick, however long it took.

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

Merge origin/main (6205b38f) into ci/energy-tests-load-independent ... 4b1a480883

Brings the branch up to date with main before review. No file this
branch changes was touched on main, so the merge is clean.

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

Revert "jouleclaw-energy: end the child window on the child's energy, not 300 ms" ... 3201f5f92e

This reverts commit 85aab023. PR #166 (energy/load-robust-tests) fixes
the same test, jouleclaw-energy/tests/process_cpu.rs, the same way: it
reads the child's own counter until it reaches 0.2 J, for at least
300 ms and at most 5 s. Dropping this branch's copy of that fix keeps
the two PRs from conflicting on the file; #166 carries it.

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

Merge origin/main (ab9650d5) into ci/energy-tests-load-independent ... 76a7f148a9

Brings the branch up to date with main (past ade3f855) before review.
Main changed none of the files this branch changes, so the merge is
clean.

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

dcharlot changed title from energy probes and tests: a tick burns its whole thread-CPU budget, so host load no longer decides them to jcp-energy: compare two threads' energy within one span, so host load no longer decides the test 2026-10-07 14:30:34 -04:00

dcharlot added 4 commits 2026-10-07 14:30:35 -04:00

Revert "jouleclaw-energy: the probe ticks burn their whole 25 ms of thread CPU" ... a45a070ef2

This reverts commit 0a17079912.

Revert "jcp-energy: the probe tick burns its whole 25 ms of thread CPU" ... d960a72b38

This reverts commit 7fc2315ab0.

Revert "proof-cascade: the probe tick burns its whole 25 ms of thread CPU" ... 2db8eff608

This reverts commit 2641dead72.

Merge origin/main (#166) into ci/energy-tests-load-independent ... 2523d8e2ed

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

dcharlot merged commit 5e3e83e2d2 into main 2026-10-07 21:21:28 -04:00

dcharlot referenced this pull request from a commit 2026-10-07 21:21:28 -04:00

Merge pull request 'jcp-energy: compare two threads' energy within one span, so host load no longer decides the test' (#179) from ci/energy-tests-load-independent into main

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

Subscribe

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!179

No description provided.