Changes between Version 9 and Version 10 of Public/Energy

Timestamp:

Dec 17, 2020, 8:44:41 AM (3 years ago)

Author:

Alessio Netti

Comment:

—

Public/Energy

@@ -81 +81 @@
 }}}
 
+==== Energy and Power Sensors
+
+DCDB provides several types of energy and power measurements that can be useful for performance analysis. Depending on the data source, these can have different units and scales - this information can be shown by querying a sensor with the {{{dcdbconfig sensor show}}} command. In detail, these are the energy sensors available for compute nodes in the DEEP-EST prototype:
+
+* **energy** [Joules]: energy consumption of a compute node as a whole.
+* **pkg-energy** [!MicroJoules]: energy consumption of a compute node's CPUs.
+* **dram-energy** [!MicroJoules]: energy consumption of a compute node's memory components.
+* **gpu0/energy** (ESB, DAM) [!MilliJoules]: energy consumption of Nvidia V100 GPUs.
+* **gpu0/sysfs-energy** (ESB) [Joules]: alternative sensor for the energy consumption of Nvidia V100 GPUs, not including the energy drawn via PCIe.
+* **sysfs-energy** (ESB) [Joules]: energy consumption of an ESB compute node, excluding the GPU.
+
+These, instead, are the available sensors for estimating power consumption:
+
+* **power** [!MilliWatts]: power consumption of a compute node as a whole. On DAM nodes this sensor is quantified in Watts.
+* **gpu0/power** (ESB, DAM) [!MilliWatts]: power consumption of Nvidia V100 GPUs.
+* **gpu0/sysfs-power** (ESB) [!MilliWatts]: alternative sensor for the power consumption of Nvidia V100 GPUs, not including the energy drawn via PCIe.
+
+In the case of multi-socket systems (i.e. CN and DAM), the pkg and dram energy and power sensors are available both for each single socket (e.g., under {{{socket0/pkg-energy}}}), as well as for the entire compute node. The same aggregation scheme applies for sensors associated with CPU performance counters. Aside from those on compute nodes, many other energy and power sensors are available on the DEEP-EST prototype: these are associated with the system's infrastructure and cooling equipment.
+
 ==== Using dcdbquery for Job Queries
 
@@ -101 +120 @@
 The {{{<SENSORNAME>}}} field identifies instead the aggregated metric and can be one of the following:
 
-* energy
-* dram-energy
-* pkg-energy
-* MemUsed
-* instructions
-* cpu-cycles
-* cache-misses
-* cache-misses-l2 
-* cache-misses-l3
-* scalar-double
-* scalar-double-128 
-* scalar-double-256 
-* scalar-double-512
-* gpu-energy (DAM, ESB)
-* ib-portXmitData (CN, ESB) 
-* ib-portRcvData (CN, ESB)
+* **energy** [Joules]: energy consumption of nodes, as computed from the respective energy sensors.
+* **dram-energy** [!MicroJoules]: energy consumption of the nodes' memory, as computed from the dram-energy sensors.
+* **pkg-energy** [!MicroJoules]: energy consumption of the nodes' CPUs, as computed from the pkg-energy sensors.
+* **!MemUsed** [!KiloBytes]: amount of used RAM on the compute nodes.
+* **instructions**: number of CPU instructions executed on the compute nodes.
+* **cpu-cycles**: amount of CPU cycles (affected by frequency scaling) on the compute nodes.
+* **cache-misses**: total amount of CPU cache misses on the compute nodes.
+* **cache-misses-l2**: amount of CPU L2 cache misses on the compute nodes.
+* **cache-misses-l3**: amount of CPU L3 cache misses on the compute nodes.
+* **scalar-double**: number of double precision floating point operations on the compute nodes' CPUs.
+* **scalar-double-128**: number of double precision floating point operations using 128-bit vectorization.
+* **scalar-double-256**: number of double precision floating point operations using 256-bit vectorization.
+* **scalar-double-512**: number of double precision floating point operations using 512-bit vectorization.
+* **gpu-energy** (DAM, ESB) [!MilliJoules]: energy consumption of the compute nodes' GPUs, as computed from the gpu0/energy sensors. 
+* **ib-portXmitData** (CN, ESB) [Bytes]: amount of data transmitted over the Infiniband network. 
+* **ib-portRcvData** (CN, ESB) [Bytes]: amount of data received over the Infiniband network.
 
 Finally, the {{{<STATNAME>}}} field identifies the actual type of aggregation performed from the readings of the queried sensor, by combining the data of all compute nodes on which the job was running. It can be one of the following:
 
-* .sum (sum of all 10s measurements in a certain 30s time window)
-* .avg (average of all 10s measurements in a certain 30s time window)
-* .med (median of all 10s measurements in a certain 30s time window)
+* **.sum**: sum of all 10s measurements in a certain 30s time window.
+* **.avg**: average of all 10s measurements in a certain 30s time window.
+* **.med**: median of all 10s measurements in a certain 30s time window.
 
 In order to get a cumulative measure of a job's performance (e.g., total energy spent or total amount of instructions computed), {{{.sum}}} should be used. Moreover, for a job to be measured by DCDB, its duration has to be longer than 30s. We currently expect to store job data for the entire lifetime of the system, and hence the time-to-live of 30 days does not apply to it.
+
+==== BeeGFS Performance Metrics
+
+DCDB also exposes a series of performance metrics associated with the BeeGFS distributed file system. Comprehensive documentation about the available metrics and their meaning is available [https://www.beegfs.io/wiki/MonDatabaseReference here]. All BeeGFS sensors in the DCDB database are identified by the {{{/deepest/beegfs/}}} prefix, and they can be listed by using the following command:
+
+{{{
+dcdbconfig sensor listpublic | grep beegfs
+}}}
+
+Most BeeGFS sensors do not directly map to users and compute nodes in the DEEP-EST prototype, and they require knowledge of the system's architecture to be interpreted.
 
 ==== Long-term Sub-sampled Sensor Data