Blog

bmtop

Estimated watts in bmtop — attribution, not a wattmeter

Terminal monitors on Mac inherit two messy problems: process CPU is easy to rank, and “how many watts is Chrome using?” is not a single kernel field. bmtop shows SoC-oriented telemetry the release documents, and it is explicit that estimated watts are an attribution model.

What you can sort safely

CPU time, resident memory, threads, and similar counters come from standard process APIs. Sorting by those is straightforward:

// Illustrative ranking key — not the full bmtop sampler
#[derive(Clone, Copy)]
struct ProcSample {
    pid: i32,
    cpu_pct: f32,
    mem_bytes: u64,
    energy_impact: f32, // platform-derived signal when available
}

fn top_by_cpu(mut rows: Vec<ProcSample>) -> Vec<ProcSample> {
    rows.sort_by(|a, b| b.cpu_pct.partial_cmp(&a.cpu_pct).unwrap());
    rows
}

What “estimated watts” means

On Apple Silicon, system tools expose package-level power and thermal context. Mapping that package power onto individual PIDs requires a model: share of CPU energy impact, display attribution, and sampling windows. Different tools (Activity Monitor, powermetrics, menu-bar apps) disagree because they optimize for different questions.

bmtop’s product page states the boundary in plain language: estimated watts are not a laboratory per-process wattmeter. Treat them as a diagnostic hint next to CPU% when fans spin up — then confirm before you quit anything.

SoC / package telemetry  ──►  context strip (power, temp, fans when available)
Process samples          ──►  sortable table (CPU, memory, energy-related signal)
User confirmation        ──►  quit / signal (never silent kill by default)

Sensor coverage varies

Fan RPM and some temperature nodes are hardware-dependent. A missing fan row on a particular Mac is often “not exposed,” not “bmtop forgot the feature.” Always read the version notes on the product page for what the current build claims.

Related

Back to Blog