ci: run the energy meters' RAPL and NVML tests on real hardware (jetson-hub, linux-hw) #162

Merged

dcharlot merged 1 commit from ci/energy-hardware-linux-hw into main 2026-10-05 15:54:21 -04:00

Conversation 0 Commits 1 Files changed 1 +123

dcharlot commented 2026-10-05 12:06:41 -04:00

Owner

Copy link

Runs the energy meters' Linux RAPL and NVML hardware tests (from #129) against real counters, in CI.

Why. Every other job runs in a container. Docker masks /sys/devices/virtual/powercap there and gives no GPU, so those tests only ever took their "unavailable, and the oracle agrees" branch. Nothing in CI exercised the live path.

Where. A new runner, jetson-hub-linux-hw, label linux-hw: a host executor on jetson-hub.

• Hardware: an Intel i9-13900H (package-0, a core sub-zone, psys, an mmio package) and an RTX 4050 Laptop GPU.
• Isolation: it runs as txhw, a dedicated user with no sudo and no docker, which can read powercap and open /dev/nvidia*.
• Service: systemd forgejo-runner-hw, beside the existing docker runner, which is unchanged.

What it runs. The six crates' hardware tests:

Crate	Tests	Features
jcp-energy	RAPL, NVML	nvml
eoc-meter	RAPL, NVML	cuda
sandbox-meter	RAPL, NVML
sandbox-exec-microvm	RAPL
proof-cascade	RAPL
jouleclaw-energy	RAPL, NVML	rapl,nvml

Each step fails unless the live path ran:

• RAPL: the oracle's package-only inner … outer … bracket was printed. Only the live path prints it, after asserting the meter read inside the bracket and below package+psys and package+core. For proof-cascade, the oracle has to say Live instead.
• NVML: the test saw the GPU (nvml hardware: 1 GPU). On this GPU the counter runs past the board while it is polled, so the tests assert it is Implausible and never graded as hardware.

Mechanics. The host has no Node, so there are no JavaScript actions:

• the source is fetched with plain git from the forge, and the step checks it got the commit the run is for;
• target directories persist in the runner's home, so later runs are incremental;
• builds run under nice and -j 8, since the host is also the docker runner and has 15 GB of RAM.

Triggers. Pull requests and pushes to main that touch those six crates or this workflow. This PR touches the workflow, so its own run is the first real test.

🤖 Generated with Claude Code

Runs the energy meters' Linux RAPL and NVML hardware tests (from #129) against **real counters**, in CI. **Why.** Every other job runs in a container. Docker masks `/sys/devices/virtual/powercap` there and gives no GPU, so those tests only ever took their "unavailable, and the oracle agrees" branch. Nothing in CI exercised the live path. **Where.** A new runner, `jetson-hub-linux-hw`, label **`linux-hw`**: a **host executor** on jetson-hub. - **Hardware:** an Intel i9-13900H (`package-0`, a `core` sub-zone, `psys`, an mmio package) and an RTX 4050 Laptop GPU. - **Isolation:** it runs as `txhw`, a dedicated user with no sudo and no docker, which can read powercap and open `/dev/nvidia*`. - **Service:** systemd `forgejo-runner-hw`, beside the existing docker runner, which is unchanged. **What it runs.** The six crates' hardware tests: | Crate | Tests | Features | |---|---|---| | jcp-energy | RAPL, NVML | `nvml` | | eoc-meter | RAPL, NVML | `cuda` | | sandbox-meter | RAPL, NVML | | | sandbox-exec-microvm | RAPL | | | proof-cascade | RAPL | | | jouleclaw-energy | RAPL, NVML | `rapl,nvml` | Each step fails unless the live path ran: - **RAPL:** the oracle's `package-only inner … outer …` bracket was printed. Only the live path prints it, after asserting the meter read inside the bracket and below package+psys and package+core. For proof-cascade, the oracle has to say Live instead. - **NVML:** the test saw the GPU (`nvml hardware: 1 GPU`). On this GPU the counter runs past the board while it is polled, so the tests assert it is Implausible and never graded as hardware. **Mechanics.** The host has no Node, so there are no JavaScript actions: - the source is fetched with plain git from the forge, and the step checks it got the commit the run is for; - target directories persist in the runner's home, so later runs are incremental; - builds run under `nice` and `-j 8`, since the host is also the docker runner and has 15 GB of RAM. **Triggers.** Pull requests and pushes to `main` that touch those six crates or this workflow. This PR touches the workflow, so its own run is the first real test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-05 12:06:41 -04:00

ci: run the energy meters' RAPL and NVML tests on real hardware ... 9318986759

Every existing job runs in a container. Docker masks
/sys/devices/virtual/powercap there and gives no GPU, so the energy
crates' hardware tests only ever took their "unavailable, and the oracle
agrees" branch. This job runs on `linux-hw`, a host executor on
jetson-hub. It runs as an unprivileged user (no sudo, no docker) that
can read powercap and open /dev/nvidia*, on an Intel i9-13900H with
package-0, a core sub-zone, psys and an mmio package, and an RTX 4050
Laptop GPU.

It runs jcp-energy, eoc-meter, sandbox-meter, sandbox-exec-microvm,
proof-cascade and jouleclaw-energy, with their NVML features on. Each
step fails unless the live path ran:
- RAPL: the oracle's package-only bracket was printed;
- NVML: the GPU was seen.

The source is fetched with plain git (the host has no Node), and the
step checks it got the commit the run is for. Target dirs persist in
the runner's home between runs.

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

dcharlot merged commit fe87dcb670 into main 2026-10-05 15:54:21 -04:00

dcharlot referenced this pull request from a commit 2026-10-05 15:54:23 -04:00

Merge pull request 'ci: run the energy meters' RAPL and NVML tests on real hardware (jetson-hub, linux-hw)' (#162) from ci/energy-hardware-linux-hw 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!162

No description provided.