energy tests: a 0.1 J burn floor, tick-driven fake RAPL trees, stale trees cleared #136

Merged

dcharlot merged 2 commits from energy/burn-floor-0-1-j into main 2026-10-04 14:04:32 -04:00

Conversation 0 Commits 2 Files changed 4 +47 -41

dcharlot commented 2026-10-01 12:35:09 -04:00

Owner

Copy link

Two per-process energy tests required 0.2 J for 200 ms of one thread's CPU:

• sandbox-meter's process_energy;
• jouleclaw-energy's process_cpu.

On a busy host the burn took 1 s of wall time and read 0.171 J, and the test's own oracle around it read the same 0.171 J. The meter was right and the floor was wrong. What 200 ms of CPU costs depends on the core class that ran it; on an M5 Max it read 0.18–1.24 J. jcp-energy's and eoc-meter's equivalent tests already use 0.1 J.

Both floors are now 0.1 J. That is also the sleeping test's ceiling, so a counter that reads wall time at a fixed power still fails one of the two tests.

Verified: cargo test -p sandbox-meter --test process_energy (5 passed) and cargo test -p jouleclaw-energy --test process_cpu (1 passed), on macOS.

Fake RAPL trees: driven by the probe's tick, and cleared before use (515545ab)

sandbox-meter's the_public_package_counter_opens_only_over_live_packages failed once, in a full workspace run on a heavily loaded host just after a restart. It passed on its own. I built test binaries of the old and new forms and ran each 12 times under 24 CPU hogs; both passed every time. So the cause was not reproduced. Two inputs the tests didn't control could produce it, and this commit removes both:

• Thread scheduling. sandbox's two liveness tests advanced the fake packages from a writer thread on a 2 ms timer, while the probe's tick slept 25 ms. A writer starved for a whole interval would make a live tree read as Frozen. The tick now advances the zones itself, then sleeps, so every interval sees exactly one advance. The 300 ms window rule still runs on the real clock. jcp-energy's and jouleclaw-energy's equivalent tests keep their writer thread, because they test the real probe with its own tick.
• Leftover trees. sandbox's and jcp-energy's fake powercap roots are named by pid and a counter, and were built into whatever already sat at that path. A killed test process never drops its trees, so a later process reusing that pid could inherit stale zones. The root is now cleared first, as eoc-meter's and jouleclaw-energy's fakes already do.

Verified: cargo test -p sandbox-meter --lib (122 passed) and cargo test -p jcp-energy --lib (84 passed).

🤖 Generated with Claude Code

Two per-process energy tests required 0.2 J for 200 ms of one thread's CPU: - sandbox-meter's `process_energy`; - jouleclaw-energy's `process_cpu`. On a busy host the burn took 1 s of wall time and read **0.171 J**, and the test's own oracle around it read the same 0.171 J. The meter was right and the floor was wrong. What 200 ms of CPU costs depends on the core class that ran it; on an M5 Max it read 0.18–1.24 J. jcp-energy's and eoc-meter's equivalent tests already use 0.1 J. Both floors are now 0.1 J. That is also the sleeping test's ceiling, so a counter that reads wall time at a fixed power still fails one of the two tests. **Verified:** `cargo test -p sandbox-meter --test process_energy` (5 passed) and `cargo test -p jouleclaw-energy --test process_cpu` (1 passed), on macOS. ### Fake RAPL trees: driven by the probe's tick, and cleared before use (515545ab) sandbox-meter's `the_public_package_counter_opens_only_over_live_packages` failed once, in a full workspace run on a heavily loaded host just after a restart. It passed on its own. I built test binaries of the old and new forms and ran each 12 times under 24 CPU hogs; both passed every time. So the cause was **not reproduced**. Two inputs the tests didn't control could produce it, and this commit removes both: - **Thread scheduling.** sandbox's two liveness tests advanced the fake packages from a writer thread on a 2 ms timer, while the probe's tick slept 25 ms. A writer starved for a whole interval would make a live tree read as Frozen. The tick now advances the zones itself, then sleeps, so every interval sees exactly one advance. The 300 ms window rule still runs on the real clock. jcp-energy's and jouleclaw-energy's equivalent tests keep their writer thread, because they test the real probe with its own tick. - **Leftover trees.** sandbox's and jcp-energy's fake powercap roots are named by pid and a counter, and were built into whatever already sat at that path. A killed test process never drops its trees, so a later process reusing that pid could inherit stale zones. The root is now cleared first, as eoc-meter's and jouleclaw-energy's fakes already do. Verified: `cargo test -p sandbox-meter --lib` (122 passed) and `cargo test -p jcp-energy --lib` (84 passed). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-01 12:35:10 -04:00

energy tests: a 200 ms burn's floor is 0.1 J in sandbox and jouleclaw ... 0cfa3a6c7b

sandbox-meter's process_energy and jouleclaw-energy's process_cpu
required 0.2 J for 200 ms of one thread's CPU. On a busy host the burn
took 1 s of wall time and read 0.171 J, and the oracle around it read
the same 0.171 J. The meter was right and the floor was wrong. What
200 ms of CPU costs depends on the core class that ran it: on an M5 Max
it read 0.18-1.24 J. jcp-energy's and eoc-meter's equivalent tests
already use 0.1 J.

The floor is now 0.1 J in both. That is also the sleeping test's
ceiling, so a counter that reads wall time at a fixed power still fails
one of the two.

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

dcharlot added 1 commit 2026-10-01 18:39:57 -04:00

energy tests: drive the fake RAPL trees from the probe's tick, and clear stale ones ... 515545abcc

sandbox-meter's the_public_package_counter_opens_only_over_live_packages
failed once in a full workspace run on a heavily loaded host, just after
a restart. It passed on its own, and in 12 of 12 runs under 24 CPU hogs
in both its old and new forms. The cause was not reproduced. Two inputs
the tests did not control could produce it, and both are removed here.

- Thread scheduling: sandbox's two liveness tests advanced the fake
  packages from a writer thread on a 2 ms timer, while the probe's tick
  slept 25 ms. A writer starved for a whole interval reads a live tree
  as Frozen. The tick now advances the zones itself, then sleeps, so
  every interval sees exactly one advance. The 300 ms window rule still
  runs on the real clock. jcp-energy's and jouleclaw-energy's
  equivalents keep their writer thread, because they test the real
  probe with its own tick.
- Leftover trees: sandbox's and jcp-energy's fake powercap roots are
  named by pid and a counter, and were built into whatever already sat
  at that path. A killed test process never drops its trees, so a later
  process reusing that pid could inherit stale zones. The root is now
  cleared first, as eoc-meter's and jouleclaw-energy's fakes already do.

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

dcharlot changed title from energy tests: a 200 ms burn's floor is 0.1 J in sandbox and jouleclaw to energy tests: a 0.1 J burn floor, tick-driven fake RAPL trees, stale trees cleared 2026-10-01 18:40:16 -04:00

dcharlot force-pushed energy/burn-floor-0-1-j from 515545abcc to cc133929c1 2026-10-01 23:39:18 -04:00 Compare

dcharlot merged commit c99c022d57 into main 2026-10-04 14:04:32 -04:00

dcharlot referenced this pull request from a commit 2026-10-04 14:04:33 -04:00

Merge pull request 'energy tests: a 0.1 J burn floor, tick-driven fake RAPL trees, stale trees cleared' (#136) from energy/burn-floor-0-1-j 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!136

No description provided.