# Flexibility in Data-Centers for Digital Soberness

Alexis Detroyat

► To cite this version:

Alexis Detroyat. Flexibility in Data-Centers for Digital Soberness. Distributed, Parallel, and Cluster Computing [cs.DC]. 2025. hal-05214822

HAL Id: hal-05214822

https://inria.hal.science/hal-05214822v1

Submitted on 19 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Flexibility in Data-Centers for Digital Soberness

DETROYAT Alexis

Université Grenoble-Alpes - IM²AG

Saint-Martin-d'Hères, France

Alexis.Detroyat@etu.univ-grenoble-alpes.fr

Supervised by: Raphaël BLEUSE and Clément MOMMESSIN (Ctrl-A team)

I understand what plagiarism entails and I declare that this report
is my own, original work.

Name, date and signature: DETROYAT Alexis, 05/06/25

## Abstract

This work focuses on adapting the behavior of datacenter infrastructures to various power constraints imposed by the French electricity transmission company RTE. Within the Ctrl-A team, potential models that could correlate the power cap applied to a distributed infrastructure and the run-time of jobs executed on that infrastructure are investigated, with the far-end aim of improving the widespread backfilling algorithms. The conducted experiments involve the Grid5000 platform, Intel's RAPL feature, and NASA's parallel benchmarks. Results suggest that a general pattern between power caps and run-times can be extrapolated for all workload profiles, which should help predict jobs' run-times under power constraints.

# 1 Introduction

## 1.1 Context

Nowadays, many Information Technology (IT) services require huge amounts of resources. On the one hand, Cloud platforms are the core of distributed systems, which allow users to get access to all sorts of remote services, including music, videos, games and storage supplies from all over the world. On the other hand, High-Performance Computing (HPC) relies on supercomputers to monitor large-scale calculations, in order to conduct scientific research, render visual effects in movies, train Artificial Intelligence models, and forecast weather.

Both Cloud and HPC services have common roots: datacenters, huge IT infrastructures with a lot of hardware components connected together, that are used to store and manage data at a very large scale. Considering the ever-ending rise of the amount of data to be processed, as well as the overall increasing complexity of problems, datacenters are often subject to heavy workloads. Consequently, they are becoming more and more energy-consuming, which represents a challenge for electricity suppliers, especially since the said suppliers already mostly rely on fossil energy sources. According

to the International Energy Agency (IEA) [IEA, 2024], the biggest datacenters consume as much power as 350 000 to 450 000 electric cars every year.

## 1.2 Related work

Several tools already exist to tackle this energy consumption threat at various operation levels. First, the growth of autonomic computing [Kephart and Chess, 2003] led to the development of self-adaptive systems in the 2000s, able to monitor themselves based on high-level objectives such as power or frequency constraints. Then, as the climate emergency has progressively spread through people's minds in recent years, multiple research works have been conducted with eco-friendly objectives in mind. Namely, the DATAZERO project [Pierson et al., 2019] aimed to design environmentally friendly datacenters by providing only renewable electricity sources, and forcing cooperation between IT workload and power supply modules.

Alternatively, Carastan-Santos et al. [Carastan-Santos et al., 2024] focused on the IT side, by developing a history-based method to predict workloads' power consumption in HPC platforms and schedule jobs accordingly. This work also modeled the problem of scheduling under power constraints (usually called power caps) as a greedy knapsack algorithm, which has proven to be efficient. Indeed, this knapsack algorithm has led to overall lower turnaround times (time taken to fulfill a job) without starving longer jobs (that is, without depriving them of resources).

As a rule of thumb, scheduling algorithms are a key concept when it comes to efficiently assigning resources to run tasks. In particular, the backfilling method and its conservative variant discussed by Feitelson and Weil [Feitelson and Weil, 1998] offer great opportunities for optimizing energy consumption, because these algorithms allow scheduling new jobs before others, as long as they do not delay the first job in the waiting queue (or every waiting job, in the case of the conservative variant). Such algorithms reduce fragmentation in job scheduling, leading to shorter execution times and a more equitable workload distribution between processors. Much remains to be done if we want to drastically reduce the fossil energy consumption of datacenters while maintaining a high quality of service for users, and enhancing backfilling could be one of the easiest and most efficient ways to achieve this goal, considering how widespread these algorithms are in cur-
rent HPC platforms.

