Software-Based Meters and Measurement software
1. Software-Based Power and Resource Meters
2. Common examples
Next step: Laboratory Design Methodology

Software-Based Meters and Measurement software

Software-Based Power and Resource Meters

Software-based energy measurement refers to techniques where power and energy consumption data is obtained through software interfaces rather than external physical instrumentation. Such methods may expose measurements originating from built-in hardware sensors or estimate energy consumption using software models and performance counters. Software-based measurement is particularly attractive because it requires little or no additional hardware and can often be integrated directly into development and monitoring workflows.

Modern software-based energy measurement systems typically exhibit a layered architecture consisting of hardware, operating system, and application layers.

Hardware layer

At the lowest level, certain hardware devices provide built-in capabilities for observing electrical quantities such as voltage, current, temperature, fan speed, instantaneous power, or cumulative energy consumption. These capabilities are commonly implemented using integrated power monitor circuits, coulomb counters, power management integrated circuits (PMICs), or specialized energy measurement functionality integrated directly into processors and system-on-chip (SoC) devices.

Examples include processor energy counters exposed through model-specific registers (MSRs), battery fuel gauges in mobile devices, and embedded sensors integrated into GPUs, network interfaces, and storage devices. The measured quantities may vary depending on the implementation and can include energy consumption of the entire system or specific subsystems such as CPUs, GPUs, memory, or batteries.

Operating system layer

The operating system provides access to hardware telemetry through drivers, kernel frameworks, and standardized interfaces. These abstractions hide hardware-specific implementation details and expose measurements in user-friendly units and formats, via programmer friendly APIs (buffered, asynchronous).

Access methods range from direct hardware access through userspace drivers to high-level kernel frameworks that aggregate and normalize data from multiple devices. Common examples include Linux HWMON and powercap subsystems, which expose sensor data through standardized interfaces under the sysfs virtual filesystem.

Software-based measurements may originate from dedicated hardware sensors or from processor-specific interfaces. For example, the Intel Running Average Power Limit (RAPL) interface exposes cumulative energy counters for various processor domains, while GPU vendors provide dedicated management APIs for monitoring power consumption and utilization.

Application layer

At the application level, measurement data is collected, visualized, and analyzed by monitoring tools, loggers, dashboards, and automation frameworks. Interactive dashboards are typically useful for observing the current state of a system and performing exploratory analysis, whereas background daemons and data loggers are more suitable for long-term monitoring and automated measurements.

High-level measurement frameworks aggregate data from multiple sources and synchronize telemetry with workload execution. This enables reproducible experiments and integration with software engineering workflows. In the context of this work, systems such as PowerGoblin utilize operating system interfaces and measurement daemons to collect and process energy-related telemetry.

Common software interfaces

Several software interfaces have become de facto standards for energy and resource monitoring in ICT systems:

RAPL (Running Average Power Limit) provides processor energy counters for CPUs and other processor domains. Although originally designed for power capping, RAPL is widely used for energy measurements. The interface exposes cumulative energy values, from which average power can be computed over time intervals.
NVML (NVIDIA Management Library) provides access to GPU telemetry, including power consumption, utilization, temperature, clock frequencies, and memory statistics.
ACPI (Advanced Configuration and Power Interface) exposes power management and battery information for many consumer devices and laptops.
WMI (Windows Management Instrumentation) provides a general-purpose interface for accessing hardware telemetry and system information on Windows systems.
I²C- and SMBus-based sensors, including PMICs and battery management systems, expose measurements from integrated power monitors and environmental sensors.
Linux perf and perf_event provide access to hardware performance counters and, on some systems, energy measurement interfaces such as RAPL.
IPMI and Redfish are commonly used in server environments to expose system-level power measurements and management information.

Resource monitoring and energy analysis

In addition to direct power measurements, operating systems expose extensive resource utilization statistics, including processor usage, memory consumption, disk activity, network traffic, process states, and thread scheduling information. While these metrics do not directly represent energy consumption, they provide valuable contextual information for interpreting power measurements.

Resource statistics are particularly useful when analyzing the relationship between system activity and power consumption over time. By synchronizing telemetry streams using timestamps, it becomes possible to perform time-domain analyses such as scatter plots, correlation analysis, and workload characterization. For example, network throughput may be correlated with power consumption in communication-intensive workloads, or CPU utilization may be compared against measured processor energy usage.

Such combined analysis is especially valuable for software optimization (green code!), as it enables developers to identify the hardware resources responsible for increased energy consumption and evaluate the effects of optimization strategies.

Limitations of software-based measurements

Although software-based measurement methods are convenient and inexpensive, they also have important limitations. The accuracy and sampling rate of measurements depend heavily on hardware support and vendor implementations. Different manufacturers may expose different measurement domains, resolutions, and update intervals, making comparisons across platforms challenging.

Furthermore, software-based measurements often provide only aggregate values for shared resources, complicating the attribution of energy consumption to individual applications or processes. As a result, software-based measurements should ideally be validated against external physical instrumentation when high accuracy or cross-platform comparability is required. Of course, in modern day systems with hundreds of concurrent threads and asynchronous tasks, doing process-level energy accounting is challenging even when using dedicated physical energy meters.

Common examples

Running Average Power Limit (RAPL)

