Distinguish gross energy from activity above a baseline

Energy-proportional computing asks how system consumption changes with useful load, rather than assuming an idle machine is free. A simple affine model connects a measured idle point and a measured full-load point. It can help organize a local experiment, but the utilization coordinate must be defined. A GPU busy-time percentage does not describe which execution units switched, how much memory traffic occurred, or how much work completed. Two equally busy kernels can therefore draw different power.

An affine fit can also fail when operating states change. Clocks, voltage, temperature, memory behavior, or the number of active devices can change abruptly with load. Measure several representative operating points and inspect residuals before interpolating. Fit within a stated hardware configuration and workload family; do not extrapolate a line fitted to one job into another architecture. A baseline measured with a loaded model and warm memory need not equal one measured before initialization.

A CMOS switching approximation makes the voltage dependence explicit: charging effective capacitance more frequently requires more power. The activity factor represents how often relevant nodes switch. At fixed activity, capacitance, and frequency, doubling voltage multiplies this switching term by four. This reasoning explains why voltage choices matter, but it excludes leakage, regulator losses, memory subsystems, and other components unless additional terms are supplied. It cannot predict a board sensor from frequency alone.

Frequency and voltage are often coupled by an operating-point policy, but that coupling is hardware-specific. A cubic frequency rule requires extra assumptions about how voltage scales with frequency and about which power component dominates. State those assumptions if using such a model. Temperature can affect leakage and throttling, and reduced frequency may lengthen execution enough to increase total gross energy. Model the time response alongside the watts instead of treating a smaller power number as the final objective.

Gross energy integrates all power inside the boundary during the job. Incremental energy subtracts a hypothetical baseline over that same duration. The latter asks what changed relative to keeping this particular system in that particular idle state. It does not automatically describe what would happen if a scheduler consolidated jobs, suspended the machine, or released an entire server. Those alternatives change the counterfactual and may change shared background loads as well.

Report the baseline trace or approximation together with its temperature, residency, software state, and measurement window. If the system performs useful background work during the supposed idle run, subtraction can misattribute its energy. Negative incremental estimates can signal noise, mismatched conditions, or a real transition to a lower-power state; they are not proof that computation generated electricity. Retain gross totals even when incremental comparisons are useful for one narrowly defined optimization.