mitchell/hamlab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 14 Wiki Activity

PLAN.md: CPU power on the Processes tab, shipped as v0.1.0-194

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Mitchell-Johnson
2026-10-11 00:00:05 -07:00
co-authored by Claude Opus 5.5
parent bfedf622be
commit a9b4d7969e
2 changed files with 9 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN.md
+8
View File
@@ -327,6 +327,14 @@ something long in one, switch away and back, refresh — it's all still there.
`grid` the sampler hung for 42 minutes in Go's poller on the Arc's `fan1_input` —
`readStr` now uses plain blocking syscalls and each GPU's sysfs reads run under a
3-second deadline (v0.1.0-168; `hamlet/docs/gotchas.md` has the mechanism).
- **CPU power on the Processes tab** — **shipped 2026-10-10** (v0.1.0-194,
`internal/metrics/cpupower.go`, the `cpu.power` sensor). Asked for beside the clock speed,
and that is where it sits: "3600 MHz · 89 W" in the cpu box's header. Watts are the RAPL
package energy counters' delta between samples, summed over packages; `psys`, a package's
parts and the MMIO duplicate are left out. The counters are root-only, so a daemon running
as `core` keeps a second root child, `hamlab cpu-energy`, beside `drm-clients`. Read on all
four Intel machines; the Mac mini has no CPU-only counter (its SMC reports the whole
machine's draw instead) and shows nothing.
- **The ARC on the ZFS tab** — **shipped 2026-10-02** (`internal/metrics/arc.go`,
`internal/storage/arc.go`, `GET /api/zfs/arc`, the Cache section in `ZFS.tsx`, `zfs.arc.*`
sensors). Asked for as "current ARC usage, including any types of caching services in the