Machines with the RAPL (Running Average Power Limit) feature provide internal support for power / energy measurement. Recent Intel & AMD CPUs provide machine registers for RAPL. Support for RAPL was also added to Linux 3.10 in 2013, and exposed later via the powercap framework (kernel API). Depending on the hardware generation, RAPL provides energy estimations for the following units (in µJ):

The whole package (package-0)
The cores (core)
The non-core parts of the SoC package (client processors, uncore)
The DRAM (server processors, dram)
System (psys)

From the hardware perspective, the supported CPU generations are:

Generation	Model name	Support
Intel
1st Gen Core	Nehalem / Westmere	No, no RAPL MSRs
2nd Gen Core	Sandy Bridge (EP)	Yes, first RAPL implementation
3rd Gen Core	Ivy Bridge (EP)	Yes, expanded support
4th Gen Core	Haswell (EP)	Yes, better DRAM support
5th Gen Core	Broadwell (EP)	Yes, continued
6th Gen Core	Skylake (EP)	Yes, added PSys domain on some SKUs
7th Gen+ Core	Kaby Lake+	Yes, fully supported
AMD
Bulldozer / Piledriver / Excavator	FX/APU era	No,different telemetry mechanisms
Ryzen 1000	Zen 1	Yes, (limited) Package energy mainly
Ryzen 2000	Zen+	Yes, improved
Ryzen 3000	Zen 2	Yes, better domain support
Ryzen 5000	Zen 3	Yes, widely supported
Ryzen 7000	Zen 4	Yes, fully supported

NVIDIA Management Library (NVML)

Nvidia graphics cards support the reading of resource information and power consumption estimates via the NVML interface. Depending on the hardware support, NVML provides resource data and energy estimations for:

GPU memory (memory-used, memory-free), unit: bytes
GPU load (percent-gpu_used), unit: percent
fan speed (fanspeed), unit: rpm or percent (?)
temperature (temperature-core), unit: °C
frequency (frequency-multiprocessor, frequency-memory), unit: Hz
power (power), unit: Watts

The information above was extracted from our test device (Geforce GTX 1080).

Tool: collectd

The collectd tool exposes software-based meter interfaces for the monitoring of resource usage. Collectd is extensible thanks to its plugin framework and a large collection of integrated and third party plugins. Collectd also has a low footprint in terms of resource consumption. These features make it a comprehensive tool for data collection. These are also the reason why collectd is being used as a data collection background process by PowerGoblin.

The following table shows the different variables that collectd supports measuring with different plugins:

Plugin	Power	CPU	Memory	Network	Disk	Process
apc ups	X (ups)
nut	X (ups)
ted	X (power)
mic	X (mic)
battery	X (laptop)
ipmi	X (ipmi)
snmp	X (ipmi)
mbmon	X (sensors)
redfish	X (sensors)
sensors	X (sensors)
thermal	X (sensors)
multimeter	X (multimeter)
sigrok	X (multimeter)
smart	X (hdd)
hddtemp	X (hdd)
wireless	X (wireless)
gpu_nvidia	X (gpu)
intel_rapl	X (rapl)
cpu		X
cpufreq		X
xen		X
turbostat		X
contextswitch		X
memory			X
swap			X
vmem			X
buddyinfo			X
dns				X
interface				X
iptables				X
netlink				X
ethstat				X
madwifi				X
disk					X
df					X
cgroups						X
load						X
processes						X
dbi						X (db)
virt		X	X	X	X

HWMON drivers

We studied the HWMON framework in Linux 6.x and found the following list of drivers which can extract energy consumption related readings:

Measurement ICs
- ina*, ltc*, max*, adm*, isl*
- lm25066, lochnagar, pli1209bc, stpddc60
- pmbus
DC converters
- ir*
- lineage-pem, pxe1610, tps53679, ucd9000, ucd9200
Power supplies
- acbel-fsg032
- bel-pfe, bpa-rs600,
- corsair-psu, crps, dps920ab
- ibm-cffps, inspur-ipsps1, lineage-pem, twl4030-madc-hwmon
System platforms
- hp-wmi-sensors
- ibmpowernv
- intel-m10-bmc-hwmon
- occ-hwmon
- sbrmi
- xgene-hwmon
pump/fan
- aquacomputer_d5next

Other software

The following monitoring software surveyed are not well suited for power measurement data collection, as they are mainly interactive: top, htop, busybox top, iotop, iptraf, iftop. The use of some software (e.g. Prometheus and JVM flight recorder) is concentrated on systems based on Docker containers or Java services. A number of remote monitoring applications have also been developed for resource use, but they also impose a resource load on the system being measured, for example by providing a web interface or by processing and visualizing data. The study was limited to those applications that were not found to impose any additional burden in terms of maintaining remote connections.

The following tools and their metrics were categorized in the mapping exercise:

Tool	Power	CPU	Central memory	Network	Disk usage	Operating system processes
nmon		X	X	X	X	X
atop		X	X			X
vmstat		X	X		X	X
sysstat/iostat
statsd
java flight recorder		X	X
rapl-read	X
mozilla_rapl	X
PAPI	X
Intel Power Gadget	X
perf	X
turbostat	X

Next step: Laboratory Design Methodology

The next analysis section covers the Laboratory Design Methodology.