## 1.3 Objectives

The main interest of this research internship is to develop flexibility in datacenters. That is, to find a balance between energy network capacity variations and regulation of computing activity in datacenters, in the context of a collaboration with RTE, the French company which is responsible for electricity transmission throughout the French power grid. A relevant example is the power cuts planned in winter 2022 due to a record drop in energy production [RTE, 2023]. To that goal, this work focuses on improving backfilling algorithms by applying different power constraints to running jobs, in order to modify their run-time and increase the overall scheduling efficiency, either by lowering the idle time of processing units, or by fitting more jobs in a same time window.

This process can be broken down into two main research questions. First, **how to establish a reliable model that links the power cap imposed on a platform to the run-time of jobs on this platform?** Second, **to what extent can we use such a model to actually improve backfilling algorithms?**

In the context of this report, we will only consider the first one, as the full-time period dedicated to the internship was too short to consider both.

This is a complex topic, since jobs' run-times depend on many parameters, such as the hardware components used in the platform, the amount of compute nodes and CPU cores allocated to them, the voltage provided by the power supply unit, the nature of the job itself, and so on. However, identifying a clear relation between the power constraints applied to a datacenter and the performances of its running jobs is crucial to make backfilling algorithms, thus most schedulers used nowadays, more energy-efficient.

# 2 Software and hardware resources used for running experiments

As mentioned beforehand, the first step of this work consists in running jobs on a large-scale infrastructure under various power constraints. This process requires three elements: an experimental HPC platform, a tool to set power constraints and measure power data, and workloads to be run by jobs on the platform. We describe each of these three elements in the following subsections.

## 2.1 The Grid5000 infrastructure

Grid5000 is a huge experimental platform with large-scale clusters that cover three countries (France, Belgium, and Luxembourg). With a total of 15000 CPU (central processing unit) cores spread across 800 compute nodes, this flexible and reconfigurable infrastructure represents a great testing environment for research in most computation-heavy IT (information technology) fields, according to their wiki homepage [Grid5000-team, 2023]. Since the Ctrl-A team can provide direct and privileged access to the platform, Grid5000 was the most obvious choice to run our experiments.

This testbed is composed of ten clusters in France (Lille, Nancy, Strasbourg, Lyon, Grenoble, Sophia-Antipolis,

Toulouse, Bordeaux, Nantes and Rennes), one cluster in Belgium (Louvain) and one cluster in Luxembourg (in Esch-sur-Alzette). The hardware configuration of each cluster, as well as the hardware components of each compute node within a cluster, can be very different. Namely, only a few clusters are equipped with wattmeters to retrieve power consumption data:

* clusters *yeti*, *troll* and *servan* in Grenoble;

* every cluster except *nova* in Lyon;

* nodes 41 to 76 from the cluster *gros* in Nancy.

This wattmeter limitation already severely restricts the scope of usable clusters in the context of this work. After several tests, the cluster *gros* of Nancy happened to be the most fitting, mainly due to its very large amount of available nodes that allow for running many jobs in parallel, as well as reducing the risks of conflicts between users over the usage of a node.

## 2.2 Intel's Running Average Power Limit (RAPL)

The second key point lies in the choice of a tool to monitor the power consumption of jobs within the infrastructure. Of all the most widespread options, Intel's RAPL appeared to be the most interesting one for two main reasons. On the one hand, RAPL directly manipulates power values (in microwatts) or at least energy values (in microjoules), which makes it easy to use in our context. On the other hand, RAPL is both a sensor and an actuator, that is, it is useful for both measuring power values during jobs' executions, and setting power constraints on the platform. That being said, RAPL has the disadvantage of being exclusive to Intel processors, making it unusable on AMD hardware for instance. This makes for another constraint that we had to take into consideration while selecting our Grid5000 nodes.

RAPL works with two sliding windows that repeatedly compute the average power consumption of the current processing unit: the first window handles long-term average computation (generally one second or more), while the second window handles short-term average computation (generally at the granularity of a millisecond). The first, larger window ensures that the overall power consumption doesn't exceed a certain value, whereas the second, smaller window acts as a regulator at a smaller granularity. Whenever the processing unit is idle, the short-term window builds up potential power, which is then used when there are new tasks to execute. At that point, the short-term window is allowed to temporarily overpass the platform's power constraint until it has spent all of its accumulated potential. See Figure 1 from [Rotem et al., 2012].

