This documentation is an english translation and adaptation derived from the preliminary analysis done in the MitViDi guide.
Software-based power measurement
Each current meter has its own unique method for data collection and data reading. Almost all the meters in the study communicate with the computer via a USB bus. The HardKernel SmartPower 3, which is the recommended purchase, also communicates over the USB bus so that the meter appears to the computer as a serial port (UART) that communicates through the device's touch interface with the connection settings (115200 bps) and interval set. Typically, programs using the serial port on a PC can read textual output from the instrument directly by first selecting the correct connection speed. A single measurement point appears on the printout as a single line with the voltage, current and power of the measurement channel separated by commas. For a more detailed description of the protocol, see the official support page of the device
In addition to the recommended power meter programming, the MitViDi project explored other possible software-based resource meters that can be used to estimate power consumption based on data. One argument for software-based power measurement is the potential difficulty or impossibility of accessing the system to be physically measured. Software-based metering allows devices to be measured without physical access to their equipment. In particular, the technology offers opportunities for power measurement of server equipment. The software used in the study is mainly Linux-based, as server equipment is often Linux-based.
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 visualising 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 categorised in the mapping exercise:
| Tool | Power | CPU | Central memory | Network | Disk usage | Operating system processes |
|---|---|---|---|---|---|---|
| collectd | X | X | X | X | X | X |
| 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 |
The described list can also be used in the measurement process as an extension of the physical hardware power measurement data. If the data points from different sources can be timed accurately, the correlations between the results can be used for a more detailed analysis of power consumption to distinguish the impact of different resource types on the overall consumption.