To better understand the logic behind PowerGoblin's measurement, we will familiarize ourselves with the application's terminology first.
PowerGoblin Instance
When PowerGoblin is started, a runtime application process, aka PowerGoblin Instance, remains operational on the host system. Unless configured differently, this process accepts connections from the outside world by default, i.e. works in a server mode. The process will accept connections from ANY interface on the host system. If you need more fine-grained access control or wish to limit the memory and CPU consumption of the process, consider configuring access permissions e.g. using a systemd unit (on Linux) or firewall settings. Configuring such settings is out of the scope of this manual.
The instance has the following associated properties:
- Services for listening to connections from clients (interface + port combinations can be queried)
- Set of free meters (see Meter) not associated with sessions
- Set of active sessions (see Session) (old sessions are stored on disk and can be restored on request)
- Global configuration for the instance
- Uptime, log file count etc. live data
Session
The session consists of all data related to the measurement arrangement. The general idea is that the session data can be stored and opened for later review without losing any information related to the measurement. Since the associated meters (see Meter) can be added or removed from an instance, in general it is not possible to fully restore an existing session from disk. Even the same meters can be assigned with different device paths in the same instance (see Instance) after reconfiguration or hot-plug events, which makes the in-memory sessions unique.
The session contains various data such as the name and id of the session, the exact start and stop time (optional) of the session, a copy of the instance's configuration (see Configuration), a mapping of meter/channel ids to human-readable names, the specifications and handlers for the meters and all the aggregated data (resource consumption (see Data), events (see Event) with the session. The measurement data is further divided into measurements (see Measurement) and runs (see Run).
A session can be in one of two modes, open or closed. A closed session also has a stop time in addition to a start time. The general idea is to mark session as closed when all the measurements are done and the session is ready to be stored on disk. Further processing of the session should not alter the data unless explicitly requested. If more measurements need to be done, closing the session again will tag it with a different stop time to make it explicitly distinct from the previous session.
PowerGoblin supports multiple simultaneous sessions. Sessions can be either freshly started with associated meters or previous sessions restored from session dump file on disk. Performing measurements in a session will log events only from those meters associated with that session. In a session, it is not possible to further limit the logging of events. If some measurement does not require the data from a certain meter, that data can be discarded manually in later analysis, or certain meters can be unassigned and/or assigned between the measurements. However, during the measurements (there is an active measurement), some operations such as adding and removing of the meters is disabled to simplify to logic and to avoid corner cases in the logging of the data.
Meter
All the meters available on the PowerGoblin instance are either unassigned (assigned to a free pool) or assigned to a single session.
Sessions restored from disk will be assigned dummy meters that do not measure anything anymore. However, the dummy meters can be used to show all the specifications of the meters that were used in the session before it was stored to disk and restored. The main purpose of this is to reconstruct the measurement session for later analysis.
PowerGoblin also supports simulated meters which are virtual meters useful for the testing of the application. The meters generate random events and the number of available simulated meters can be configured when starting the application. Currently, no simulated meters can be added or removed from the application instance after startup.
Event
All the meters configured for the PowerGoblin instance will produce meter events. If the meter is unassigned (free), the past events will not be logged. Only the most recent event is used for visualizing the meter's state in the web GUI (the same data is also available via the APIs). When the meter is assigned to a session, past events will only be logged when the measurement is active. In that case the events are also associated with a measurement and a run.
During an active measurement session, PowerGoblin starts logging meter events from the meters assigned to the session. Each meter event either contains a reading associated with the channels of a meter or signals a read error. Currently, if a meter produces multiple points of data (e.g. multiple input/output channels) during a single time step, a distinct event is generated for each channel.
In addition to meter events originating from the meters, there are different kinds of control events. The user may wish to further configure the session (e.g. rename the session, meters/channels, or the measurement) to make it easier to later analyze the logged session data. Configuring such aspects produces control events. In addition, there is a concept called trigger event, which tells when a measurement or run starts or stops, or when a meter goes online or offline. In addition to these six, there is a custom trigger event for user generated triggers. All the trigger events have a field for a message that will be logged.
Command
Commands are control artifacts similar to events, but unlike events, the commands will be not stored as part of the session data. For example, trigger events for starting and stopping measurements are events, but a command for discarding or storing the session are commands. The commands are supposed to control the PowerGoblin instance and are not relevant for later analysis of the session data.
Measurement
A session consists of measurements. Different measurements represent different tasks. A measurement is identified by a pair of trigger messages for starting and stopping the measurement. E.g. a test setup can measure the power consumption of different sub-pages on a domain. Thus, each sub-page should trigger a separate measurement entity. Another example would be the measurement of different sorting algorithms. Each algorithm or a combination of algorithm and dataset would be a single measurement.
The measurements are identified with a name. By default, the measurements are named as M-1, M-2, and so forth. If needed, each measurement can be renamed when it is in the active state, i.e. not stopped. Please note that the events logged before the rename event will be associated with the old name. Measurements cannot be currently nested, thus only a single measurement can be active at any time.
Run
Each measurement consists of zero or more runs. The purpose of the runs is to support statistical analysis by tagging repetitions. Each distinct run in a measurement should perform exactly the same things unless you specifically want the data to also reflect the variations between the runs.
The runs will be identified with positive integers (1, 2, ...). Events will be logged even before the first run starts. This implicit run will have an id of 0. Thus, for measurements with only a single run, a run can be easily distinguished even without explicitly starting a run. Runs cannot be currently nested, thus only a single run can be active at any time.
Data sources
PowerGoblin aims to support a variety of mechanisms for importing measurement information from different types of data sources. For certain power meters (SmartPower & SmartPower 3), there is direct support in PowerGoblin. This is mainly because these devices do not use any standard protocol for transmitting measurement data.
On the other hand, PowerGoblin makes use of a tool called collectd for accessing a wide range of different data sources supporting existing standards and driver interfaces. Monitoring of CPU, memory, and network resources are provided via operating system's internal interfaces. Software based power measurements can be performed with devices utilizing different interfaces supported by collectd or 3rd party collectd plugins.
Some examples are presented here:
- RAPL: processor and DRAM energy / power
- NVML: GPU power
- HWMON
- 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
- Measurement ICs