### Power capping with RAPL

The most direct way to access RAPL's data is to read the Linux kernel files under `/sys/class/powercap/intel-rapl/`, or to use the `powercap-info` command from the `powercap-utils` package which aggregates RAPL file contents into a well-formatted output, as in Figure 2. There are other options, like the `perf stat` command, but they either add too much overhead to the system, or
<figure><img src="image_2.png" /><figcaption>Figure 1: Dynamic behavior of the Intel Turbo Boost. After a period of low power consumption, the CPU and graphics can burst to very high power and performance for 30 to 60 seconds, delivering a responsive user experience. After this period, the power stabilizes back to the rated Thermal Design Power (TDP) which corresponds to the power cap.</figcaption></figure>

lack flexibility or accuracy compared to reading "raw" RAPL files.

In the typical output of Figure 2 given by the `powercap-info` command on the node 112 of cluster `gros` in Nancy, we can see that the data is organized into indexed zones and constraints. The zones correspond to different regions of the CPU: zones 0, 1, etc. refer to different CPU sockets, whereas zones 0:0, 0:1, etc. refer to different components within the same socket, depending on their names. In this example, we can see that the CPU has a single socket (zone 0 only), with a specific subzone dedicated to its local memory, called DRAM (Dynamic Random Access Memory). For these regions, the field `enabled` indicates whether RAPL's power capping is active (1) or not (0).

The constraints correspond to the sliding windows mentioned above: `Constraint 0`, named `long_term`, is the larger window, while `Constraint 1`, named `short_term`, is the smaller window. We can see for this node that the long-term window lasts approximately one second, whereas the short-term window lasts about two milliseconds (fields `time_windows_us`). For both windows (constraints), the field `power_limit_uw` is the current power cap value in microwatts, and the field `max.power.uw` is the maximum reachable power for this node in microwatts. At the moment of the screenshot, the node `gros-112` had a long-term window capped at 125W, which is its maximum power; its short-term window was capped at 150W out of its maximum power of 307W. Therefore, the field `power_limit.uw` is the most interesting in our case to set a power cap value. This operation can be done more easily through the command `powercap-set`.

## Measuring power data with RAPL

Unlike the power cap values, the RAPL sensors' data is not always displayed by the `powercap-info` command, as shown by Figure 2. Consequently, we had to read

<figure><img src="image_3.png" /><figcaption>Figure 2: Example of output from `powercap-info` on the node 112 of cluster `gros` in Nancy. Every field in this output corresponds to the content of a file under `/sys/class/powercap/intel-rapl/`.</figcaption></figure>

the energy values located in files named `energy.uj` under `/sys/class/powercap/intel-rapl/`. For instance, the energy counter for the cores of the socket from node `gros-112` in Figure 2 corresponds to the file `/sys/class/powercap/intel-rapl:0/energy.uj`.

In order to convert these energy values (microwatts) into power values $P$ (microwatts), we have to retrieve energy values at two different timestamps, then compute the quotient of the energy difference by the time difference:

$$P = \frac{\Delta energy}{\Delta time}.$$

In Figure 2, the fields named `max.power.uw` correspond to the maximum reachable values for each energy counter. Beyond these values, the energy counters overlap and go back to 0. As a consequence, energy deltas can be erroneous, and one has to consider wraparound-aware logic to account for such cases while computing energy differences.

## 2.3 NASA's parallel benchmarks

Last but not least, experimenting with power caps requires jobs to run. Since we want to cover as many job patterns as possible, these jobs have to be very different from each other: some are computationally heavy (CPU-bound), others mostly rely on input/output buses (I/O-bound), others stress the local and distant storage spaces (memory-bound), etc.

The study of Chapter 8 from Franz Heinrich's thesis [Heinrich, 2019] about CPU power consumption measurements led us to the choice of the NAS (NASA's Advanced Supercomputing division) parallel benchmarks [NAS, 2024]. Those are programs aimed at assessing the performance of parallel
supercomputers by executing different workflows. Among them, some are CPU-bound (Embarrassingly Parallel, EP), others are memory-bound (Integer Sort, IS and Conjugate Gradient, CG), others are I/O-bound (Data Cube, DC) but most of them have multiple bottlenecks.

