moved to sampling_rate instead of resolution

ArneTR · ArneTR · commit e6e73309aa87 · 2025-05-18T17:15:14.000+02:00
diff --git a/content/en/docs/installation/installation-macos.md b/content/en/docs/installation/installation-macos.md
@@ -61,7 +61,7 @@ You will need to disable all providers and enable the:
 
 ```yml
 powermetrics.provider.PowermetricsProvider:
-    resolution: 100
+    sampling_rate: 100
 ```
 
 in the `config.yml`.
diff --git a/content/en/docs/measuring/best-practices.md b/content/en/docs/measuring/best-practices.md
@@ -42,21 +42,21 @@ Our [Hosted Service]({{< relref "measuring-service" >}}) on our [Measurement Clu
     + If that is however what your application is design to operate it, then do not alter it. However most applications assume an
    infinite amout of resources and behave weirdly if they run into resource limitations
 
-### 3. The application you want to test must run at least twice as long as the minimal resolution
+### 3. The application you want to test must run at least twice as long as the minimal sampling rate
 
-- The minimal resolution is the one you have configured with your [Metric Providers]({{< relref "metric-providers" >}})
+- The minimal sampling rate is the one you have configured with your [Metric Providers]({{< relref "metric-providers" >}})
   + Also be aware that Intel RAPL has a minimum time resolution of ~10ms and CPU time resolution is typically around 1 microsecond.
 
 ### 4. When running tests your disk load should not go over 50%
 
 - Since typically linux systems can run in congestion above 60% and also our tool needs some disk time.
   + Check `iostat -xmdz` if in doubt
 
-### 5. Limit amount and resolution of Metric Providers to what you absolutely need
+### 5. Limit amount and sampling rate of Metric Providers to what you absolutely need
 
-- Do not exceed 10 Metric Reporters on 100 ms resolution,
-- or 2 metric reporters on 10 ms resolution as this will produce a non-significant load on the system and might skew results.
-- Try to keep the resolution of all metric reporters identical. This allows for easier data drill-down later.
+- Do not exceed 10 Metric Reporters on 100 ms sampling rate,
+- or 2 metric reporters on 10 ms sampling rate as this will produce a non-significant load on the system and might skew results.
+- Try to keep the sampling rate of all metric reporters identical. This allows for easier data drill-down later.
 
 ### 6. Always check STDDEV
 
@@ -137,7 +137,7 @@ rather run `docker volume prune` once in a while.
 
 ### 15. Use non standard sampling intervals and avoid undersampling
 If the effect you are looking for in your code is likely only a 200 ms activity you should at least
-use a sampling rate (metric provider resolution) of 100 ms. 
+use a sampling rate of 100 ms.
 
 Having said that: It is also good practice to use an odd number here, which is slightly lower. For instance 99 ms or even 95 ms. 
 
diff --git a/content/en/docs/measuring/configuration.md b/content/en/docs/measuring/configuration.md
@@ -80,13 +80,13 @@ measurement:
   metric-providers:
     linux:
       cpu.utilization.cgroup.container.provider.CpuUtilizationCgroupContainerProvider:
-        resolution: 100
+        sampling_rate: 100
       cpu.energy.RAPL.MSR.system.provider.CpuEnergyRaplMsrSystemProvider:
-        resolution: 100
+        sampling_rate: 100
       memory.total.cgroup.container.provider.MemoryTotalCgroupContainerProvider:
-        resolution: 100
+        sampling_rate: 100
       cpu.time.cgroup.container.provider.CpuTimeCgroupContainerProvider:
-        resolution: 100
+        sampling_rate: 100
     # ...
 
 admin:
@@ -129,7 +129,7 @@ For the rest please see [installation →]({{< relref "/docs/cluster/installatio
 - `metric-providers`:
   + `linux`/`macos`/`common` **[string]**: Specifies under what system the metric provider can run. Common implies it could run on either.
     * `METRIC_PROVIDER_NAME` **[string]**: Key specifies the Metric Provider. [Possible Metric Providers →]({{< relref "/docs/measuring/metric-providers/metric-providers-overview" >}})
-    * `METRIC_PROVIDER_NAME.resolution` **[integer]**: sampling resolution in ms
+    * `METRIC_PROVIDER_NAME.sampling_rate` **[integer]**: sampling rate in ms
 
 Some metric providers have unique configuration params:
 
diff --git a/content/en/docs/measuring/measurement-cluster.md b/content/en/docs/measuring/measurement-cluster.md
@@ -51,7 +51,7 @@ We have the following machines available for running measurements in our cluster
 ---
 
 - **Micro Benchmarking (DVFS OFF, TB OFF, HT OFF) - TX1330 M2**
-    + Use Case: For micro benchmarking of a software where configuration is tuned for reproducability. Reporters are set to 1ms resolution and limited to RAPL CPU / Memory
+    + Use Case: For micro benchmarking of a software where configuration is tuned for reproducability. Reporters are set to 1ms sampling_rate and limited to RAPL CPU / Memory
     + Vendor: Fujitsu TX1330 M2
     + Ubuntu 22.04 ([NOP Linux](https://www.green-coding.io/blog/nop-linux/))
     + Type: Single-Tenant Server 
diff --git a/content/en/docs/measuring/metric-providers/cpu-energy-RAPL-MSR-component.md b/content/en/docs/measuring/metric-providers/cpu-energy-RAPL-MSR-component.md
@@ -27,8 +27,8 @@ sudo modprobe rapl
 
 ### Technical specs
 
-- Time resolution: 976 micro-seconds
-- Energy resolution: 15.3 micro-Joules
+- Time resolution: up to 976 micro-seconds (depending on production year of the CPU)
+- Energy resolution: up to 15.3 micro-Joules (depending on production year of the CPU)
 
 ### Classname
 
diff --git a/content/en/docs/measuring/metric-providers/lm-sensors.md b/content/en/docs/measuring/metric-providers/lm-sensors.md
@@ -64,7 +64,7 @@ Your config could be:
 
 ```bash
 lmsensors.temperature.provider.LmsensorsTempComponentProvider:
-    resolution: 100
+    sampling_rate: 100
     chips: ['coretemp-isa-0000']
     features: ['Package id 0', 'Core 0', 'Core 1', 'Core 2', 'Core 3']
 ```
diff --git a/content/en/docs/measuring/metric-providers/memory-energy-RAPL-MSR-component.md b/content/en/docs/measuring/metric-providers/memory-energy-RAPL-MSR-component.md
@@ -28,8 +28,8 @@ sudo modprobe rapl
 
 ### Technical specs
 
-- Time resolution: 976 micro-seconds
-- Energy resolution: 15.3 micro-Joules
+- Time resolution: up to 976 micro-seconds (depending on production year of the CPU)
+- Energy resolution: up to 15.3 micro-Joules (depending on production year of the CPU)
 
 ### Classname
 
diff --git a/content/en/docs/measuring/metric-providers/metric-providers-overview.md b/content/en/docs/measuring/metric-providers/metric-providers-overview.md
@@ -38,11 +38,11 @@ measurement:
   metric-providers:
     linux:
       cpu.utilization.cgroup.container.provider.CpuUtilizationCgroupContainerProvider:
-        resolution: 100
+        sampling_rate: 100
       cpu.energy.RAPL.MSR.system.provider.CpuEnergyRaplMsrSystemProvider:
-        resolution: 100
+        sampling_rate: 100
 #      psu.energy.ac.xgboost.system.provider.PsuEnergyAcXgboostSystemProvider:
-#        resolution: 100
+#        sampling_rate: 100
          # This is a default configuration. Please change this to your system!
 #        CPUChips: 1
 #        HW_CPUFreq: 3100
@@ -51,7 +51,7 @@ measurement:
 #        HW_MemAmountGB: 16
 ```
 
-The dimension of the resolution is milliseconds. Change this number to have a smaller or larger time window between measurements for that specific provider.
+The dimension of the sampling_rate is milliseconds. Change this number to have a smaller or larger time window between measurements for that specific provider.
 
 The metric providers are written as C programs with a Python wrapper, and live under `metric_providers/` in the subdirectory that matches the `config.yml`. The directory contains the following files:
 
diff --git a/content/en/docs/measuring/metric-providers/overhead-of-measurement-providers.md b/content/en/docs/measuring/metric-providers/overhead-of-measurement-providers.md
@@ -36,14 +36,14 @@ The script produces a lot of output, but what you want to look out for is:
 ## Results for Esprimo P956 - Measurement #1 Machine Power
 
 Configured reporters
-- PsuEnergyAcMCPMachineProvider: 99 ms resolution
-- NetworkIoCgroupContainerProvider: 99 ms resolution
-- CpuEnergyRaplMsrComponentProvider: 99 ms resolution
-- MemoryEnergyRaplMsrComponentProvider: 99 ms resolution
-- CpuUtilizationProcfsSystemProvider: 99 ms resolution
-- MemoryTotalCgroupContainerProvider: 99 ms resolution
-- CpuUtilizationCgroupContainerProvider: 99 ms resolution
-- LmsensorsTemperatureComponentProvider: 99 ms resolution
+- PsuEnergyAcMCPMachineProvider: 99 ms sampling_rate
+- NetworkIoCgroupContainerProvider: 99 ms sampling_rate
+- CpuEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- MemoryEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- CpuUtilizationProcfsSystemProvider: 99 ms sampling_rate
+- MemoryTotalCgroupContainerProvider: 99 ms sampling_rate
+- CpuUtilizationCgroupContainerProvider: 99 ms sampling_rate
+- LmsensorsTemperatureComponentProvider: 99 ms sampling_rate
 
 ```console
 [INFO] 2024-02-16 10:56:49,208 - System Baseline measurement successful
@@ -91,13 +91,13 @@ Read on for the CPU only values, which give some more insights, but are less gen
 ## Results for Esprimo P956 - Measurement #2 CPU Energy
 
 Configured reporters
-- NetworkIoCgroupContainerProvider: 99 ms resolution
-- CpuEnergyRaplMsrComponentProvider: 99 ms resolution
-- MemoryEnergyRaplMsrComponentProvider: 99 ms resolution
-- CpuUtilizationProcfsSystemProvider: 99 ms resolution
-- MemoryTotalCgroupContainerProvider: 99 ms resolution
-- CpuUtilizationCgroupContainerProvider: 99 ms resolution
-- LmsensorsTemperatureComponentProvider: 99 ms resolution
+- NetworkIoCgroupContainerProvider: 99 ms sampling_rate
+- CpuEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- MemoryEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- CpuUtilizationProcfsSystemProvider: 99 ms sampling_rate
+- MemoryTotalCgroupContainerProvider: 99 ms sampling_rate
+- CpuUtilizationCgroupContainerProvider: 99 ms sampling_rate
+- LmsensorsTemperatureComponentProvider: 99 ms sampling_rate
 
 ```console
 [INFO] 2024-02-16 12:08:32,652 - System Baseline measurement successful
@@ -140,14 +140,14 @@ Configured reporters
 ## Fujitsu TX1330 M2 - Measurement #1 Machine Power
 
 Configured reporters
-- PsuEnergyAcMCPMachineProvider: 99 ms resolution
-- NetworkIoCgroupContainerProvider: 99 ms resolution
-- CpuEnergyRaplMsrComponentProvider: 99 ms resolution
-- MemoryEnergyRaplMsrComponentProvider: 99 ms resolution
-- CpuUtilizationProcfsSystemProvider: 99 ms resolution
-- MemoryTotalCgroupContainerProvider: 99 ms resolution
-- CpuUtilizationCgroupContainerProvider: 99 ms resolution
-- LmsensorsTemperatureComponentProvider: 99 ms resolution
+- PsuEnergyAcMCPMachineProvider: 99 ms sampling_rate
+- NetworkIoCgroupContainerProvider: 99 ms sampling_rate
+- CpuEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- MemoryEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- CpuUtilizationProcfsSystemProvider: 99 ms sampling_rate
+- MemoryTotalCgroupContainerProvider: 99 ms sampling_rate
+- CpuUtilizationCgroupContainerProvider: 99 ms sampling_rate
+- LmsensorsTemperatureComponentProvider: 99 ms sampling_rate
 
 ```console
 [INFO] 2024-02-16 10:13:26,496 - System Baseline measurement successful
@@ -190,13 +190,13 @@ The nature of a switching power supply is that the machine power, when polled in
 ## Fujitsu TX1330 M2 - Measurement #2 CPU Power
 
 Configured reporters
-- NetworkIoCgroupContainerProvider: 99 ms resolution
-- CpuEnergyRaplMsrComponentProvider: 99 ms resolution
-- MemoryEnergyRaplMsrComponentProvider: 99 ms resolution
-- CpuUtilizationProcfsSystemProvider: 99 ms resolution
-- MemoryTotalCgroupContainerProvider: 99 ms resolution
-- CpuUtilizationCgroupContainerProvider: 99 ms resolution
-- LmsensorsTemperatureComponentProvider: 99 ms resolution
+- NetworkIoCgroupContainerProvider: 99 ms sampling_rate
+- CpuEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- MemoryEnergyRaplMsrComponentProvider: 99 ms sampling_rate
+- CpuUtilizationProcfsSystemProvider: 99 ms sampling_rate
+- MemoryTotalCgroupContainerProvider: 99 ms sampling_rate
+- CpuUtilizationCgroupContainerProvider: 99 ms sampling_rate
+- LmsensorsTemperatureComponentProvider: 99 ms sampling_rate
 
 ```console
 [INFO] 2024-02-16 12:26:02,660 - System Baseline measurement successful
diff --git a/content/en/docs/measuring/metric-providers/psu-energy-dc-picolog-machine.md b/content/en/docs/measuring/metric-providers/psu-energy-dc-picolog-machine.md
@@ -73,7 +73,7 @@ The provider will configure the PicoLog HRDL ADC-24 into streaming mode with
 By default the measurement interval is *1000 ms*, which however is only for testing
 purposes.
 
-As stated in the paragraph before the provider should always be used with *61 ms* samling frequency
+As stated in the paragraph before the provider should always be used with *61 ms* sampling rate
 
 ```bash
 ./metric-provider-binary -i 61
@@ -103,7 +103,7 @@ The provider has a significant energy overhead when used as it draws power
 from the USB port of the system.
 
 In our test system the PicoLog HRDL ADC-24 draws about **0.5 W on Stand-By** and
-about **6 W when used with a 61 ms capture resolution**.
+about **6 W when used with a 61 ms sampling rate**.
 
 If you are using a AC reporter in conjuction this will heavily skew your signal.
 Please either use only an AC or DC reporter, or correct the output data
diff --git a/content/en/docs/measuring/metric-providers/psu-energy-dc-rapl-msr-machine.md b/content/en/docs/measuring/metric-providers/psu-energy-dc-rapl-msr-machine.md
@@ -31,8 +31,8 @@ sudo modprobe rapl
 
 ### Technical specs
 
-- Time resolution: 976 micro-seconds
-- Energy resolution: 15.3 micro-Joules
+- Time resolution: up to 976 micro-seconds (depending on production year of the CPU)
+- Energy resolution: up to 15.3 micro-Joules (depending on production year of the CPU)
 
 ### Classname
 