The NAS benchmarks have to be manually imported and compiled on local compute nodes in order to be run. Moreover, users have to provide the size of the problem instances to run a benchmark, called a class. There are eight different classes.

* Class S, which is the smallest possible class, usually used for quick testing purposes.

* Class W, which corresponds to the size of a workstation from the 1990's.

* Classes A, B which were designed for medium-sized clusters (about 4 to 32 cores).

* Classes C, D which were made for large-sized clusters (up to one hundred cores).

* Classes E, F which correspond to the largest supercomputers (thousands of cores).

# 3 Drawing a parallel between power constraints and execution times

## 3.1 Experimental power capping and measurement protocol

In order to set up the NAS benchmarks, set the power caps, run the jobs and collect the run-time and power measurements, the NAS benchmarks had to be installed first. They were imported to the distant home directory of the Nancy cluster through SSH connection, then compiled on one of the nodes from cluster gros so that the compiler was able to optimize the code according to the nodes' hardware. Since the Grid5000 file system is common to the whole cluster, this compilation step doesn't need to be repeated for each different node, as long as we keep working on the Nancy infrastructure.

Then, the following protocol was executed by running a launch bash script from the Nancy site frontend. Those steps, on the other hand, must be replicated for each new experiment.

1. A request was made to the scheduler to allocate a fitting node for the experiment, that is, a node with an Intel CPU (for RAPL) and a wattmeter (for power measurements). The executed launch script asks for a NAS benchmark to run, the size (class) of this benchmark, the number of processes to run (that is, the number of CPU cores to use), the interface to choose (between MPI for Message Passing Interface or OpenMP), and the power cap value to apply to the node.

2. In this request, a second script was passed as a command-line argument to be executed inside the allocated node. This other script, which we call the run script, is responsible for three tasks. First, it sets up the environment within the allocated node, by installing

<figure><img src="image_4.png" /><figcaption>Figure 3: Sketch of the experimental power cap and measurement protocol</figcaption></figure>

the power capping utility `powercap-utils` then setting the power cap according to the user's value. Second, it calls a logger script in the background which reads RAPL's energy values then computes the power consumption of the node every second, and stores its results in a log file. Third, it runs the requested workload 5 times in a row while the logger is active. The timestamps before and after each run are registered using GNU `date`, so that each run time is also written into the log file. Eventually, the duration of the complete workload (from the beginning of the first run to the end of the fifth run) is added into the log file.

3. Once the launch script has requested a node to the scheduler with the run script as an argument, it repeatedly checks the status of the corresponding job until it is finished. Then, the launch script calls a third script, which we call the result script. This third script retrieves the start and end dates of execution from the Grid5000 API to display the total job makespan (including allocation, initialization, execution, termination). Then, the result script reads the log file created by the run script to compute statistics across all 5 runs of the workload. Eventually, the result script collects wattmeter data from the Grid5000 API in the same time interval as the job makespan, and adds that data to the log file.

The execution of the launch script produces three files: a first one that contains the outputs of the executed job, a second one that contains the potential errors that occurred during the job execution, and a third one which is the log file with power and run-time measurements for each of the five runs, as well as for the whole workload. Figure 3 summarizes the sequence of steps 1, 2 and 3 described above for better understanding.

This experimental protocol was done with the following parameters:

* workloads BT, CG, EP, FT, IS, LU, MG, SP and DT from the NAS benchmarks;
* class A, since classes S and W are too small for a whole compute node, and bigger classes led to very long execution times since each workload is executed five times in a row;

* 18 processes, which is the maximum amount for each node of the cluster gros in Nancy, according to its hardware section on the wiki;

* the MPI interface, which emphasizes communication between processes rather than between threads;

* a set of increasing power cap values, ranging from 10W to 125W, which is the TDP of the chosen cluster's CPU, that is, the maximum reachable power value according to the CPU specification.

## 3.2 Results & Analysis

### Data tables

The log files obtained through the experiments led to two data sets: a first one that links power cap values to the execution times of the workloads, and a second one that draws a parallel between power cap values and actual power measurements from RAPL. Table 1 shows the resulting run-times, and Table 2 highlights the resulting power values measured by RAPL.

A first observation is that when the power cap increased, the run-times of jobs decreased and their maximum power measured by RAPL increased. This is coherent with the fundamental principle of power capping: the more power provided to the platform, the faster the jobs are.

According to Table 1, the lowest run-time gaps were seen when the power cap goes from 100W to 125W. This is not surprising either, because we know that 125W is the TDP of the node's CPU, which means the closer we get to 125W, the smaller the margin for improvement becomes. The highest run-time gaps, on the other hand, occurred between 25 and 30W of power cap: for every workload except FT, the overall run-times were more than halved, with the LU workload's run-time having even been divided by more than five. As such, this 30W threshold looks like an interesting critical point to investigate.

Regarding the RAPL power measurements listed in Table 2, we can see that every workload adapted pretty well to the power constraints, with the maximum power measurements (averaged across all five runs) being very close to the power cap in most cases. Nevertheless, two major exceptions arose, around the minimum power cap value (10W) as well as the maximum power cap value (125W). In the first case, with very low power caps, we notice that RAPL measured maximum power values between 25 and 28W for every benchmark, which represents almost three times more power than what was imposed to the compute node. This seems to illustrate a low threshold effect, possibly meaning that the CPUs have reached the minimum power at which they can operate properly.

Conversely, in the second case, at the highest power cap, only the BT benchmark managed to reach a maximum power consumption that was close to 125W. For every other workload, the maximum power measured by RAPL was much lower than the power cap, with the power consumption of

<table><caption>Table 1: run-time values according to power cap for each workload with class A</caption><caption>Class A - runtimes</caption><thead><tr><th></th><th>BT</th><th>CG</th><th>DT</th><th>EP</th><th>FT</th><th>IS</th><th>LU</th><th>MG</th><th>SP</th></tr><tr><th>power cap (W)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th><th>runtime (s)</th></tr></thead><tbody><tr><td>10</td><td>2109</td><td>280</td><td>223</td><td>384</td><td>307</td><td>268</td><td>1187</td><td>281</td><td>1133</td></tr><tr><td>25</td><td>2077</td><td>171</td><td>156</td><td>308</td><td>202</td><td>190</td><td>996</td><td>167</td><td>1006</td></tr><tr><td>30</td><td>474</td><td>50</td><td>54</td><td>80</td><td>153</td><td>50</td><td>190</td><td>70</td><td>388</td></tr><tr><td>35</td><td>184</td><td>37</td><td>31</td><td>41</td><td>40</td><td>35</td><td>100</td><td>41</td><td>115</td></tr><tr><td>45</td><td>90</td><td>31</td><td>26</td><td>35</td><td>31</td><td>31</td><td>76</td><td>30</td><td>71</td></tr><tr><td>50</td><td>89</td><td>28</td><td>26</td><td>31</td><td>30</td><td>27</td><td>73</td><td>30</td><td>64</td></tr><tr><td>75</td><td>65</td><td>25</td><td>21</td><td>26</td><td>26</td><td>25</td><td>50</td><td>26</td><td>51</td></tr><tr><td>100</td><td>45</td><td>23</td><td>21</td><td>26</td><td>25</td><td>22</td><td>45</td><td>25</td><td>40</td></tr><tr><td>125</td><td>42</td><td>21</td><td>21</td><td>25</td><td>25</td><td>21</td><td>40</td><td>25</td><td>36</td></tr></tbody></table>

<table><caption>Table 2: RAPL maximum power values according to power cap for each workload with class A</caption><caption>Class A - max power measurements</caption><thead><tr><th></th><th>BT</th><th>CG</th><th>DT</th><th>EP</th><th>FT</th><th>IS</th><th>LU</th><th>MG</th><th>SP</th></tr><tr><th>power cap (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th><th>max power (W)</th></tr></thead><tbody><tr><td>10</td><td>25</td><td>26</td><td>25</td><td>27</td><td>27</td><td>27</td><td>24</td><td>27</td><td>28</td></tr><tr><td>25</td><td>27</td><td>26</td><td>28</td><td>29</td><td>28</td><td>28</td><td>27</td><td>25</td><td>29</td></tr><tr><td>30</td><td>28</td><td>29</td><td>32</td><td>32</td><td>37</td><td>33</td><td>33</td><td>35</td><td>37</td></tr><tr><td>35</td><td>33</td><td>34</td><td>33</td><td>36</td><td>37</td><td>34</td><td>37</td><td>40</td><td>39</td></tr><tr><td>45</td><td>42</td><td>42</td><td>42</td><td>44</td><td>43</td><td>43</td><td>44</td><td>45</td><td>45</td></tr><tr><td>50</td><td>47</td><td>47</td><td>47</td><td>49</td><td>48</td><td>47</td><td>50</td><td>47</td><td>50</td></tr><tr><td>75</td><td>68</td><td>71</td><td>63</td><td>70</td><td>71</td><td>70</td><td>70</td><td>73</td><td>73</td></tr><tr><td>100</td><td>94</td><td>77</td><td>63</td><td>81</td><td>84</td><td>69</td><td>80</td><td>84</td><td>95</td></tr><tr><td>125</td><td>118</td><td>83</td><td>68</td><td>84</td><td>81</td><td>75</td><td>97</td><td>84</td><td>108</td></tr></tbody></table>

the DT job being as low as almost half the power cap. This is most likely due to the CPUs not having enough computations to run, or at least not for a time period that is long enough at such high power caps. If we draw a parallel between the last rows of Tables 1 and 2, we can clearly point out a correlation: the only benchmarks that take more than 25 seconds to execute under 125W of power cap (BT, LU, SP) are the exact same benchmarks which consume the most power from what is provided to them.

### Graphs

Figures 4 and 5 show the plotted versions of the previous tables from Tables 1 and 2 respectively, with power cap values on the x-axis and either run-time or RAPL-measured power values on the y-axis. Note that the y-axis scale is logarithmic in Figure 4. Even though the data points are the same, this graph format allows to highlight other trends and patterns that can be harder to see in raw tables.

To start with, Figure 4 blatantly depicts the sharp drop in the run-times of jobs when going from 20 to 40W of power
<figure><img src="image_5.png" /><figcaption>Figure 4: Run-time values according to power cap for each workload with class A</figcaption></figure>

cap, which we already mentioned above. This general behavior suggests that power caps lower than 30W make these jobs run in very degraded states, to the point the benchmarks become very slow to run. What is even more interesting in this graph is that all workloads follow the same run-time pattern when the power cap increases, since the curves are almost “parallel”. As a result, elaborating a general power cap to run-time model seems feasible, and one could simply adjust the starting point with an offset depending on the nature of the job to run.

Talking about the nature of jobs, three main job groups are distinguishable from this graph at low power cap, even more so if we consider the original, non-logarithmic scale which heavily reinforces the spacing between curves. At 10W of power cap, the BT benchmark is by far the longest to run. Then come the SP and LU benchmarks together, and finally all the other benchmarks constitute a third, lower run-time group. This ranking corresponds to the amount of simultaneous CPU and communication (MPI) usage: BT (Block Tridiagonal Solver) is the most CPU-bound and communication-bound benchmark at the same time; SP and LU are also solvers, but with simpler equations and less demanding synchronization; all others are either not using communication primitives or are computationally lightweight.

On the other hand, Figure 5 illustrates the low threshold effect mentioned earlier around low power caps, showing that all benchmarks never go below 25W. In high power cap regions, we also notice the dispersion of RAPL-measured power values depending on the benchmarks. Interestingly, the order among the curves is approximately the same between the low power cap region of Figure 4 and the high power cap region of Figure 5, showing that the jobs that suffer the most from heavily power-constrained environments are also the ones who benefit the most from extra power.

# 4 Discussion & Conclusion

In the context of this work, we proposed an experimental protocol that relies on Intel's RAPL mechanism and the Grid5000 distributed infrastructure to run various job profiles from NAS. This led to a first set of results which suggest

<figure><img src="image_6.png" /><figcaption>Figure 5: RAPL maximum power values according to power cap for each workload with class A</figcaption></figure>

that a general model correlating the power cap imposed on a platform and the run-time of jobs on this platform should be exploitable to predict the execution time of any given job, according to its properties. This is an encouraging outcome which we will have to investigate in further details, in order to be able to develop such a model with the goal of enhancing backfilling algorithms in mind.

That being said, the aforementioned results are not to be taken as a general truth, especially considering that the data obtained in this article come from experiments that were carried out in very specific circumstances. Namely, the protocol explained earlier was only deployed for benchmarks of class A, on single nodes, using the MPI interface exclusively, and on Intel CPUs only, since hardware from other manufacturers generally does not support RAPL.

As a consequence, there is still a lot of testing to be done. In the time that remains until the end of July, we will perform deeper testbenches by successively moving cursors one by one, from the most simple to the most complex parameters: starting with bigger benchmark classes such as B or C, we will then assess the impact of using the OpenMP interface, before trying to design new protocols aimed at multi-nodes monitoring, and an AMD hardware alternative if time permits.

Alternatively, we could study the effects of various power caps on RAPL's short-term window only, to assess the importance of this window in energy consumption monitoring. Other energy monitoring tools, such as Dynamic Frequency and Voltage Scaling (DVFS) may also be considered for comparison with RAPL modules.

Ultimately, the objective remains to improve backfilling thanks to the newly acquired knowledge from this study. Beyond playing with jobs' run-times through the application of well-chosen power cap values, the main challenge will lie in designing a new backfilling-based algorithm that shows better efficiency while avoiding classic scheduling pitfalls, such as the starvation of long jobs. The knapsack modeling under power constraints from Carastan-Santos et al. [Carastan-Santos et al., 2024] could make for a good starting point, but we will undoubtedly have to consider deeper algorithmic concepts in order to find a satisfying solution, if one exists.
References

[Carastan-Santos et al., 2024] Danilo Carastan-Santos, Georges da Costa, Igor Fontana de Nardin, Millian Poquet, Krzysztof Rzadca, Patricia Stolf, and Denis Trystram. Scheduling with lightweight predictions in power-constrained HPC platforms. working paper or preprint, October 2024.

[Feitelson and Weil, 1998] D.G. Feitelson and A.M. Weil. Utilization and predictability in scheduling the ibm sp2 with backfilling. In *Proceedings of the First Merged International Parallel Processing Symposium and Symposium on Parallel and Distributed Processing*, pages 542–546, 1998.

[Grid5000-team, 2023] Grid5000-team. Grid5000:Home. https://www.grid5000.fr/w/Grid5000:Home, 2023.

[Heinrich, 2019] Franz Heinrich. *Modeling, Prediction and Optimization of Energy Consumption of MPI Applications using SimGrid*. Theses, Université Grenoble Alpes, May 2019.

[IEA, 2024] IEA. What the data centre and AI boom could mean for the energy sector. https://www.iea.org/commentaries/what-the-data-centre-and-ai-boom-could-mean-for-the-energy-sector/, 2024.

[Kephart and Chess, 2003] J.O. Kephart and D.M. Chess. The vision of autonomic computing. *Computer*, 36(1):41–50, 2003.

[NAS, 2024] NAS. NAS Parallel Benchmarks. https://www.nas.nasa.gov/software/npb.html, 2024.

[Pierson et al., 2019] Jean-Marc Pierson, Gwilherm Baudic, Stéphane Caux, Berk Celik, Georges Da Costa, Léo Grange, Marwa Haddad, Jérôme Lecuivre, Jean-Marc Nicod, Laurent Philippe, Veronika Rehn-Sonigo, Robin Roche, Gustavo Rostirolla, Amal Sayah, Patricia Stolf, Minh-Thuyen Thi, and Christophe Varnier. Datazero: Datacenter with zero emission and robust management using renewable energy. *IEEE Access*, 7:103209–103230, 2019.

[Rotem et al., 2012] Efraim Rotem, Alon Naveh, Avinash Ananthakrishnan, Eliezer Weissmann, and Doron Rajwan. Power-management architecture of the intel microarchitecture code-named sandy bridge. *IEEE Micro*, 32(2):20–27, 2012.

[RTE, 2023] RTE. FRANCE 2022 ELECTRICITY REVIEW. https://assets.rte-france.com/analyse-et-donnees/2023-08/Bilan%20C3%A9lectrique%202022%20synth%C3%A8se%20GB_version_finale%20(1).pdf, 2023.