# Adaptive control of HPC clusters for server overload avoidance

Rosa Pagano

<figure><img src="image_1.png" /></figure>

## To cite this version:

Rosa Pagano. Adaptive control of HPC clusters for server overload avoidance. Distributed, Parallel, and Cluster Computing [cs.DC]. 2023. hal-04390558

HAL Id: hal-04390558

https://inria.hal.science/hal-04390558

Submitted on 12 Jan 2024

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_2.png" /></figure>
# Adaptive control of HPC clusters for server overload avoidance

Rosa Pagano

<figure><img src="image_1.png" /></figure>

## To cite this version:

Rosa Pagano. Adaptive control of HPC clusters for server overload avoidance. Distributed, Parallel, and Cluster Computing [cs.DC]. 2023. hal-04390558

HAL Id: hal-04390558

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

Submitted on 12 Jan 2024

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_2.png" /></figure>
<figure><img src="image_3.png" /></figure>

**POLITECNICO**
MILANO 1863

SCUOLA DI INGEGNERIA INDUSTRIALE
E DELL'INFORMAZIONE

# Adaptive control of HPC clusters for server overload avoidance

TESI DI LAUREA MAGISTRALE IN
AUTOMATION AND CONTROL ENGINEERING - INGEGNERIA
AUTOMAZIONE E CONTROLLO

Author: **Rosa Pagano**

Student ID: 10629478

Advisor: Prof. Alberto Leva

Co-advisors: Bogdan Robu, Eric Rutten

Academic Year: 2022-23
<figure><img src="image_3.png" /></figure>

**POLITECNICO**
MILANO 1863

SCUOLA DI INGEGNERIA INDUSTRIALE
E DELL'INFORMAZIONE

# Adaptive control of HPC clusters for server overload avoidance

TESI DI LAUREA MAGISTRALE IN
AUTOMATION AND CONTROL ENGINEERING - INGEGNERIA
AUTOMAZIONE E CONTROLLO

Author: **Rosa Pagano**

Student ID: 10629478

Advisor: Prof. Alberto Leva

Co-advisors: Bogdan Robu, Eric Rutten

Academic Year: 2022-23
<figure><img src="image_4.png" /></figure>
<figure><img src="image_4.png" /></figure>
Abstract

This thesis focuses on the maximal usage of an High-Performance Computing (HPC) Cluster with particular attention to the overloading of the storage, namely the file server. HPCs have become important in the scientific domain because of their computational power which allows calculation that otherwise would be impossible with a single computer. On the other hand, this powered structure has a considerable cost, and unfortunately also a short life cycle. As a consequence, it becomes important to use as best as possible all the resources that this new structure gives. In this context, Autonomic Computing and the collaboration between control theory and computer science were born.

This Mater Thesis continues a broader project where a PI controller was designed for an HPC Cluster. The aim of the controller is the minimization of idle resources inside the cluster. However, the controller is built on a model in a nominal configuration which leads to heterogeneous results for different working conditions. Moreover, conditions far from the nominal one bring the file server close to the overloading which is a challenging condition for the system.

The idea of this project is to design an identification algorithm in order to end up with an Adaptive PI that changes its own parameters to achieve specification with various working conditions. We design three different algorithms that are going to be tested in a simulation environment (SIMULINK) and then only one will be carried to the real set-up. In the end, there is a comparison between the PI and the Adaptive PI. Here it is shown how the Adaptive PI has a more homogeneous result than the case of the simple PI and how the overloading of the file server is avoided. However, the drawback is the settling time which becomes larger than in the case of classic PI.

**Keywords:** HPC, File server, Adaptive, Algorithm
Abstract

This thesis focuses on the maximal usage of an High-Performance Computing (HPC) Cluster with particular attention to the overloading of the storage, namely the file server. HPCs have become important in the scientific domain because of their computational power which allows calculation that otherwise would be impossible with a single computer. On the other hand, this powered structure has a considerable cost, and unfortunately also a short life cycle. As a consequence, it becomes important to use as best as possible all the resources that this new structure gives. In this context, Autonomic Computing and the collaboration between control theory and computer science were born.

This Mater Thesis continues a broader project where a PI controller was designed for an HPC Cluster. The aim of the controller is the minimization of idle resources inside the cluster. However, the controller is built on a model in a nominal configuration which leads to heterogeneous results for different working conditions. Moreover, conditions far from the nominal one bring the file server close to the overloading which is a challenging condition for the system.

The idea of this project is to design an identification algorithm in order to end up with an Adaptive PI that changes its own parameters to achieve specification with various working conditions. We design three different algorithms that are going to be tested in a simulation environment (SIMULINK) and then only one will be carried to the real set-up. In the end, there is a comparison between the PI and the Adaptive PI. Here it is shown how the Adaptive PI has a more homogeneous result than the case of the simple PI and how the overloading of the file server is avoided. However, the drawback is the settling time which becomes larger than in the case of classic PI.

**Keywords:** HPC, File server, Adaptive, Algorithm
<figure><img src="image_5.png" /></figure>
<figure><img src="image_5.png" /></figure>
Abstract in lingua italiana

Questa tesi si focalizza nell'usare al meglio le risorse di un High-Performance Computing (HPC) con un accento sul sovraccarico della memoria esterna.

Gli HPC sono diventati fondamentali nell'ambito scientifico per la loro potenza computazionale che sorpassa ogni limite prescritto dal singolo computer. Data la loro importanza e potenza, queste strutture vengono ad un costo non ignorabile e, sfortunatamente, anche ad un ciclo di vita relativamente breve. Di conseguenza, diventa molto importante sfruttare al meglio tutte le risorse di un HPC durante il suo ciclo vitale. Proprio in questo contesto nasce l'Autonomic computing che da' inizio alla cooperazione tra esperti di informatica e controllo.

Questa Tesi Magistrale è solo una parte di un progetto più ampio. Infatti, nel lavoro precedente, si è costruito un PI in modo da minimizzare le risorse inutilizzate in un HPC Cluster. Però, il controllore è stato disegnato su un modello specifico per una condizione di lavoro, che verrà chiamata nominale. Quindi, il sistema finale presentava diverse etereogeneità rispetto le diverse condizioni di lavoro. In più, situazioni lontane da quella nominale portavano quasi al sovraccarico della memoria esterna, una condizione da evitare assolutamente.

L'idea di questo progetto è di affiancare al precedente controllo un algoritmo di identificazione, in modo tale da avere un controllore che cambi i propri parametri per soddisfare sempre le specifiche in qualsiasi quadro lavorativo. In questo lavoro vengono discussi e testati in ambiente simulativo (SIMULINK) tre algoritmi diversi. Poi vengono mostrati anche gli esperimenti sulla vera struttura, ma qui viene testato solo uno dei tre algoritmi. Alla fine, c'è un confronto tra il PI e il PI Adattivo. In questa parte è possibile vedere come i risultati del nuovo controllore sono più omogenei rispetto ai precedenti e come il sovraccarico viene evitato. Però, il nuovo sistema tende ad essere più lento del precedente.

**Parole chiave:** HPC, memoria esterna, Adattivo, Algoritmi
Abstract in lingua italiana

Questa tesi si focalizza nell'usare al meglio le risorse di un High-Performance Computing (HPC) con un accento sul sovraccarico della memoria esterna.

Gli HPC sono diventati fondamentali nell'ambito scientifico per la loro potenza computazionale che sorpassa ogni limite prescritto dal singolo computer. Data la loro importanza e potenza, queste strutture vengono ad un costo non ignorabile e, sfortunatamente, anche ad un ciclo di vita relativamente breve. Di conseguenza, diventa molto importante sfruttare al meglio tutte le risorse di un HPC durante il suo ciclo vitale. Proprio in questo contesto nasce l'Autonomic computing che da' inizio alla cooperazione tra esperti di informatica e controllo.

Questa Tesi Magistrale è solo una parte di un progetto più ampio. Infatti, nel lavoro precedente, si è costruito un PI in modo da minimizzare le risorse inutilizzate in un HPC Cluster. Però, il controllore è stato disegnato su un modello specifico per una condizione di lavoro, che verrà chiamata nominale. Quindi, il sistema finale presentava diverse etereogeneità rispetto le diverse condizioni di lavoro. In più, situazioni lontane da quella nominale portavano quasi al sovraccarico della memoria esterna, una condizione da evitare assolutamente.

L'idea di questo progetto è di affiancare al precedente controllo un algoritmo di identificazione, in modo tale da avere un controllore che cambi i propri parametri per soddisfare sempre le specifiche in qualsiasi quadro lavorativo. In questo lavoro vengono discussi e testati in ambiente simulativo (SIMULINK) tre algoritmi diversi. Poi vengono mostrati anche gli esperimenti sulla vera struttura, ma qui viene testato solo uno dei tre algoritmi. Alla fine, c'è un confronto tra il PI e il PI Adattivo. In questa parte è possibile vedere come i risultati del nuovo controllore sono più omogenei rispetto ai precedenti e come il sovraccarico viene evitato. Però, il nuovo sistema tende ad essere più lento del precedente.

**Parole chiave:** HPC, memoria esterna, Adattivo, Algoritmi
<figure><img src="image_6.png" /></figure>
<figure><img src="image_6.png" /></figure>
# Contents

<table><tr><td>Abstract</td><td>i</td></tr><tr><td>Abstract in lingua italiana</td><td>iii</td></tr><tr><td>Contents</td><td>v</td></tr><tr><td>Introduction</td><td>1</td></tr><tr><td>0.1 Organization of the thesis</td><td>2</td></tr><tr><td>1 State of the Art</td><td>3</td></tr><tr><td>1.1 High-Performance Computing: an overview</td><td>3</td></tr><tr><td>1.2 HPC Cluster</td><td>5</td></tr><tr><td>1.2.1 Job Scheduling</td><td>6</td></tr><tr><td>1.2.2 File System</td><td>7</td></tr><tr><td>1.3 HPC Grid</td><td>8</td></tr><tr><td>1.4 Autonomic Computing</td><td>9</td></tr><tr><td>1.5 Dynamic HPC management using Control Theory</td><td>12</td></tr><tr><td>1.5.1 Assets of control theory for computing system</td><td>12</td></tr><tr><td>1.5.2 Challenges</td><td>13</td></tr><tr><td>1.5.3 Literature overview</td><td>14</td></tr><tr><td>2 System description</td><td>17</td></tr><tr><td>2.0.1 The Experimental Infrastructure: Grid5000</td><td>17</td></tr><tr><td>2.1 Single Cluster Components</td><td>18</td></tr><tr><td>2.1.1 Controller CIGRI</td><td>19</td></tr><tr><td>2.1.2 Priorities inside the OAR scheduler</td><td>20</td></tr><tr><td>2.1.3 Overview of the System's Description</td><td>22</td></tr><tr><td>2.2 Prior work: a PI controller</td><td>24</td></tr><tr><td>2.2.1 Model of File System</td><td>25</td></tr></table>
# Contents

Abstract i

Abstract in lingua italiana iii

Contents v

Introduction 1

0.1 Organization of the thesis 2

1 State of the Art 3

1.1 High-Performance Computing: an overview 3

1.2 HPC Cluster 5

1.2.1 Job Scheduling 6

1.2.2 File System 7

1.3 HPC Grid 8

1.4 Autonomic Computing 9

1.5 Dynamic HPC management using Control Theory 12

1.5.1 Assets of control theory for computing system 12

1.5.2 Challenges 13

1.5.3 Literature overview 14

2 System description 17

2.0.1 The Experimental Infrastructure: Grid5000 17

2.1 Single Cluster Components 18

2.1.1 Controller CIGRI 19

2.1.2 Priorities inside the OAR scheduler 20

2.1.3 Overview of the System's Description 22

2.2 Prior work: a PI controller 24

2.2.1 Model of File System 25
<table><tbody><tr><td>2.2.2 Controller Algorithm</td><td>30</td></tr><tr><td>2.2.3 PI performances and limitations</td><td>32</td></tr><tr><td><b>3 Adaptive Control Design</b></td><td><b>35</b></td></tr><tr><td>3.1 Adaptive Control</td><td>35</td></tr><tr><td>3.1.1 Self-Tuning</td><td>36</td></tr><tr><td>3.1.2 Fundamental Algorithm Framework: Basis for Subsequent Variations</td><td>37</td></tr><tr><td>3.2 Exploring Algorithmic Approaches: A Triad of Implementations</td><td>41</td></tr><tr><td>3.2.1 Parallel Estimation</td><td>42</td></tr><tr><td>3.2.2 Robust Estimation</td><td>43</td></tr><tr><td>3.2.3 Selective Memory Estimation</td><td>45</td></tr><tr><td>3.3 Explicitly taking into account the HP disturbance</td><td>47</td></tr><tr><td>3.3.1 Limitation of the double estimation</td><td>48</td></tr><tr><td><b>4 Validation of Algorithms</b></td><td><b>49</b></td></tr><tr><td>4.1 Validation in Simulation</td><td>49</td></tr><tr><td>4.1.1 Choice of parameters: α</td><td>49</td></tr><tr><td>4.1.2 Comparison of algorithms</td><td>52</td></tr><tr><td>4.1.3 Case with HP disturbance</td><td>55</td></tr><tr><td>4.2 Evaluation with experiments on the real platform</td><td>57</td></tr><tr><td>4.2.1 Experimental setup</td><td>58</td></tr><tr><td>4.2.2 Initial parameter condition</td><td>59</td></tr><tr><td>4.2.3 Experiment Result with Varying File Size</td><td>62</td></tr><tr><td>4.3 PI vs. Adaptive PI</td><td>64</td></tr><tr><td><b>5 Conclusion and Future work</b></td><td><b>71</b></td></tr><tr><td><b>A Appendix A</b></td><td><b>73</b></td></tr><tr><td><b>Bibliography</b></td><td><b>75</b></td></tr><tr><td><b>List of Figures</b></td><td><b>81</b></td></tr><tr><td><b>List of Tables</b></td><td><b>85</b></td></tr><tr><td><b>List of Symbols</b></td><td><b>87</b></td></tr></tbody></table>
<table><tbody><tr><td>2.2.2 Controller Algorithm</td><td>30</td></tr><tr><td>2.2.3 PI performances and limitations</td><td>32</td></tr><tr><td><b>3 Adaptive Control Design</b></td><td><b>35</b></td></tr><tr><td>3.1 Adaptive Control</td><td>35</td></tr><tr><td>3.1.1 Self-Tuning</td><td>36</td></tr><tr><td>3.1.2 Fundamental Algorithm Framework: Basis for Subsequent Variations</td><td>37</td></tr><tr><td>3.2 Exploring Algorithmic Approaches: A Triad of Implementations</td><td>41</td></tr><tr><td>3.2.1 Parallel Estimation</td><td>42</td></tr><tr><td>3.2.2 Robust Estimation</td><td>43</td></tr><tr><td>3.2.3 Selective Memory Estimation</td><td>45</td></tr><tr><td>3.3 Explicitly taking into account the HP disturbance</td><td>47</td></tr><tr><td>3.3.1 Limitation of the double estimation</td><td>48</td></tr><tr><td><b>4 Validation of Algorithms</b></td><td><b>49</b></td></tr><tr><td>4.1 Validation in Simulation</td><td>49</td></tr><tr><td>4.1.1 Choice of parameters: α</td><td>49</td></tr><tr><td>4.1.2 Comparison of algorithms</td><td>52</td></tr><tr><td>4.1.3 Case with HP disturbance</td><td>55</td></tr><tr><td>4.2 Evaluation with experiments on the real platform</td><td>57</td></tr><tr><td>4.2.1 Experimental setup</td><td>58</td></tr><tr><td>4.2.2 Initial parameter condition</td><td>59</td></tr><tr><td>4.2.3 Experiment Result with Varying File Size</td><td>62</td></tr><tr><td>4.3 PI vs. Adaptive PI</td><td>64</td></tr><tr><td><b>5 Conclusion and Future work</b></td><td><b>71</b></td></tr><tr><td><b>A Appendix A</b></td><td><b>73</b></td></tr><tr><td><b>Bibliography</b></td><td><b>75</b></td></tr><tr><td><b>List of Figures</b></td><td><b>81</b></td></tr><tr><td><b>List of Tables</b></td><td><b>85</b></td></tr><tr><td><b>List of Symbols</b></td><td><b>87</b></td></tr></tbody></table>
Acknowledgements 89

Ringraziamenti 91
Acknowledgements 89

Ringraziamenti 91
<figure><img src="image_7.png" /></figure>
<figure><img src="image_7.png" /></figure>
# Introduction

This Master's thesis focuses on the application of control techniques to resource allocation in High-Performance Computing (HPC) systems. The presented work is part of a long-term research carried out at INRIA in Grenoble (France) that has resulted in a control technique to minimize idle resources within an HPC cluster. Building upon this result, the primary objective of this work is to make the said controller adaptive so as to face diverse operational *scenarii* and various clusters without requiring a manual re-tuning.

In the contemporary landscape, High-Performance Computing and its computational power have become crucial in the scientific domain. The HPC technology plays a fundamental role in numerous fields, including - but not limited to - weather prediction [1], the accelerated development of vaccines, large-size dynamic simulation, big data management and more. Consequently, HPC systems are beneficial for both the scientific community and the society at large by facilitating the advancement of new technologies and knowledge.

Nevertheless, such cutting-edge infrastructures come at a considerable cost for both development and maintenance, and given the highly dynamic nature of the field, they have relatively short life cycles. Thus, maximizing resource utilization within these structures is a fundamental means to optimize their efficiency and cost-effectiveness.

The scientific collocation of the research just mentioned is within Autonomic Computing, a field that IBM pioneered starting approximately in the 70s of the last century in response to a growing challenge, namely the escalating complexity of computational infrastructures. In a series of blueprints, IBM foresaw a future where computing systems would become so complicated to be manageable by a decreasing number of professionals, hence making “self-governance” capabilities a necessity.

In addition, HPC represents a substantial investment for companies, so that its suboptimal management could lead to a shortened lifespan and under-utilization of computing, potentially causing concerns for investors. Autonomic Computing offers a solution to this problem as well, by making any equipment more affective during its useful life. This approach enables machines to optimize their resources efficiently and minimize errors re-
# Introduction

This Master's thesis focuses on the application of control techniques to resource allocation in High-Performance Computing (HPC) systems. The presented work is part of a long-term research carried out at INRIA in Grenoble (France) that has resulted in a control technique to minimize idle resources within an HPC cluster. Building upon this result, the primary objective of this work is to make the said controller adaptive so as to face diverse operational *scenarii* and various clusters without requiring a manual re-tuning.

In the contemporary landscape, High-Performance Computing and its computational power have become crucial in the scientific domain. The HPC technology plays a fundamental role in numerous fields, including - but not limited to - weather prediction [1], the accelerated development of vaccines, large-size dynamic simulation, big data management and more. Consequently, HPC systems are beneficial for both the scientific community and the society at large by facilitating the advancement of new technologies and knowledge.

Nevertheless, such cutting-edge infrastructures come at a considerable cost for both development and maintenance, and given the highly dynamic nature of the field, they have relatively short life cycles. Thus, maximizing resource utilization within these structures is a fundamental means to optimize their efficiency and cost-effectiveness.

The scientific collocation of the research just mentioned is within Autonomic Computing, a field that IBM pioneered starting approximately in the 70s of the last century in response to a growing challenge, namely the escalating complexity of computational infrastructures. In a series of blueprints, IBM foresaw a future where computing systems would become so complicated to be manageable by a decreasing number of professionals, hence making “self-governance” capabilities a necessity.

In addition, HPC represents a substantial investment for companies, so that its suboptimal management could lead to a shortened lifespan and under-utilization of computing, potentially causing concerns for investors. Autonomic Computing offers a solution to this problem as well, by making any equipment more affective during its useful life. This approach enables machines to optimize their resources efficiently and minimize errors re-
sulting from human distractions. While human managers will continue to play a crucial
role, therefore, their focus will shift toward handling larger, more complex issues that
machines cannot autonomously address.

Coming to the main subject of this work, the mentioned existing controller was aimed
to reduce – ideally, minimize – idle resources within an HPC cluster. To accomplish this
task, the INRIA team employed the control theory to construct a system based on a
Proportional-Integral (PI) controller, with the purpose of dispatching incoming work to
computing units by dividing it into small computational tasks, exploiting the so gained
granularity to best fill the cluster’s available resources.

However, the said controller was designed based on a simplified linear model. Consequently, its performance deteriorated as operational conditions deviated from the nominal state. The core contribution of this thesis is to enhance that controller with an identification and adaptation algorithm. This new algorithm enables the controller to dynamically adjust its parameters to accommodate for varying working conditions, preventing the undesired behaviors observed in the previous solution.

**0.1. Organization of the thesis**

**Chapter 1** Large-scale description of the system with an overview on the literature.

**Chapter 2** Insightful description of the system and, in the end, the previous work of the researcher is presented.

**Chapter 3** Explanation of what is Adaptive Control and Self-Tuning. Then, the design of the three different algorithms in two different contexts - evaluation of one parameter and two parameters.

**Chapter 4** In this chapter the algorithms are tuned and tested. After the test, only one algorithm is implemented in the real platform and here the suitable initial condition is discussed. In the end, there is a comparison between PI and Adaptive PI.

**Chapter 5** Here there are the conclusions of the work and some ideas for the future.
sulting from human distractions. While human managers will continue to play a crucial
role, therefore, their focus will shift toward handling larger, more complex issues that
machines cannot autonomously address.

Coming to the main subject of this work, the mentioned existing controller was aimed
to reduce – ideally, minimize – idle resources within an HPC cluster. To accomplish this
task, the INRIA team employed the control theory to construct a system based on a
Proportional-Integral (PI) controller, with the purpose of dispatching incoming work to
computing units by dividing it into small computational tasks, exploiting the so gained
granularity to best fill the cluster’s available resources.

However, the said controller was designed based on a simplified linear model. Consequently, its performance deteriorated as operational conditions deviated from the nominal state. The core contribution of this thesis is to enhance that controller with an identification and adaptation algorithm. This new algorithm enables the controller to dynamically adjust its parameters to accommodate for varying working conditions, preventing the undesired behaviors observed in the previous solution.

**0.1. Organization of the thesis**

**Chapter 1** Large-scale description of the system with an overview on the literature.

**Chapter 2** Insightful description of the system and, in the end, the previous work of the researcher is presented.

**Chapter 3** Explanation of what is Adaptive Control and Self-Tuning. Then, the design of the three different algorithms in two different contexts - evaluation of one parameter and two parameters.

**Chapter 4** In this chapter the algorithms are tuned and tested. After the test, only one algorithm is implemented in the real platform and here the suitable initial condition is discussed. In the end, there is a comparison between PI and Adaptive PI.

**Chapter 5** Here there are the conclusions of the work and some ideas for the future.
# 1 | State of the Art

This chapter provides a brief overview of High-Performance Computing (HPC), in a way tailored specifically for automation and control professionals, followed by an exploration of the primary components of HPC clusters and grids. Having introduced the said physical components and their interactions, the focus is then moved to the growing significance of control theory in *autonomic computing*. Subsequently, the potential and the challenges of integrating the control theory into this relatively new field are examined. In addition, the chapter summarises the outcome of a comprehensive review of prior research, focusing particularly on two distinct works that address themes that are similar to those discussed in this thesis.

## 1.1. High-Performance Computing: an overview

High-Performance Computing (HPC) encompasses various computing systems that have common capabilities to overcome limitations encountered by traditional computers in terms of complexity and time consumption. These limitations often arise when dealing with simulations, heavy computations, or the management of vast amounts of data. HPC includes systems such as supercomputers, clusters, and grids, all of which share these aforementioned properties.

Before delving into technical details, we would like to give the reader a brief historical overview of these computational structures. The first supercomputer, the CRAY-1 (Fig. 1.3), was introduced in 1975 and boasted an unprecedented computational rate of 100 million floating-point operations per second (MFlop/s) [2]. Since then, HPC has made significant progress, prompting the need to monitor achievements worldwide. Thus, in 1993, the TOP500 list was established. The TOP500 list ranks the 500 most powerful HPC systems in the world and is updated biannually [3]. As of June 2023, the most powerful supercomputer on the list achieved an astounding rate of 1.194 Exaflop/s. The continuous progress of HPC is made possible by the development of different crucial functionalities as *parallel computing* and *communication network*.
# 1 | State of the Art

This chapter provides a brief overview of High-Performance Computing (HPC), in a way tailored specifically for automation and control professionals, followed by an exploration of the primary components of HPC clusters and grids. Having introduced the said physical components and their interactions, the focus is then moved to the growing significance of control theory in *autonomic computing*. Subsequently, the potential and the challenges of integrating the control theory into this relatively new field are examined. In addition, the chapter summarises the outcome of a comprehensive review of prior research, focusing particularly on two distinct works that address themes that are similar to those discussed in this thesis.

## 1.1. High-Performance Computing: an overview

High-Performance Computing (HPC) encompasses various computing systems that have common capabilities to overcome limitations encountered by traditional computers in terms of complexity and time consumption. These limitations often arise when dealing with simulations, heavy computations, or the management of vast amounts of data. HPC includes systems such as supercomputers, clusters, and grids, all of which share these aforementioned properties.

Before delving into technical details, we would like to give the reader a brief historical overview of these computational structures. The first supercomputer, the CRAY-1 (Fig. 1.3), was introduced in 1975 and boasted an unprecedented computational rate of 100 million floating-point operations per second (MFlop/s) [2]. Since then, HPC has made significant progress, prompting the need to monitor achievements worldwide. Thus, in 1993, the TOP500 list was established. The TOP500 list ranks the 500 most powerful HPC systems in the world and is updated biannually [3]. As of June 2023, the most powerful supercomputer on the list achieved an astounding rate of 1.194 Exaflop/s. The continuous progress of HPC is made possible by the development of different crucial functionalities as *parallel computing* and *communication network*.
Parallel computing is a key characteristic that empowers HPC. As the development of more powerful processors became increasingly challenging and expensive, a solution emerged: instead of relying on a single, specialized, and costly processor, multiple cheaper processors could be used [4]. Then, parallel computing replaces the single processor with multiple processors, effectively addressing the limitations of relying on a single processor. Distributing the computational load among different processors reduces the burden on each individual processor and overcomes power and thermal limitations.

However, this collaborative approach introduces a new challenge, that is, the need to manage a communication network. In the past, when the number of CPUs (Central Process Unit) was small, managing data and communication was not a significant issue, and separate networks for these purposes was feasible. However, as the number of CPUs increased, the communication network's cost escalated, leading to a tradeoff between cost and performance. Then, a decision was made to merge the two networks, creating a unified network for both communication and data transfer. Various topology networks have been developed, with one of the earliest being the torus interconnection. In this arrangement, all nodes are interconnected with one another, and the topology can be realized in different dimensions. An example of a 2D torus topology is shown in Figure 1.1, giving an idea of its shape.

<figure><img src="image_8.png" /><figcaption>Figure 1.1: Torus design network [5].</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Figure 1.2: Fat tree network.</figcaption></figure>

Another topology commonly used is the fat tree [6]. Unlike the torus, the fat tree does not connect each processor directly to others. Instead, it establishes a hierarchical structure (Fig. 1.2) resembling a tree, which reduces the amount of cabling required, resulting in a more cost-effective solution compared to the torus. "Fat" refers to the increasing bandwidth required as one ascends the fat tree; it starts with low bandwidth at the bottom and increases as one moves up.

Summing up, HPC distinguishes itself from traditional computers by offering incredible speed and computational power thanks to the use of several processors and network topologies. Then, because of the updating over the years of architecture and power
Parallel computing is a key characteristic that empowers HPC. As the development of more powerful processors became increasingly challenging and expensive, a solution emerged: instead of relying on a single, specialized, and costly processor, multiple cheaper processors could be used [4]. Then, parallel computing replaces the single processor with multiple processors, effectively addressing the limitations of relying on a single processor. Distributing the computational load among different processors reduces the burden on each individual processor and overcomes power and thermal limitations.

However, this collaborative approach introduces a new challenge, that is, the need to manage a communication network. In the past, when the number of CPUs (Central Process Unit) was small, managing data and communication was not a significant issue, and separate networks for these purposes was feasible. However, as the number of CPUs increased, the communication network's cost escalated, leading to a tradeoff between cost and performance. Then, a decision was made to merge the two networks, creating a unified network for both communication and data transfer. Various topology networks have been developed, with one of the earliest being the torus interconnection. In this arrangement, all nodes are interconnected with one another, and the topology can be realized in different dimensions. An example of a 2D torus topology is shown in Figure 1.1, giving an idea of its shape.

<figure><img src="image_8.png" /><figcaption>Figure 1.1: Torus design network [5].</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Figure 1.2: Fat tree network.</figcaption></figure>

Another topology commonly used is the fat tree [6]. Unlike the torus, the fat tree does not connect each processor directly to others. Instead, it establishes a hierarchical structure (Fig. 1.2) resembling a tree, which reduces the amount of cabling required, resulting in a more cost-effective solution compared to the torus. "Fat" refers to the increasing bandwidth required as one ascends the fat tree; it starts with low bandwidth at the bottom and increases as one moves up.

Summing up, HPC distinguishes itself from traditional computers by offering incredible speed and computational power thanks to the use of several processors and network topologies. Then, because of the updating over the years of architecture and power
consumption, HPC systems have expanded beyond their initial realm of research and penetrated various fields, including aerospace, life sciences, artificial intelligence, finance, and energy [7, 8, 9].

<figure><img src="image_10.png" /><figcaption>Figure 1.3: Picture of CRAY-1 with his peculiar C shape [10].</figcaption></figure>

## 1.2. HPC Cluster

A High-Performance Computing cluster opens up new horizons for parallel computing by embracing distributed computing models. Indeed, a cluster can be best described as an ensemble of stand-alone computers that are interconnected and collaborate smoothly to accomplish complex tasks. Each computer within the cluster is referred to as a *node*, and these nodes possess more than just processing capabilities. They also have their own dedicated memory and operating system, making them self-contained entities within the larger cluster ecosystem. Furthermore, the nodes are linked together through specialized, high-speed connections, facilitating efficient communication and data exchange [4].

The power of a cluster lies in its ability to divide the computational workload of a specific task among multiple computers, a process commonly known as workload distribution. Despite this division, the user (ideally) experiences a unified computing environment, perceiving the cluster as a single powerful machine. This perception is made possible through sophisticated coordination mechanisms and resource management techniques that seamlessly integrate the individual capabilities of each node into a cohesive whole. As a result, the cluster transcends the limits of a single machine and uses the combined strength of its constituent nodes to tackle computationally intensive problems with efficiency and speed.
consumption, HPC systems have expanded beyond their initial realm of research and penetrated various fields, including aerospace, life sciences, artificial intelligence, finance, and energy [7, 8, 9].

<figure><img src="image_10.png" /><figcaption>Figure 1.3: Picture of CRAY-1 with his peculiar C shape [10].</figcaption></figure>

## 1.2. HPC Cluster

A High-Performance Computing cluster opens up new horizons for parallel computing by embracing distributed computing models. Indeed, a cluster can be best described as an ensemble of stand-alone computers that are interconnected and collaborate smoothly to accomplish complex tasks. Each computer within the cluster is referred to as a *node*, and these nodes possess more than just processing capabilities. They also have their own dedicated memory and operating system, making them self-contained entities within the larger cluster ecosystem. Furthermore, the nodes are linked together through specialized, high-speed connections, facilitating efficient communication and data exchange [4].

The power of a cluster lies in its ability to divide the computational workload of a specific task among multiple computers, a process commonly known as workload distribution. Despite this division, the user (ideally) experiences a unified computing environment, perceiving the cluster as a single powerful machine. This perception is made possible through sophisticated coordination mechanisms and resource management techniques that seamlessly integrate the individual capabilities of each node into a cohesive whole. As a result, the cluster transcends the limits of a single machine and uses the combined strength of its constituent nodes to tackle computationally intensive problems with efficiency and speed.
1.2.1. Job Scheduling

In most scenarios, it is rare for a single job to utilize the entire cluster. As a result, the
cluster needs to be divided and shared among multiple users. To facilitate this sharing, a
scheduler is necessary to handle and manage all the job requests within the cluster. This
scheduler is a critical component of a more complex system known as the Resource and
Job Management System (RJMS) [11].

The RJMS can be divided into three distinct parts:

**Application Manager** : This component serves as the interface between users and the scheduler. Users submit job descriptions to the application manager, enabling the scheduler to find appropriate space and time within the cluster for each job.

**Scheduler** : The scheduler computes the job allocation and determines the timeslot for each job based on their respective priorities, if applicable.

**Resource Manager** : Acting as the interface between the scheduler and the cluster platform, the resource manager monitors the jobs within the cluster. It handles the deployment of applications and oversees their execution.

The scheduler serves as a bridge connecting the user interface and the platform interface within the system. It plays a crucial role in managing job scheduling and allocation. Following there is a representation of RJMS (Figure 1.4). In the picture, there is also the *file system* that will be explained later.

<figure><img src="image_11.png" /><figcaption>Figure 1.4: Representation of RJMS connected with both the user and cluster [11].</figcaption></figure>

After providing an overview of the job scheduler’s framework, we can delve into a higher-
level understanding of its functioning. The following code snippet illustrates the basic
1.2.1. Job Scheduling

In most scenarios, it is rare for a single job to utilize the entire cluster. As a result, the
cluster needs to be divided and shared among multiple users. To facilitate this sharing, a
scheduler is necessary to handle and manage all the job requests within the cluster. This
scheduler is a critical component of a more complex system known as the Resource and
Job Management System (RJMS) [11].

The RJMS can be divided into three distinct parts:

**Application Manager** : This component serves as the interface between users and the scheduler. Users submit job descriptions to the application manager, enabling the scheduler to find appropriate space and time within the cluster for each job.

**Scheduler** : The scheduler computes the job allocation and determines the timeslot for each job based on their respective priorities, if applicable.

**Resource Manager** : Acting as the interface between the scheduler and the cluster platform, the resource manager monitors the jobs within the cluster. It handles the deployment of applications and oversees their execution.

The scheduler serves as a bridge connecting the user interface and the platform interface within the system. It plays a crucial role in managing job scheduling and allocation. Following there is a representation of RJMS (Figure 1.4). In the picture, there is also the *file system* that will be explained later.

<figure><img src="image_11.png" /><figcaption>Figure 1.4: Representation of RJMS connected with both the user and cluster [11].</figcaption></figure>

After providing an overview of the job scheduler’s framework, we can delve into a higher-
level understanding of its functioning. The following code snippet illustrates the basic
operation of the scheduler, specifically in the context of the First-In-First-Out (FIFO) discipline.

upon each event (arrived or terminated) run:

while `waiting_queue` is not empty
`next_job`=$waiting_queue.pop_front()`

if `next_job` fit now:
`launch(next_job)`

else
`waiting_queue.push_front()`
`break`

This code is executed only when jobs arrive in the queue or when the cluster finishes processing existing jobs. Two essential functions are featured in the code:

`pop_front()` : With this function, the scheduler selects the first job in the queue and plans it inside the cluster, if there is enough space.

`push_front()` : Conversely, this function adds a job to the front of the queue. This happens when there is not enough space inside the cluster. In short, the task gets picked up and put back in the queue in case the cluster cannot afford it.

The one above is a basic interpretation of the scheduler’s work. More complex codes are usually employed, such as the well-known Backfill [12].

The job scheduling architecture is a crucial component of a cluster as it is in charge of efficiently managing task allocation, optimizing resource usage, ensuring fairness, and enhancing the overall performance. By intelligently coordinating job execution, the scheduler maximizes cluster efficiency and throughput, effectively utilizing available resources.

### 1.2.2. File System

The file system, also known as the file server, is another critical component of the cluster that works as storage. Within the cluster, each node can access two types of file systems: a local file, system exclusive to that particular node, and a shared file system, accessible by all nodes in the cluster. These two file systems exhibit different performances, with the local file system being limited in capabilities compared to the shared file system due to cost and space constraints. For the purpose of this thesis, we will focus on the shared file system.
operation of the scheduler, specifically in the context of the First-In-First-Out (FIFO) discipline.

upon each event (arrived or terminated) run:

while `waiting_queue` is not empty
`next_job`=$waiting_queue.pop_front()`

if `next_job` fit now:
`launch(next_job)`

else
`waiting_queue.push_front()`
`break`

This code is executed only when jobs arrive in the queue or when the cluster finishes processing existing jobs. Two essential functions are featured in the code:

`pop_front()` : With this function, the scheduler selects the first job in the queue and plans it inside the cluster, if there is enough space.

`push_front()` : Conversely, this function adds a job to the front of the queue. This happens when there is not enough space inside the cluster. In short, the task gets picked up and put back in the queue in case the cluster cannot afford it.

The one above is a basic interpretation of the scheduler's work. More complex codes are usually employed, such as the well-known Backfill [12].

The job scheduling architecture is a crucial component of a cluster as it is in charge of efficiently managing task allocation, optimizing resource usage, ensuring fairness, and enhancing the overall performance. By intelligently coordinating job execution, the scheduler maximizes cluster efficiency and throughput, effectively utilizing available resources.

### 1.2.2. File System

The file system, also known as the file server, is another critical component of the cluster that works as storage. Within the cluster, each node can access two types of file systems: a local file, system exclusive to that particular node, and a shared file system, accessible by all nodes in the cluster. These two file systems exhibit different performances, with the local file system being limited in capabilities compared to the shared file system due to cost and space constraints. For the purpose of this thesis, we will focus on the shared file system.
The file system functions as an abstraction layer for the physical storage devices, enabling applications to make input and output (I/O) requests for specific portions of files [13]. One significant challenge in the relationship between the HPC cluster and the file server is the speed difference. While the cluster operates in the exascale speed, the file server lags behind due to slower devices like memory, disk, and network. Consequently, the I/O system's performance dictates the speed of the HPC system [14].

Another critical issue related to the file server is its available space. Each node in the cluster can use the file server to store, read or write data, and this may lead to a saturation of the file system's space. As a consequence, a file server's approaching saturation can significantly slow down the network between the cluster and the file server. In the worst-case scenario, the entire system may become stuck, even if the cluster is not completely full [15, 16]. Due to this substantial impact of the file server on the system, it is essential not only to monitor the state of the cluster but also the state of the file system to prevent such problematic scenarios.

One widely implemented partial solution is to execute the file system on several machines to improve performance. However, this does not entirely eliminate the aforementioned problems. Additional measures are necessary to effectively address this issue.

## 1.3. HPC Grid

While clusters are characterized by a distributed computing environment where all nodes are physically close to each other, grids, consist of clusters that are geographically dispersed. The primary objective of grids is to leverage the collective power of interconnected clusters, typically facilitated through the Internet. From a quantitative perspective, clusters typically consist of hundreds of nodes on average, whereas grids encompass millions of computers. Thus, it is evident that the power of a grid surpasses that of an individual cluster. However, within a grid, there can be variations in performance due to the inherent heterogeneity of the clusters [17, 4]. Moreover, HPC grids provide a distributed computing infrastructure that enables the pooling of computing resources across multiple organizations or institutions.

However, the geographic dispersion of clusters within a grid introduces a potential challenge: latency. As the workload is divided among clusters situated far apart, communication between them can introduce delays. Consequently, this latency issue must be carefully considered, as it could amplify the overall computational time.

In conclusion, HPC grids offer a powerful solution for distributed computing, leveraging interconnected clusters across geographical locations. However, the challenge of latency needs to be addressed to fully exploit the potential benefits of grid computing and avoid
The file system functions as an abstraction layer for the physical storage devices, enabling applications to make input and output (I/O) requests for specific portions of files [13]. One significant challenge in the relationship between the HPC cluster and the file server is the speed difference. While the cluster operates in the exascale speed, the file server lags behind due to slower devices like memory, disk, and network. Consequently, the I/O system's performance dictates the speed of the HPC system [14].

Another critical issue related to the file server is its available space. Each node in the cluster can use the file server to store, read or write data, and this may lead to a saturation of the file system's space. As a consequence, a file server's approaching saturation can significantly slow down the network between the cluster and the file server. In the worst-case scenario, the entire system may become stuck, even if the cluster is not completely full [15, 16]. Due to this substantial impact of the file server on the system, it is essential not only to monitor the state of the cluster but also the state of the file system to prevent such problematic scenarios.

One widely implemented partial solution is to execute the file system on several machines to improve performance. However, this does not entirely eliminate the aforementioned problems. Additional measures are necessary to effectively address this issue.

## 1.3. HPC Grid

While clusters are characterized by a distributed computing environment where all nodes are physically close to each other, grids, consist of clusters that are geographically dispersed. The primary objective of grids is to leverage the collective power of interconnected clusters, typically facilitated through the Internet. From a quantitative perspective, clusters typically consist of hundreds of nodes on average, whereas grids encompass millions of computers. Thus, it is evident that the power of a grid surpasses that of an individual cluster. However, within a grid, there can be variations in performance due to the inherent heterogeneity of the clusters [17, 4]. Moreover, HPC grids provide a distributed computing infrastructure that enables the pooling of computing resources across multiple organizations or institutions.

However, the geographic dispersion of clusters within a grid introduces a potential challenge: latency. As the workload is divided among clusters situated far apart, communication between them can introduce delays. Consequently, this latency issue must be carefully considered, as it could amplify the overall computational time.

In conclusion, HPC grids offer a powerful solution for distributed computing, leveraging interconnected clusters across geographical locations. However, the challenge of latency needs to be addressed to fully exploit the potential benefits of grid computing and avoid
significant computational time amplifications.

## 1.4. Autonomic Computing

In 2001, IBM identified a critical challenge in the advancement of computing systems: complexity. At that time, system administrators were entirely responsible for managing computer systems. IBM stressed that if the growth rate continued as before, there would soon be a complication to handle by hand [18, 19]. Fortunately, alongside this concern, IBM put forth a potential solution: *autonomic computing*. In reference to Parashar et al.[20], autonomic computing refers to the utilization of self-governing strategies and algorithms by the system and its applications to effectively manage complexity and uncertainties, thereby minimizing the need for human intervention, which leads to *self-adaptive* software system [21, 22]. This approach enables an HPC system to adapt and optimize its performance autonomously. Here is where the expertise of automation and control professionals becomes crucial. Automation not only enables self-management but also facilitates self-optimization from various perspectives, including energy consumption and the utilization of resources [23, 15]. By embracing autonomic computing principles, the field of computing aims to address the increasing complexity of computer systems while maximizing their performance and efficiency. These advancements have the potential to alleviate the burden on human administrators and enable computing systems to operate seamlessly in dynamic environments.

In 2005, IBM introduced an example of autonomic computing architecture, depicted in Figure 1.5. This architecture, referred to as MAPE loop, consists of four main components, each serving a distinct purpose:
significant computational time amplifications.

## 1.4. Autonomic Computing

In 2001, IBM identified a critical challenge in the advancement of computing systems: complexity. At that time, system administrators were entirely responsible for managing computer systems. IBM stressed that if the growth rate continued as before, there would soon be a complication to handle by hand [18, 19]. Fortunately, alongside this concern, IBM put forth a potential solution: *autonomic computing*. In reference to Parashar et al.[20], autonomic computing refers to the utilization of self-governing strategies and algorithms by the system and its applications to effectively manage complexity and uncertainties, thereby minimizing the need for human intervention, which leads to *self-adaptive* software system [21, 22]. This approach enables an HPC system to adapt and optimize its performance autonomously. Here is where the expertise of automation and control professionals becomes crucial. Automation not only enables self-management but also facilitates self-optimization from various perspectives, including energy consumption and the utilization of resources [23, 15]. By embracing autonomic computing principles, the field of computing aims to address the increasing complexity of computer systems while maximizing their performance and efficiency. These advancements have the potential to alleviate the burden on human administrators and enable computing systems to operate seamlessly in dynamic environments.

In 2005, IBM introduced an example of autonomic computing architecture, depicted in Figure 1.5. This architecture, referred to as MAPE loop, consists of four main components, each serving a distinct purpose:
<figure><img src="image_12.png" /><figcaption>Figure 1.5: Functional detail of the autonomic manager [24].</figcaption></figure>

**Monitor** : This component is responsible for collecting, aggregating, filtering, and reporting detailed information, such as metrics and topologies, from a managed resource.

**Analyze** : The analyze component utilizes mechanisms for correlating and modeling complex situations. For instance, it can perform tasks like time-series forecasting and queuing models. By analyzing data, the autonomic manager can learn about the IT (Information Technology) environment and predict future situations.

**Plan** : The plan component defines the necessary actions to achieve goals and objectives. It leverages policy information to guide its decision-making process.

**Execute** : The execute component controls the execution of the planned actions, considering dynamic updates and changes in the environment.

These four components work in concert to provide the functionality of a control loop. As depicted in Figure 1.5, all the components communicate with each other, exchanging relevant knowledge. Lastly, the policies serve as constraints and goals that the overall system must adhere to. This entire figure is commonly referred to as the MAPE-K loop, which stands for Monitor-Analyze-Plan-Execute over a shared Knowledge.

The discussion mentioned above was presented by Eric Rutten et al. in 2017 [25]. In their work, they aimed to provide a clearer understanding of the MAPE-K loop in the control theory field. They proposed reinterpreting the different phases of the loop as follows:
<figure><img src="image_12.png" /><figcaption>Figure 1.5: Functional detail of the autonomic manager [24].</figcaption></figure>

**Monitor** : This component is responsible for collecting, aggregating, filtering, and reporting detailed information, such as metrics and topologies, from a managed resource.

**Analyze** : The analyze component utilizes mechanisms for correlating and modeling complex situations. For instance, it can perform tasks like time-series forecasting and queuing models. By analyzing data, the autonomic manager can learn about the IT (Information Technology) environment and predict future situations.

**Plan** : The plan component defines the necessary actions to achieve goals and objectives. It leverages policy information to guide its decision-making process.

**Execute** : The execute component controls the execution of the planned actions, considering dynamic updates and changes in the environment.

These four components work in concert to provide the functionality of a control loop. As depicted in Figure 1.5, all the components communicate with each other, exchanging relevant knowledge. Lastly, the policies serve as constraints and goals that the overall system must adhere to. This entire figure is commonly referred to as the MAPE-K loop, which stands for Monitor-Analyze-Plan-Execute over a shared Knowledge.

The discussion mentioned above was presented by Eric Rutten et al. in 2017 [25]. In their work, they aimed to provide a clearer understanding of the MAPE-K loop in the control theory field. They proposed reinterpreting the different phases of the loop as follows:
**Monitor** : This phase can be seen as the sampling phase, where data is collected from the system with a proper frequency.

**Analyze** : The analyze phase can be seen as signal estimation or the reconstruction of a signal based on the collected data. Thus, variables with the hat (i.e. $\hat{x}$).

**Plan** : The plan phase involves computing the control law using the system's knowledge held in the model.

**Execute** : The execute phase corresponds to the actual implementation of the control law, which involves making changes to the system through actuators.

Considering the aforementioned reinterpretation, the figure referred to as 1.5 can be updated with Figure 1.6.

<figure><img src="image_13.png" /><figcaption>Figure 1.6: Reinterpretation of MAPE-K loop [25].</figcaption></figure>
**Monitor** : This phase can be seen as the sampling phase, where data is collected from the system with a proper frequency.

**Analyze** : The analyze phase can be seen as signal estimation or the reconstruction of a signal based on the collected data. Thus, variables with the hat (i.e. $\hat{x}$).

**Plan** : The plan phase involves computing the control law using the system's knowledge held in the model.

**Execute** : The execute phase corresponds to the actual implementation of the control law, which involves making changes to the system through actuators.

Considering the aforementioned reinterpretation, the figure referred to as 1.5 can be updated with Figure 1.6.

<figure><img src="image_13.png" /><figcaption>Figure 1.6: Reinterpretation of MAPE-K loop [25].</figcaption></figure>
## 1.5. Dynamic HPC management using Control Theory

### 1.5.1. Assets of control theory for computing system

The application of control theory in the software field brings forth various methodologies that were not previously utilized. These approaches offer significant advantages and can greatly enhance the effectiveness of software control systems. In the following, we present how the key aspects of control theory are valuable tools for software development [26].

**Input-Output Model** : One fundamental concept is the Input-Output Model. This model is the fundamental brick for the system in Figure 1.7, where the control input (u) is linked to the measured output (y). By defining this relationship, we can establish a foundation for feedback-based control, leading to improved results. Neglecting this initial step could lead to issues such as failure to converge to equilibrium, overly aggressive or slow controllers, or an inability to adapt to different operating conditions.

<figure><img src="image_14.png" /><figcaption>Figure 1.7: Simple control scheme.</figcaption></figure>

**Dynamics and Transient** : Control theory models not only consider the input-output relationship but also incorporate the dynamics and transient effects. These models capture the influence of past output values on the present output, enabling the representation of memory effects within the system. For example, in equation 1.1 the coefficients $a_i$ and $b_j$ represent respectively the correlation between the current output and the past output, until $n$, and input, until $m-1$. By accounting for these dynamics, we gain a deeper understanding of the system's behavior.

$$y(k) = \sum_{i=1}^{n} a_i y(k-i) + \sum_{j=0}^{m-1} b_j u(k-d-j) + e(k) \quad (1.1)$$

Inside the above equation $k$ is the time step, $d$ is the delay and $e$ is noise.
## 1.5. Dynamic HPC management using Control Theory

### 1.5.1. Assets of control theory for computing system

The application of control theory in the software field brings forth various methodologies that were not previously utilized. These approaches offer significant advantages and can greatly enhance the effectiveness of software control systems. In the following, we present how the key aspects of control theory are valuable tools for software development [26].

**Input-Output Model** : One fundamental concept is the Input-Output Model. This model is the fundamental brick for the system in Figure 1.7, where the control input (u) is linked to the measured output (y). By defining this relationship, we can establish a foundation for feedback-based control, leading to improved results. Neglecting this initial step could lead to issues such as failure to converge to equilibrium, overly aggressive or slow controllers, or an inability to adapt to different operating conditions.

<figure><img src="image_14.png" /><figcaption>Figure 1.7: Simple control scheme.</figcaption></figure>

**Dynamics and Transient** : Control theory models not only consider the input-output relationship but also incorporate the dynamics and transient effects. These models capture the influence of past output values on the present output, enabling the representation of memory effects within the system. For example, in equation 1.1 the coefficients $a_i$ and $b_j$ represent respectively the correlation between the current output and the past output, until $n$, and input, until $m-1$. By accounting for these dynamics, we gain a deeper understanding of the system's behavior.

$$y(k) = \sum_{i=1}^{n} a_i y(k-i) + \sum_{j=0}^{m-1} b_j u(k-d-j) + e(k) \quad (1.1)$$

Inside the above equation $k$ is the time step, $d$ is the delay and $e$ is noise.
**Correlation between Multiple Metrics** : Another advantage of control theory is the ability to correlate multiple metrics. Indeed, it is possible to design models with different input and output variables, each with its own unique correlations. This flexibility allows us to capture complex relationships between different aspects of the system, leading to more comprehensive control strategies.

**Well-Studied Control Algorithms** : In the realm of control algorithms, software systems often rely on threshold-based approaches to maintain desired output values. While these algorithms are relatively straightforward to understand and implement, fine-tuning them can be challenging. The control theory offers a wide range of well-studied control algorithms that have been extensively researched and refined. Leveraging these established algorithms can greatly simplify the tuning process and improve system performance.

**Stability Guarantees** : Control theory also provides stability guarantees for the closed-loop system. By employing analytical methods and utilizing models of the target system and controller, we can assess the stability of the overall system. Furthermore, control theory offers guidelines for selecting appropriate parameter values to ensure system stability, enhancing the reliability of software control systems.

**Nonlinear and Time-Varying Behavior** : Moreover, control theory addresses the challenges posed by nonlinear and time-varying behaviors. Adaptive control theory, in particular, offers proven methodologies for designing controllers that can handle systems with varying behavior over time. Additionally, it provides techniques to control nonlinear systems, expanding the range of systems that can be effectively controlled.

In summary, the control theory gives crucial advice to model and design feedback loops in software systems. By embracing the methodologies and techniques offered by control theory, it can be feasible to enhance the performance, stability, and adaptability of software systems.

### 1.5.2. Challenges

However, the cultural differences between software and control engineering introduce significant challenges. Numerous studies have been conducted to establish a connection between the fields of computer science and control [27, 28]. This endeavor has been driven by the recognition that pure control specialists cannot effectively utilize their expertise without a comprehensive understanding of the processes they are dealing with. Likewise, computer science experts may lack familiarity with control theory, necessitating collaboration.
**Correlation between Multiple Metrics** : Another advantage of control theory is the ability to correlate multiple metrics. Indeed, it is possible to design models with different input and output variables, each with its own unique correlations. This flexibility allows us to capture complex relationships between different aspects of the system, leading to more comprehensive control strategies.

**Well-Studied Control Algorithms** : In the realm of control algorithms, software systems often rely on threshold-based approaches to maintain desired output values. While these algorithms are relatively straightforward to understand and implement, fine-tuning them can be challenging. The control theory offers a wide range of well-studied control algorithms that have been extensively researched and refined. Leveraging these established algorithms can greatly simplify the tuning process and improve system performance.

**Stability Guarantees** : Control theory also provides stability guarantees for the closed-loop system. By employing analytical methods and utilizing models of the target system and controller, we can assess the stability of the overall system. Furthermore, control theory offers guidelines for selecting appropriate parameter values to ensure system stability, enhancing the reliability of software control systems.

**Nonlinear and Time-Varying Behavior** : Moreover, control theory addresses the challenges posed by nonlinear and time-varying behaviors. Adaptive control theory, in particular, offers proven methodologies for designing controllers that can handle systems with varying behavior over time. Additionally, it provides techniques to control nonlinear systems, expanding the range of systems that can be effectively controlled.

In summary, the control theory gives crucial advice to model and design feedback loops in software systems. By embracing the methodologies and techniques offered by control theory, it can be feasible to enhance the performance, stability, and adaptability of software systems.

### 1.5.2. Challenges

However, the cultural differences between software and control engineering introduce significant challenges. Numerous studies have been conducted to establish a connection between the fields of computer science and control [27, 28]. This endeavor has been driven by the recognition that pure control specialists cannot effectively utilize their expertise without a comprehensive understanding of the processes they are dealing with. Likewise, computer science experts may lack familiarity with control theory, necessitating collaboration.
ration with those who possess knowledge of the required modeling and control synthesis methodologies

For example, in the two fields, the word "adaptive" has two different meanings. In software engineering, a system is called “adaptive” if it is capable of responding to the same stimulus in different ways depending on the particular situation in which the said stimulus is received. Since in the systems theory such a property is enjoyed by any dynamic system, just naming the “situation” state, not all the systems that are adaptive in the computer sense are adaptive in the systems and control sense. For the latter fact to be true, the *law* that computes the system state and output must be subject to modifications - for example, having some of its parameters change.

In addition to the differences in terminology, there are much more intrinsic differences like the idea of modeling. In software, models are often based on architectural concepts, whereas control engineering relies on equations to estimate models in the discrete and continuous time. Therefore, creating a detailed analytical model for software becomes challenging, as software is not governed by the same law as physical systems [29]. Furthermore, even if such a model is successfully created, it may quickly become inaccurate after the first software update [30].

Another obstacle faced in the software domain is the actuator. Actuators in software systems are often subject to heavy quantization, which imposes constraints on control without clear justifications. Additionally, variable delays within the system pose a significant problem. These delays can arise from various sources, including the controller itself, which may request data from parts of the system that are not designed to respond efficiently. Another challenging issue arises from sensor noise attributed to concurrent external processes. This noise significantly affects the ultimate outcomes and results. Further problems related to control theory in the software domain are discussed in detail in A. Leva et al. [31].

### 1.5.3. Literature overview

Having discussed the advantages and difficulties of applying control theory to computing systems, we can examine previous applications and their results [30]. From a modeling perspective, it appears that linear models are often preferred over nonlinear models. This preference stems from the greater complexity involved in estimating nonlinear models compared to linear ones. Furthermore, the lack of available tools for identifying nonlinear models exacerbates the difficulty [32]. However, in the cases of interest of this thesis, it seems that finding a model capable of representing suitable average quantities is sufficient, as the system nonlinearities that cause deviation from averages can be compensated for
ration with those who possess knowledge of the required modeling and control synthesis methodologies

For example, in the two fields, the word "adaptive" has two different meanings. In software engineering, a system is called “adaptive” if it is capable of responding to the same stimulus in different ways depending on the particular situation in which the said stimulus is received. Since in the systems theory such a property is enjoyed by any dynamic system, just naming the “situation” state, not all the systems that are adaptive in the computer sense are adaptive in the systems and control sense. For the latter fact to be true, the *law* that computes the system state and output must be subject to modifications - for example, having some of its parameters change.

In addition to the differences in terminology, there are much more intrinsic differences like the idea of modeling. In software, models are often based on architectural concepts, whereas control engineering relies on equations to estimate models in the discrete and continuous time. Therefore, creating a detailed analytical model for software becomes challenging, as software is not governed by the same law as physical systems [29]. Furthermore, even if such a model is successfully created, it may quickly become inaccurate after the first software update [30].

Another obstacle faced in the software domain is the actuator. Actuators in software systems are often subject to heavy quantization, which imposes constraints on control without clear justifications. Additionally, variable delays within the system pose a significant problem. These delays can arise from various sources, including the controller itself, which may request data from parts of the system that are not designed to respond efficiently. Another challenging issue arises from sensor noise attributed to concurrent external processes. This noise significantly affects the ultimate outcomes and results. Further problems related to control theory in the software domain are discussed in detail in A. Leva et al. [31].

### 1.5.3. Literature overview

Having discussed the advantages and difficulties of applying control theory to computing systems, we can examine previous applications and their results [30]. From a modeling perspective, it appears that linear models are often preferred over nonlinear models. This preference stems from the greater complexity involved in estimating nonlinear models compared to linear ones. Furthermore, the lack of available tools for identifying nonlinear models exacerbates the difficulty [32]. However, in the cases of interest of this thesis, it seems that finding a model capable of representing suitable average quantities is sufficient, as the system nonlinearities that cause deviation from averages can be compensated for
by equipping the feedback controller with adaptive or online model update mechanisms
[33].

From a pure control standpoint, the most widely preferred control strategy is the Proportional-
Integral-Derivative (PID) controller, as depicted in Figure 1.8. PID control is highly fa-
vored due to its ease of implementation and satisfactory performance in terms of set-point
tracking and disturbance rejection. Moreover, it is worth noting that *adaptive* PID con-
trollers are commonly used in software applications to compensate for errors resulting
from model linearization. The detailed explanation of the PID controller’s functioning
will be provided later in this thesis.

Despite its favorable characteristics, the PID controller does have a limitation: scalability.
Consequently, it is primarily preferred for Single-Input-Single-Output (SISO) systems. In
contrast, for Multiple-Input-Multiple-Output (MIMO) systems, alternative techniques are
preferred, with Model Predictive Control (MPC) being the most commonly used. MPC
refers to a controller that employs a system model to predict future behavior and selects
adaptive actions to minimize the cost associated with achieving this behavior. The adop-
tion of MPC enables optimal management of multiple requirements, as demonstrated in
various literature studies across different domains [34, 35, 36].

<figure><img src="image_15.png" /><figcaption>Figure 1.8: PID control loop in discrete time.</figcaption></figure>

In an effort to implement control theory in the software domain, various attempts have
been made. For Instance, in their work, S. Cerf et al. [23] successfully computed a
linear model and used a PI controller to regulate an HPC grid. In this case, they applied
the same methodology across three different clusters. The results showed satisfactory
performance in two clusters, but the third cluster did not yield the desired outcomes. This
case exemplified that simple models augmented with basic PI controllers can be effective;
however, their applicability may be limited as linear approximations and straightforward
by equipping the feedback controller with adaptive or online model update mechanisms
[33].

From a pure control standpoint, the most widely preferred control strategy is the Proportional-
Integral-Derivative (PID) controller, as depicted in Figure 1.8. PID control is highly fa-
vored due to its ease of implementation and satisfactory performance in terms of set-point
tracking and disturbance rejection. Moreover, it is worth noting that *adaptive* PID con-
trollers are commonly used in software applications to compensate for errors resulting
from model linearization. The detailed explanation of the PID controller’s functioning
will be provided later in this thesis.

Despite its favorable characteristics, the PID controller does have a limitation: scalability.
Consequently, it is primarily preferred for Single-Input-Single-Output (SISO) systems. In
contrast, for Multiple-Input-Multiple-Output (MIMO) systems, alternative techniques are
preferred, with Model Predictive Control (MPC) being the most commonly used. MPC
refers to a controller that employs a system model to predict future behavior and selects
adaptive actions to minimize the cost associated with achieving this behavior. The adop-
tion of MPC enables optimal management of multiple requirements, as demonstrated in
various literature studies across different domains [34, 35, 36].

<figure><img src="image_15.png" /><figcaption>Figure 1.8: PID control loop in discrete time.</figcaption></figure>

In an effort to implement control theory in the software domain, various attempts have
been made. For Instance, in their work, S. Cerf et al. [23] successfully computed a
linear model and used a PI controller to regulate an HPC grid. In this case, they applied
the same methodology across three different clusters. The results showed satisfactory
performance in two clusters, but the third cluster did not yield the desired outcomes. This
case exemplified that simple models augmented with basic PI controllers can be effective;
however, their applicability may be limited as linear approximations and straightforward
controllers might not always account for all relevant phenomena, as evidenced in the case
of the last cluster.

To address this limitation while preserving a linear model, an adaptive controller (Ch. 3.1) can be employed. For example, in the work of A. Filieri et al. [37], researchers generated a linear model for the system and synthesized a configurable controller. This controller tackles potential nonlinearities by dynamically adapting the linear model using a Kalman filter. Moreover, to handle significant changes in system behavior, the controller incorporates a change-point detection strategy to trigger an online model rebuilding phase. By integrating these two features into the controller, the overall system performs well even with a linear model instead of a nonlinear one.

The works quoted above address the challenge of applying a linear model to a complex
process from different perspectives. The first work illustrates that a controller designed
exclusively for a linear model could not always be effective. Conversely, the second work
overcomes this limitation by employing an adaptive controller and recalculating the model
when the operational conditions significantly deviate from the previous state. In this
study, we aim to solve this issue using an alternative approach. We propose enhancing
the existing PI controller with an identification algorithm. In this way, the controller
should meet the specified requirements irrespective of the operational conditions.
controllers might not always account for all relevant phenomena, as evidenced in the case
of the last cluster.

To address this limitation while preserving a linear model, an adaptive controller (Ch. 3.1) can be employed. For example, in the work of A. Filieri et al. [37], researchers generated a linear model for the system and synthesized a configurable controller. This controller tackles potential nonlinearities by dynamically adapting the linear model using a Kalman filter. Moreover, to handle significant changes in system behavior, the controller incorporates a change-point detection strategy to trigger an online model rebuilding phase. By integrating these two features into the controller, the overall system performs well even with a linear model instead of a nonlinear one.

The works quoted above address the challenge of applying a linear model to a complex
process from different perspectives. The first work illustrates that a controller designed
exclusively for a linear model could not always be effective. Conversely, the second work
overcomes this limitation by employing an adaptive controller and recalculating the model
when the operational conditions significantly deviate from the previous state. In this
study, we aim to solve this issue using an alternative approach. We propose enhancing
the existing PI controller with an identification algorithm. In this way, the controller
should meet the specified requirements irrespective of the operational conditions.
# 2 | System description

In the preceding chapter, we provided an overview of HPC and introduced its main components in general. In this one, we investigate the elements of the particular system used for this study. To begin, we present the HPC grid where experiments are conducted, followed by an examination of one of the main aspects of this thesis: the CIGRI controller. Within this section, we highlight the existing limitations of the current CIGRI implementation. Then, a comprehensive analysis of the scheduler is provided, along with an overview of all the interactions among the system.

Moving forward, we discuss the state of the research prior to the work presented herein. We elucidate the model's design, the underlying hypotheses, and the subsequent validation process. Finally, we introduce the controller development based on this model and conclude with a thorough performance evaluation of the controller.

## 2.0.1. The Experimental Infrastructure: Grid5000

The entire study is conducted within the HPC grid known as Grid5000. This grid comprises various clusters spread across nine different cities in France, as depicted in Figure 2.1, with a total of 15000 cores and 800 nodes.

Grid5000 serves as a large-scale and versatile testbed, supporting experiment-driven research in all domains of computer science, with a particular emphasis on parallel and distributed computing, including Cloud, HPC, Big Data, and AI. It is widely utilized by multiple research teams from different universities such as Université Grenoble Alpes and Université de Lorraine, as well as by esteemed organizations like CNRS and INRIA.
2

System description

In the preceding chapter, we provided an overview of HPC and introduced its main com-
ponents in general. In this one, we investigate the elements of the particular system used
for this study. To begin, we present the HPC grid where experiments are conducted,
followed by an examination of one of the main aspects of this thesis: the CIGRI con-
troller. Within this section, we highlight the existing limitations of the current CIGRI
implementation. Then, a comprehensive analysis of the scheduler is provided, along with
an overview of all the interactions among the system.

Moving forward, we discuss the state of the research prior to the work presented herein. We elucidate the model's design, the underlying hypotheses, and the subsequent validation process. Finally, we introduce the controller development based on this model and conclude with a thorough performance evaluation of the controller.

2.0.1. The Experimental Infrastructure: Grid5000

The entire study is conducted within the HPC grid known as Grid5000. This grid com-
prises various clusters spread across nine different cities in France, as depicted in Figure
2.1, with a total of 15000 cores and 800 nodes.

Grid5000 serves as a large-scale and versatile testbed, supporting experiment-driven re-
search in all domains of computer science, with a particular emphasis on parallel and
distributed computing, including Cloud, HPC, Big Data, and AI. It is widely utilized by
multiple research teams from different universities such as Université Grenoble Alpes and
Université de Lorraine, as well as by esteemed organizations like CNRS and INRIA.
<figure><img src="image_16.png" /><figcaption>Figure 2.1: Geography representation of Grid5000 [38].</figcaption></figure>

The popularity of this infrastructure stems from the wealth of information it provides, which would otherwise be unattainable through private clusters like Google Cloud Platform or Azure. This access to valuable information makes Grid5000 a highly suitable environment for research experiments, granting researchers the essential insights required to comprehensively understand the workings of the cluster.

Moreover, Grid5000 boasts a remarkable level of reconfigurability, facilitating easier execution of experiments while offering complete control over the processes. Researchers can even isolate their experiments within the network, enhancing the overall controllability of the study environment.

For all the reasons above, Grid5000 is an ideal platform for conducting this work because we are trying to test a controller that should be suitable for whatever cluster inside whatever grid. Then, all possible data that are accessible in Grid5000 becomes crucial for understanding where are the issues and giving an idea of how to solve them.

## 2.1. Single Cluster Components

As seen in the previous chapter, an HPC grid can be seen as a collection of clusters. This thesis focuses on the control of a single cluster, while the wider research to which the thesis belongs also comprises the management of different clusters.

In this section, we provide an overview of the crucial components that collaborate with the cluster and play a key role in this work. The first component is the controller, known as CIGRI [39]. Its main responsibility is to dispatch a specific number of jobs to the scheduler OAR [40]. Additionally, we explore various types of jobs that may arrive and the potential challenges associated with the dispatching process. By the end of this section, we show a comprehensive overview of the entire system.
<figure><img src="image_16.png" /><figcaption>Figure 2.1: Geography representation of Grid5000 [38].</figcaption></figure>

The popularity of this infrastructure stems from the wealth of information it provides, which would otherwise be unattainable through private clusters like Google Cloud Platform or Azure. This access to valuable information makes Grid5000 a highly suitable environment for research experiments, granting researchers the essential insights required to comprehensively understand the workings of the cluster.

Moreover, Grid5000 boasts a remarkable level of reconfigurability, facilitating easier execution of experiments while offering complete control over the processes. Researchers can even isolate their experiments within the network, enhancing the overall controllability of the study environment.

For all the reasons above, Grid5000 is an ideal platform for conducting this work because we are trying to test a controller that should be suitable for whatever cluster inside whatever grid. Then, all possible data that are accessible in Grid5000 becomes crucial for understanding where are the issues and giving an idea of how to solve them.

## 2.1. Single Cluster Components

As seen in the previous chapter, an HPC grid can be seen as a collection of clusters. This thesis focuses on the control of a single cluster, while the wider research to which the thesis belongs also comprises the management of different clusters.

In this section, we provide an overview of the crucial components that collaborate with the cluster and play a key role in this work. The first component is the controller, known as CIGRI [39]. Its main responsibility is to dispatch a specific number of jobs to the scheduler OAR [40]. Additionally, we explore various types of jobs that may arrive and the potential challenges associated with the dispatching process. By the end of this section, we show a comprehensive overview of the entire system.
2.1.1. Controller CIGRI

The CIGRI emerged as an innovative solution to address a widespread challenge faced
by various laboratories – how to efficiently pool and leverage the resources of a cluster to
achieve optimal performance. This led to the development of a simple, lightweight system
based on a modular architecture, incorporating high-level components that enable the use
of locally unutilized resources within the cluster.

The core idea behind CIGRI is to use only the idle resources of the cluster, without
affecting the tasks assigned to local users. To achieve this, the concept of *Best Effort* (BE)
jobs is introduced in the batch scheduler. BE jobs are jobs that require less computation
and have a lower priority than the other type of jobs, namely the *High-Priority* (HP). In
this study, an approximation is made - only jobs coming from CIGRI can be considered
as BE, hence the HP jobs will be tasks coming directly from users. Afterward, the CIGRI
functions as a server that communicates with all the batch schedulers across the clusters.
It operates like a regular user, submitting jobs at the BE queue of the scheduler (Figure
2.3).

While the primary objective of CIGRI is to efficiently harvest idle resources, it is crucial
to consider potential issues that might arise if this process is not carefully managed. For
instance, if CIGRI indiscriminately uses the cluster's resources without considering other
factors, such as the file server's capacity, it could lead to an overload. Therefore, CIGRI
must be equipped with a feedback mechanism not only for the clusters but also for the
file system, to prevent overload and maintain system stability [15].

<figure><img src="image_17.png" /><figcaption>Figure 2.2: Schematic picture of CIGRI.</figcaption></figure>

Figure 2.2 displays a simplified illustration of CIGRI. Indeed, for the purpose of this thesis, we focus solely on the modules linked to the controller behavior.

Starting with the job queue, one can note that the jobs are organized into *campaigns*. In this context, a *campaign* refers to the number of jobs available with a specific file size *f*.
2.1.1. Controller CIGRI

The CIGRI emerged as an innovative solution to address a widespread challenge faced
by various laboratories – how to efficiently pool and leverage the resources of a cluster to
achieve optimal performance. This led to the development of a simple, lightweight system
based on a modular architecture, incorporating high-level components that enable the use
of locally unutilized resources within the cluster.

The core idea behind CIGRI is to use only the idle resources of the cluster, without
affecting the tasks assigned to local users. To achieve this, the concept of *Best Effort* (BE)
jobs is introduced in the batch scheduler. BE jobs are jobs that require less computation
and have a lower priority than the other type of jobs, namely the *High-Priority* (HP). In
this study, an approximation is made - only jobs coming from CIGRI can be considered
as BE, hence the HP jobs will be tasks coming directly from users. Afterward, the CIGRI
functions as a server that communicates with all the batch schedulers across the clusters.
It operates like a regular user, submitting jobs at the BE queue of the scheduler (Figure
2.3).

While the primary objective of CIGRI is to efficiently harvest idle resources, it is crucial
to consider potential issues that might arise if this process is not carefully managed. For
instance, if CIGRI indiscriminately uses the cluster's resources without considering other
factors, such as the file server's capacity, it could lead to an overload. Therefore, CIGRI
must be equipped with a feedback mechanism not only for the clusters but also for the
file system, to prevent overload and maintain system stability [15].

<figure><img src="image_17.png" /><figcaption>Figure 2.2: Schematic picture of CIGRI.</figcaption></figure>

Figure 2.2 displays a simplified illustration of CIGRI. Indeed, for the purpose of this thesis, we focus solely on the modules linked to the controller behavior.

Starting with the job queue, one can note that the jobs are organized into *campaigns*. In this context, a *campaign* refers to the number of jobs available with a specific file size *f*.
(MByte).

Inside CIGRI, there are two blocks: the Controller and the Tap. The Controller plays a
crucial role as it employs an algorithm to determine the optimal number of jobs to send
to the scheduler queue based on the system’s current status. On the other hand, the Tap
is responsible for receiving the jobs selected by the Controller after this decision-making
process.

An important characteristic of CIGRI is the length of the period, namely the constant
time it waits before sending a new set of jobs; this is set 30 seconds. Due to this behavior,
both the model and the controller will be designed in discrete time.

The research time chose to focus on CiGri due to its *current* limiting implementation:

Input : *rate* (init.3)
        *increase factor* (constant 1.5)

if no running jobs then:

rate = min(rate × increase factor, 100)

submit *rate* jobs

else

submit 0 jobs

The above algorithm involves injecting new jobs into the system, but it lacks a useful
feedback mechanism regarding the system's state. Consequently, the controller will only
send new jobs if all the previous batch of jobs has been executed. This approach poses
a significant problem: there might be situations where CIGRI refrains from sending any
new job because there is a single lingering job from the previous batch still running in the
cluster. This limitation has drawn the teams attention, and it was argued that control
theory could be a potential solution to overcome this issue.

By leveraging control theory, the team aimed to enhance the performance of CIGRI by
introducing a feedback loop that allows the controller to make more informed decisions.
Indeed, monitoring the state of the system and the progress of running jobs, the controller
can dynamically adjust the injection of new jobs, ensuring a more efficient and balanced
workload distribution within the cluster. Through this approach, they wanted to aim a
real optimization of resources into the cluster.

2.1.2. Priorities inside the OAR scheduler

The OAR scheduler operates as described in the subsection 1.2.1. Within OAR, two
different queues exist: one for jobs coming from CIGRI, known as BE jobs, and another
(MByte).

Inside CIGRI, there are two blocks: the Controller and the Tap. The Controller plays a
crucial role as it employs an algorithm to determine the optimal number of jobs to send
to the scheduler queue based on the system’s current status. On the other hand, the Tap
is responsible for receiving the jobs selected by the Controller after this decision-making
process.

An important characteristic of CIGRI is the length of the period, namely the constant
time it waits before sending a new set of jobs; this is set 30 seconds. Due to this behavior,
both the model and the controller will be designed in discrete time.

The research time chose to focus on CiGri due to its *current* limiting implementation:

Input : *rate* (init.3)
        *increase factor* (constant 1.5)

if no running jobs then:

rate = min(rate × increase factor, 100)

submit *rate* jobs

else

submit 0 jobs

The above algorithm involves injecting new jobs into the system, but it lacks a useful
feedback mechanism regarding the system's state. Consequently, the controller will only
send new jobs if all the previous batch of jobs has been executed. This approach poses
a significant problem: there might be situations where CIGRI refrains from sending any
new job because there is a single lingering job from the previous batch still running in the
cluster. This limitation has drawn the teams attention, and it was argued that control
theory could be a potential solution to overcome this issue.

By leveraging control theory, the team aimed to enhance the performance of CIGRI by
introducing a feedback loop that allows the controller to make more informed decisions.
Indeed, monitoring the state of the system and the progress of running jobs, the controller
can dynamically adjust the injection of new jobs, ensuring a more efficient and balanced
workload distribution within the cluster. Through this approach, they wanted to aim a
real optimization of resources into the cluster.

2.1.2. Priorities inside the OAR scheduler

The OAR scheduler operates as described in the subsection 1.2.1. Within OAR, two
different queues exist: one for jobs coming from CIGRI, known as BE jobs, and another
one for jobs submitted directly by users, referred to as the HP jobs. In the context of
queueing theory, the relationship between these two types of jobs can be characterized as
*preemptive priority*. This means that BE jobs can only be executed when the HP queue
is empty or no HP job cannot be executed. Additionally, HP jobs have the authority to
displace a BE job from the cluster if there are no available resources to accommodate the
HP job [41]. The primary objective of OAR is to efficiently schedule both types of jobs.
However, if an HP job needs resources and takes the place of a BE job, the preemptive
priority principle comes into play, and the BE job is sent back to the BE queue to wait
for available resources again.

Another notable distinction between the BE and HP jobs lies in how they book the cluster's resources. When jobs arrive from CIGRI, they enter the queue of the OAR and wait for their turn to be executed. Instead, HP jobs have the advantage of being able to schedule specific time slots for their execution. This flexibility in scheduling is governed by the internal policies of the cluster, aimed at promoting smoother resource sharing. By allowing HP jobs to book time slots, the cluster's resource allocation becomes less troublesome. For instance, an internal rule dictates that resource-intensive jobs should be scheduled during the night when the cluster experiences lower usage, ensuring that these jobs do not interfere with other user's activities.

<figure><img src="image_18.png" /><figcaption>**Figure 2.3:** Representation of two OARs for two different clusters. The queue linked to CIGRI is the Best-Effort queue while the other is the High-Prepriority queue.</figcaption></figure>

The job scheduler visualizes the bookings on a GANTT chart, as illustrated in Figure 2.4.
In this representation, the y-axis denotes the reserved space within the cluster, the x-axis
represents time, and the rectangles symbolize the scheduled jobs from different users. The
specified duration for each job is typically provided by the user, which often tends to give
an overestimation of the actual execution time.
one for jobs submitted directly by users, referred to as the HP jobs. In the context of
queueing theory, the relationship between these two types of jobs can be characterized as
*preemptive priority*. This means that BE jobs can only be executed when the HP queue
is empty or no HP job cannot be executed. Additionally, HP jobs have the authority to
displace a BE job from the cluster if there are no available resources to accommodate the
HP job [41]. The primary objective of OAR is to efficiently schedule both types of jobs.
However, if an HP job needs resources and takes the place of a BE job, the preemptive
priority principle comes into play, and the BE job is sent back to the BE queue to wait
for available resources again.

Another notable distinction between the BE and HP jobs lies in how they book the cluster's resources. When jobs arrive from CIGRI, they enter the queue of the OAR and wait for their turn to be executed. Instead, HP jobs have the advantage of being able to schedule specific time slots for their execution. This flexibility in scheduling is governed by the internal policies of the cluster, aimed at promoting smoother resource sharing. By allowing HP jobs to book time slots, the cluster's resource allocation becomes less troublesome. For instance, an internal rule dictates that resource-intensive jobs should be scheduled during the night when the cluster experiences lower usage, ensuring that these jobs do not interfere with other user's activities.

<figure><img src="image_18.png" /><figcaption>Figure 2.3: Representation of two OARs for two different clusters. The queue linked to CIGRI is the Best-Effort queue while the other is the High-Prepriority queue.</figcaption></figure>

The job scheduler visualizes the bookings on a GANTT chart, as illustrated in Figure 2.4.
In this representation, the y-axis denotes the reserved space within the cluster, the x-axis
represents time, and the rectangles symbolize the scheduled jobs from different users. The
specified duration for each job is typically provided by the user, which often tends to give
an overestimation of the actual execution time.
<figure><img src="image_19.png" /><figcaption>Figure 2.4: Example of a GANTT chart [42].</figcaption></figure>

With this scheduling approach, the cluster's resources are utilized more efficiently, and users can plan their job execution with greater flexibility while adhering to the cluster's internal policies.

In delving deeper into the working of OAR, we discover that it requires a certain amount of time to schedule a job, a process referred to as *provisioning*. Additionally, it takes some time to delete a job, known as *deprovisioning*. However, the efficiency of the OAR largely depends on the state of the job queue. If the queue is filled with numerous pending jobs, OAR will experience slower job scheduling within the cluster. Consequently, having knowledge of the waiting queue's state could prove beneficial for the controller as it would prevent overloading the OAR's waiting queue. By understanding the current status of the queue, the controller can make informed decisions to optimize job allocation and avoid potential bottlenecks, thus enhancing the overall performance of the OAR system.

### 2.1.3. Overview of the System's Description

In the preceding sections, we presented the controller, CIGRI, responsible for dispatching jobs to OAR. On the other hand, OAR manages two distinct queues: one for CIGRI's jobs (referred to as BE jobs) and another for jobs submitted directly by users to the cluster (referred to as HP jobs). Notably, HP jobs take precedence over BE jobs in terms of priority. To clarify, both types of jobs are sent to the cluster and executed with the simultaneous utilization of the file server.

The interaction between these components can be visualized in Figure 2.5.
<figure><img src="image_19.png" /><figcaption>Figure 2.4: Example of a GANTT chart [42].</figcaption></figure>

With this scheduling approach, the cluster's resources are utilized more efficiently, and users can plan their job execution with greater flexibility while adhering to the cluster's internal policies.

In delving deeper into the working of OAR, we discover that it requires a certain amount of time to schedule a job, a process referred to as *provisioning*. Additionally, it takes some time to delete a job, known as *deprovisioning*. However, the efficiency of the OAR largely depends on the state of the job queue. If the queue is filled with numerous pending jobs, OAR will experience slower job scheduling within the cluster. Consequently, having knowledge of the waiting queue's state could prove beneficial for the controller as it would prevent overloading the OAR's waiting queue. By understanding the current status of the queue, the controller can make informed decisions to optimize job allocation and avoid potential bottlenecks, thus enhancing the overall performance of the OAR system.

### 2.1.3. Overview of the System's Description

In the preceding sections, we presented the controller, CIGRI, responsible for dispatching jobs to OAR. On the other hand, OAR manages two distinct queues: one for CIGRI's jobs (referred to as BE jobs) and another for jobs submitted directly by users to the cluster (referred to as HP jobs). Notably, HP jobs take precedence over BE jobs in terms of priority. To clarify, both types of jobs are sent to the cluster and executed with the simultaneous utilization of the file server.

The interaction between these components can be visualized in Figure 2.5.
<figure><img src="image_20.png" /><figcaption>Figure 2.5: Overall system [15].</figcaption></figure>

In addition, there are information exchanges between CIGRI and OAR, as well as the File System. The OAR sensor enables the controller to access essential data held by OAR, such as the cluster's status and the state of the waiting queue. Meanwhile, the other sensor provides insights into the file system's state, helping to prevent overload.

In cases where administrators lack specific information about the system's bottleneck, they may establish separate controls for three different closed loops. One closed-loop focuses on the cluster's objectives, such as energy performance or the filling level, while others aim to prevent overloading the file server and the BE queue of OAR. To achieve optimal control, a final control law may be derived from these three different control laws [15].

This work focuses on the system's limitations, with the file system identified as the bottleneck. This implies that the file system has significantly fewer resources compared to the cluster itself. Given this substantial gap between the two amounts resources, we make the assumption that we can treat the cluster as having an infinite number of resources for the purpose of the analysis. Throughout the thesis, we will consistently refer to a single controller, specifically the one designed for the file system. This controller plays a pivotal role in managing and optimizing the file system's operations to improve the overall system performance.
<figure><img src="image_20.png" /><figcaption>Figure 2.5: Overall system [15].</figcaption></figure>

In addition, there are information exchanges between CIGRI and OAR, as well as the File System. The OAR sensor enables the controller to access essential data held by OAR, such as the cluster's status and the state of the waiting queue. Meanwhile, the other sensor provides insights into the file system's state, helping to prevent overload.

In cases where administrators lack specific information about the system's bottleneck, they may establish separate controls for three different closed loops. One closed-loop focuses on the cluster's objectives, such as energy performance or the filling level, while others aim to prevent overloading the file server and the BE queue of OAR. To achieve optimal control, a final control law may be derived from these three different control laws [15].

This work focuses on the system's limitations, with the file system identified as the bottleneck. This implies that the file system has significantly fewer resources compared to the cluster itself. Given this substantial gap between the two amounts resources, we make the assumption that we can treat the cluster as having an infinite number of resources for the purpose of the analysis. Throughout the thesis, we will consistently refer to a single controller, specifically the one designed for the file system. This controller plays a pivotal role in managing and optimizing the file system's operations to improve the overall system performance.
## 2.2. Prior work: a PI controller

The primary objective of this study is to prevent the file system from becoming overloaded. The strategy we will adopt involves modifying the controller algorithm while preserving its fundamental structure. Consequently, the CIGRI controller is tasked with sending jobs in a manner that avoids burdening the file system with excessive load. Then, the system we are about to discuss is depicted at high abstraction level in Figure 2.6.

<figure><img src="image_21.png" /><figcaption>Figure 2.6: Picture of the file system closed loop.</figcaption></figure>

In Figure 2.6, two crucial quantities require elucidation: the control action denoted as *u*, and the output labeled as *y*. In this context, the control action is represented as a two-dimensional vector encompassing distinct quantities. The first component, denoted as *n*, signifies the count of BE jobs dispatched by the controller. The second component corresponds to the weight *f*, namely the *file size*, of an individual BE task, measured in MByte. These two quantities are subject to specific limitations. Naturally, neither of them can take negative values due to their physical interpretation. Moreover, *n* is subjected to an additional constraint. Since it is not possible to dispatch part of a job, *n* must be integer. Consequently, it must also adhere to a quantization requirement. Instead, the output *y* corresponds to the load on the file server, obtained through sensor-based measurements. However, a complicating factor arises from the sensor's measurement of various quantities. As a result, the recorded measurement *y* becomes susceptible to substantial amounts of noise.

Figure 2.6 illustrates the presence of the file system as the unique process, but it is important to acknowledge that, as depicted in Figure 2.5, the controller's perspective of the system encompasses a trio of distinct processes: OAR, cluster, and file system. The simplification in Figure 2.6 focuses solely on the file system, aligning with the forthcoming model's specification. This scope narrowing is due to the underlying assumption that both the scheduler and the cluster's processing speeds far exceed that of the file system.

After depicting the control loop under study, in order to develop an effective controller for the system, it is essential to have a thorough understanding of the system itself. Hence, we will initiate this section by describing the model.
## 2.2. Prior work: a PI controller

The primary objective of this study is to prevent the file system from becoming overloaded. The strategy we will adopt involves modifying the controller algorithm while preserving its fundamental structure. Consequently, the CIGRI controller is tasked with sending jobs in a manner that avoids burdening the file system with excessive load. Then, the system we are about to discuss is depicted at high abstraction level in Figure 2.6.

<figure><img src="image_21.png" /><figcaption>Figure 2.6: Picture of the file system closed loop.</figcaption></figure>

In Figure 2.6, two crucial quantities require elucidation: the control action denoted as *u*, and the output labeled as *y*. In this context, the control action is represented as a two-dimensional vector encompassing distinct quantities. The first component, denoted as *n*, signifies the count of BE jobs dispatched by the controller. The second component corresponds to the weight *f*, namely the *file size*, of an individual BE task, measured in MByte. These two quantities are subject to specific limitations. Naturally, neither of them can take negative values due to their physical interpretation. Moreover, *n* is subjected to an additional constraint. Since it is not possible to dispatch part of a job, *n* must be integer. Consequently, it must also adhere to a quantization requirement. Instead, the output *y* corresponds to the load on the file server, obtained through sensor-based measurements. However, a complicating factor arises from the sensor's measurement of various quantities. As a result, the recorded measurement *y* becomes susceptible to substantial amounts of noise.

Figure 2.6 illustrates the presence of the file system as the unique process, but it is important to acknowledge that, as depicted in Figure 2.5, the controller's perspective of the system encompasses a trio of distinct processes: OAR, cluster, and file system. The simplification in Figure 2.6 focuses solely on the file system, aligning with the forthcoming model's specification. This scope narrowing is due to the underlying assumption that both the scheduler and the cluster's processing speeds far exceed that of the file system.

After depicting the control loop under study, in order to develop an effective controller for the system, it is essential to have a thorough understanding of the system itself. Hence, we will initiate this section by describing the model.
## 2.2.1. Model of File System

### Modeling the static behavior

To identify the model, the team initiated the experimentation phase in an open loop setup, aiming to comprehend the underlying relationships. Importantly, they aim to model only the impact of the writing tasks, because these are considered the ones with more impact with respect to the other two operations, reading and storing.

In an open loop experiment, the team systematically manipulated the system's inputs and observed their corresponding effects on the output. The ultimate objective was to identify the optimal mathematical relationship that could effectively explain the changes in y with respect to n and f. By the use of linear regression they got

$$y = c + \beta_1 f + \beta_2 n + \gamma f \times n \quad (2.1)$$

With:

* $c = -0.5071484$

* $\beta_1 = 0.0086335$

* $\beta_2 = 0.0451394$

* $\gamma = 0.001633$

Through this experimental process, they arrived at the above model, which incorporates the two inputs, n and f, as shown in Formula 2.1. Although, It might seem odd that the result of a linear regression is a nonlinear model, the reason behind this is that in each experiment f was always fixed. However, this was an approximation made by the team. In reality, in practical scenarios, f varies in relation to the executed tasks, and its precise values is unknown.
## 2.2.1. Model of File System

### Modeling the static behavior

To identify the model, the team initiated the experimentation phase in an open loop setup, aiming to comprehend the underlying relationships. Importantly, they aim to model only the impact of the writing tasks, because these are considered the ones with more impact with respect to the other two operations, reading and storing.

In an open loop experiment, the team systematically manipulated the system's inputs and observed their corresponding effects on the output. The ultimate objective was to identify the optimal mathematical relationship that could effectively explain the changes in y with respect to n and f. By the use of linear regression they got

$$y = c + \beta_1 f + \beta_2 n + \gamma f \times n \quad (2.1)$$

With:

* $c = -0.5071484$

* $\beta_1 = 0.0086335$

* $\beta_2 = 0.0451394$

* $\gamma = 0.001633$

Through this experimental process, they arrived at the above model, which incorporates the two inputs, n and f, as shown in Formula 2.1. Although, It might seem odd that the result of a linear regression is a nonlinear model, the reason behind this is that in each experiment f was always fixed. However, this was an approximation made by the team. In reality, in practical scenarios, f varies in relation to the executed tasks, and its precise values is unknown.
## Dynamic modeling

Now we are interested in dynamic modeling, the researchers aimed to develop a first-order model due to its simplicity and ease of study. Thus, it will be possible to predict the next value of y based on the previous value and the previous action u. Following the generic shape of a first order model:

$$y(k + 1) = ay(k) + bu(k) \qquad (2.2)$$

In pursuit of this objective, they considered the structure of the sensor located at the end of the file server, which is an exponential filter called loadavg. This particular filter was employed to obtain a smoother output result, and it is represented by the following expression, similar to the previous one:

$$y(k + 1) = (1 - \xi)N_k + \xi y(k) \qquad (2.3)$$

Here, $y(k)$ denotes the loading of the file system at time instant $k$, and $N_k$ represents the number of processes currently running on the system, namely, how many files are writing at instant $k$. The value of the parameter $\xi$ is determined by the sensor's sampling time. A larger sampling time leads to a smoother output result, but it may take longer for the estimated value to converge to the actual value. Conversely, a smaller sampling time provides faster estimation but may not achieve significant smoothing of the output. After careful considerations, they opted for a small sampling time of 5 seconds (smaller than a period of CIGRI), as it struck a balance between satisfactory measurement and reasonable smoothness.

In reference to Ferrari et al. [43], the specific value of $\xi$ was determined as follows:

$$\xi = \left( \exp \left( -\frac{5}{60} \right) \right)^{\frac{\Delta t}{5}} \qquad (2.4)$$

Where $\Delta t$ is 30s, the period of CIGRI.

As previously mentioned, the primary objective is to formulate a model in the format represented by expression 2.2. Up until now, the explanation has focused on the aspect that relies on the correlation with the previous output. Now, we can proceed to evaluate the correlation on the input.
## Dynamic modeling

Now we are interested in dynamic modeling, the researchers aimed to develop a first-order model due to its simplicity and ease of study. Thus, it will be possible to predict the next value of y based on the previous value and the previous action u. Following the generic shape of a first order model:

$$y(k + 1) = ay(k) + bu(k) \qquad (2.2)$$

In pursuit of this objective, they considered the structure of the sensor located at the end of the file server, which is an exponential filter called loadavg. This particular filter was employed to obtain a smoother output result, and it is represented by the following expression, similar to the previous one:

$$y(k + 1) = (1 - \xi)N_k + \xi y(k) \qquad (2.3)$$

Here, $y(k)$ denotes the loading of the file system at time instant $k$, and $N_k$ represents the number of processes currently running on the system, namely, how many files are writing at instant $k$. The value of the parameter $\xi$ is determined by the sensor's sampling time. A larger sampling time leads to a smoother output result, but it may take longer for the estimated value to converge to the actual value. Conversely, a smaller sampling time provides faster estimation but may not achieve significant smoothing of the output. After careful considerations, they opted for a small sampling time of 5 seconds (smaller than a period of CIGRI), as it struck a balance between satisfactory measurement and reasonable smoothness.

In reference to Ferrari et al. [43], the specific value of $\xi$ was determined as follows:

$$\xi = \left( \exp \left( -\frac{5}{60} \right) \right)^{\frac{\Delta t}{5}} \qquad (2.4)$$

Where $\Delta t$ is 30s, the period of CIGRI.

As previously mentioned, the primary objective is to formulate a model in the format represented by expression 2.2. Up until now, the explanation has focused on the aspect that relies on the correlation with the previous output. Now, we can proceed to evaluate the correlation on the input.
## Model Parameters

To do the model the researchers need to define what are the input of the system. For the nature of the system, the team decided to consider as input $n$ because it's a controllable quantity while $f$ will be considered as a disturbance because has an impact on the system but is not possible to control. Afterward, to be consistent with the control literature we will rename $u$ as the number of BE jobs sent by CIGRI.

To accomplish the model they add an additional identification:

$$ (1 - \xi) \times N_k \approx b \times u(k) \qquad (2.5) $$

With the latter expression the Eq. 2.3 becomes equal to Eq. 2.2. Then, by inverting this new formula at steady state, one gets $b$

$$ \bar{y} \approx \xi \times \bar{y} + b \times \bar{u} \implies b \approx \frac{\bar{y}(1 - \xi)}{\bar{u}} = \tilde{b} \qquad (2.6) $$

Now, an expression for $b$ is available, but relies on $u$ and $y$. Taking into account the formula from the linear regression (Eq. 2.1) in the place of $y$ and considering the limit to infinite of $u$, which means a big quantity of jobs, we can effectively untangle these two quantities:

$$ \lim_{u \to +\infty} \tilde{b} \approx \lim_{u \to +\infty} \frac{(c + \beta_1 f + \beta_2 u + \gamma f \times u)(1 - \xi)}{u} = (\beta_2 + \gamma f) \times (1 - \xi) = \tilde{b} \qquad (2.7) $$

Finally, the coefficients of the first-order model are:

$$ \left\{ \begin{aligned} \xi &= \left( \exp \left( -\frac{5}{60} \right) \right)^{\frac{\Delta t}{5}} = 0.6065307 \\ \tilde{b} &= (\beta_2 + \gamma f) \times (1 - \xi) = 0.017761 + 6.4273488 \times 10^{-4} \times f \end{aligned} \right. \qquad (2.8) $$

The significance of the second input becomes evident, and it comes out that isolating the parameter $b$ (and also the model) from the file size of the jobs ($f$) is not a feasible task. In conclusion, the team uses $\tilde{b}$ as the value for $b$ to build the model and afterward the controller.

Subsequently, an investigation is conducted to assess the efficacy of this approximation under various conditions. This study aligns with the general aim of this thesis, which
## Model Parameters

To do the model the researchers need to define what are the input of the system. For the nature of the system, the team decided to consider as input $n$ because it's a controllable quantity while $f$ will be considered as a disturbance because has an impact on the system but is not possible to control. Afterward, to be consistent with the control literature we will rename $u$ as the number of BE jobs sent by CIGRI.

To accomplish the model they add an additional identification:

$$ (1 - \xi) \times N_k \approx b \times u(k) \qquad (2.5) $$

With the latter expression the Eq. 2.3 becomes equal to Eq. 2.2. Then, by inverting this new formula at steady state, one gets $b$

$$ \bar{y} \approx \xi \times \bar{y} + b \times \bar{u} \implies b \approx \frac{\bar{y}(1 - \xi)}{\bar{u}} = \tilde{b} \qquad (2.6) $$

Now, an expression for $b$ is available, but relies on $u$ and $y$. Taking into account the formula from the linear regression (Eq. 2.1) in the place of $y$ and considering the limit to infinite of $u$, which means a big quantity of jobs, we can effectively untangle these two quantities:

$$ \lim_{u \to +\infty} \tilde{b} \approx \lim_{u \to +\infty} \frac{(c + \beta_1 f + \beta_2 u + \gamma f \times u)(1 - \xi)}{u} = (\beta_2 + \gamma f) \times (1 - \xi) = \tilde{b} \qquad (2.7) $$

Finally, the coefficients of the first-order model are:

$$ \left\{ \begin{aligned} \xi &= \left( \exp \left( -\frac{5}{60} \right) \right)^{\frac{\Delta t}{5}} = 0.6065307 \\ \tilde{b} &= (\beta_2 + \gamma f) \times (1 - \xi) = 0.017761 + 6.4273488 \times 10^{-4} \times f \end{aligned} \right. \qquad (2.8) $$

The significance of the second input becomes evident, and it comes out that isolating the parameter $b$ (and also the model) from the file size of the jobs ($f$) is not a feasible task. In conclusion, the team uses $\tilde{b}$ as the value for $b$ to build the model and afterward the controller.

Subsequently, an investigation is conducted to assess the efficacy of this approximation under various conditions. This study aligns with the general aim of this thesis, which
involves real-time estimation of the parameter *b*, as opposed to relying on the approximation.

Figure 2.7 illustrates the disparity between the $\tilde{\tilde{b}}$ value obtained from Eq. 2.7 and the $\tilde{b}$ value acquired through approximation in Eq. 2.6 by the use of the relative percentage error. The presented set of four graphs exhibits distinct variations as they correspond to different values of *f*, ranging from 25 MByte to 200 MByte. Each graph effectively portrays the error with respect to *u*, where *u* takes discrete values between 10 and 50, in increments of 10. One can note that the two approximations exhibit closer agreement when dealing with larger values of the input *u*, compared to cases with smaller inputs. Notably, the error term $b_{err} = \tilde{\tilde{b}} - \tilde{b}$ increases with the file size, and $\tilde{\tilde{b}}$ tends to overestimate $\tilde{b}$ only when $f=25$MByte, whereas in all other cases, the opposite holds true. Thus, $\tilde{\tilde{b}}$ appears to capture a distinct aspect of $\tilde{b}$, which represents a more accurate representation of *b*. However, it is crucial to acknowledge that $\tilde{\tilde{b}}$ becomes less reliable when *f* is equal to or greater than 200MByte and with a limited number of jobs (less than or equal to 20).

<figure><img src="image_22.png" /><figcaption>Figure 2.7: Study of the difference between the two approximations $\tilde{\tilde{b}}$ and $\tilde{b}$ for the different file size.</figcaption></figure>

In Figure 2.8, we present a comparison between the real experiments conducted on the file server in an open-loop configuration (represented by the orange dots) and the model previously shown (represented by the blue line), with three different file sizes.
involves real-time estimation of the parameter *b*, as opposed to relying on the approximation.

Figure 2.7 illustrates the disparity between the $\tilde{\tilde{b}}$ value obtained from Eq. 2.7 and the $\tilde{b}$ value acquired through approximation in Eq. 2.6 by the use of the relative percentage error. The presented set of four graphs exhibits distinct variations as they correspond to different values of *f*, ranging from 25 MByte to 200 MByte. Each graph effectively portrays the error with respect to *u*, where *u* takes discrete values between 10 and 50, in increments of 10. One can note that the two approximations exhibit closer agreement when dealing with larger values of the input *u*, compared to cases with smaller inputs. Notably, the error term $b_{err} = \tilde{\tilde{b}} - \tilde{b}$ increases with the file size, and $\tilde{\tilde{b}}$ tends to overestimate $\tilde{b}$ only when $f=25$MByte, whereas in all other cases, the opposite holds true. Thus, $\tilde{\tilde{b}}$ appears to capture a distinct aspect of $\tilde{b}$, which represents a more accurate representation of *b*. However, it is crucial to acknowledge that $\tilde{\tilde{b}}$ becomes less reliable when *f* is equal to or greater than 200MByte and with a limited number of jobs (less than or equal to 20).

<figure><img src="image_22.png" /><figcaption>Figure 2.7: Study of the difference between the two approximations $\tilde{\tilde{b}}$ and $\tilde{b}$ for the different file size.</figcaption></figure>

In Figure 2.8, we present a comparison between the real experiments conducted on the file server in an open-loop configuration (represented by the orange dots) and the model previously shown (represented by the blue line), with three different file sizes.
$$model = G(z) = \frac{\tilde{b}}{z - \xi} \qquad (2.9)$$

The orange dot represents an average of five experiments, which helps to reduce the impact of noise on the result. Notably, the peak values differ among the three rows, which can be attributed to varying file sizes from (a) to (c). While the model provides a reasonably accurate estimation of the true system's behavior, one can note that its performance improves with higher file sizes and diminishes with smaller ones. Specifically, in the first row, the model tends to overestimate the load on the file server. However, this overestimation becomes less pronounced in the second row, and in the last row, the model appears to fit the true process very well.

<figure><img src="image_23.png" /><figcaption>Figure 2.8: Comparison between the load of the file system in open loop and the model computed above. The orange dot represents an average of five experiments, while the blue line shows the model. (a) Case of file size = 50 MByte. (b) Case of file size = 100 MByte. (c) Case of file size = 200 MByte.</figcaption></figure>

The outcomes of these two studies yield non-obvious conclusions. In the initial investigation, it appears from Figure 2.7 that as f becomes smaller, the disparity between $\tilde{b}$ and $b$ diminishes. However, an opposite observation arises from Figure 2.8, where the scenario with the smallest file size exhibits the worst result. The research team has yet to identify a definitive solution to this quandary. The disparity between these two sets of results
$$model = G(z) = \frac{\tilde{b}}{z - \xi} \qquad (2.9)$$

The orange dot represents an average of five experiments, which helps to reduce the impact of noise on the result. Notably, the peak values differ among the three rows, which can be attributed to varying file sizes from (a) to (c). While the model provides a reasonably accurate estimation of the true system's behavior, one can note that its performance improves with higher file sizes and diminishes with smaller ones. Specifically, in the first row, the model tends to overestimate the load on the file server. However, this overestimation becomes less pronounced in the second row, and in the last row, the model appears to fit the true process very well.

<figure><img src="image_23.png" /><figcaption>Figure 2.8: Comparison between the load of the file system in open loop and the model computed above. The orange dot represents an average of five experiments, while the blue line shows the model. (a) Case of file size = 50 MByte. (b) Case of file size = 100 MByte. (c) Case of file size = 200 MByte.</figcaption></figure>

The outcomes of these two studies yield non-obvious conclusions. In the initial investigation, it appears from Figure 2.7 that as *f* becomes smaller, the disparity between $\tilde{b}$ and $\tilde{b}$ diminishes. However, an opposite observation arises from Figure 2.8, where the scenario with the smallest file size exhibits the worst result. The research team has yet to identify a definitive solution to this quandary. The disparity between these two sets of results
could stem from $\tilde{b}$ not being an accurate approximation for $b$, leading to a reduction in the reliability of the first study. Alternatively, the model overestimates the actual system, and in the case where $\tilde{\tilde{b}}$ underestimated $\tilde{b}$, there is a compensation which led to a good result in the last row.

Up to this point, we showed the disparities that arise among various approximations of the parameter $b$, by plugging in the suitable file size. However, in practical scenarios, the parameter $f$ remains unknown. Consequently, our team needs to select a nominal file size in order to establish a single model. In this way, the controller is developed on this chosen nominal file size. For this purpose, a nominal file size of 100 Mbyte is adopted as a reference for the controller design. This particular file size was deliberately chosen due to its perceived representativeness, as indicated by J. Emeras et al. in their work [44]. Upon establishing this nominal file size as a foundation, the resulting system model takes on the following form:

$$G(z) = \frac{\tilde{\tilde{b}}}{z - \xi} \approx \frac{0.0821}{z - 0.606} \qquad (2.10)$$

Subsequently, the final model incorporates an additional approximation that enhances its performance within the proximity of the 100 Mbyte nominal file size. However, its reliability diminishes as the parameter $f$ deviates significantly from this established nominal value.

### 2.2.2. Controller Algorithm

After developing a first-order model for the system, the researcher's objective is to find a suitable controller to effectively regulate the system's behavior. The choice is to employ a Proportional-Integral (PI) controller due to its simplicity, robustness, and promising performance. The PI controller has two distinct parameters: the proportional gain denoted as $K_p$ and the integral gain denoted as $K_i$. The control input is calculated as follows:

$$u(k) = K_p \text{error}(k) + K_i \sum_{i=0}^{k} \text{error}(i) \qquad (2.11)$$

The role of the PI controller is to minimize the error between the system's output and the desired reference value. This error is determined as the difference between the reference value and the actual output of the system. By taking this error as its input, the PI controller generates a control signal to influence the system and bring the error to zero.
could stem from $\tilde{b}$ not being an accurate approximation for $b$, leading to a reduction in the reliability of the first study. Alternatively, the model overestimates the actual system, and in the case where $\tilde{\tilde{b}}$ underestimated $\tilde{b}$, there is a compensation which led to a good result in the last row.

Up to this point, we showed the disparities that arise among various approximations of the parameter $b$, by plugging in the suitable file size. However, in practical scenarios, the parameter $f$ remains unknown. Consequently, our team needs to select a nominal file size in order to establish a single model. In this way, the controller is developed on this chosen nominal file size. For this purpose, a nominal file size of 100 Mbyte is adopted as a reference for the controller design. This particular file size was deliberately chosen due to its perceived representativeness, as indicated by J. Emeras et al. in their work [44]. Upon establishing this nominal file size as a foundation, the resulting system model takes on the following form:

$$G(z) = \frac{\tilde{\tilde{b}}}{z - \xi} \approx \frac{0.0821}{z - 0.606} \qquad (2.10)$$

Subsequently, the final model incorporates an additional approximation that enhances its performance within the proximity of the 100 Mbyte nominal file size. However, its reliability diminishes as the parameter $f$ deviates significantly from this established nominal value.

### 2.2.2. Controller Algorithm

After developing a first-order model for the system, the researcher's objective is to find a suitable controller to effectively regulate the system's behavior. The choice is to employ a Proportional-Integral (PI) controller due to its simplicity, robustness, and promising performance. The PI controller has two distinct parameters: the proportional gain denoted as $K_p$ and the integral gain denoted as $K_i$. The control input is calculated as follows:

$$u(k) = K_p \text{error}(k) + K_i \sum_{i=0}^{k} \text{error}(i) \qquad (2.11)$$

The role of the PI controller is to minimize the error between the system's output and the desired reference value. This error is determined as the difference between the reference value and the actual output of the system. By taking this error as its input, the PI controller generates a control signal to influence the system and bring the error to zero.
The proportional parameter $K_p$ governs the strength of the controller's action in reaching the desired setpoint. However, relying solely on the proportional term is not sufficient to guarantee an error of zero in a steady state. To address this limitation, the integral part $K_I$ is introduced. The integral gain allows the controller to accumulate the error over time, which helps to address any steady-state error that remains even after the proportional control has been applied. By combining both the proportional and integral actions, the PI controller is capable of effectively regulating the system, ensuring that it converges to the desired setpoint with minimal error. In general, another possibility could be the PID control, as shown in Figure 1.8, where the derivative action brings a quicker answer but also more sensitivity to noise.

In short, the PI controller operates by taking the error between the reference value and the actual system output and then adjusting the system's input to minimize this error. The two parameters, $K_p$ and $K_I$, respectively control the proportional and integral actions of the controller, if chosen carefully, ensuring a robust and precise control strategy for the system.

<figure><img src="image_24.png" /><figcaption>Figure 2.9: Proportional-Integrative controller</figcaption></figure>

Then the PI was designed by taking into account the model 2.10 and the technique employed by J. Hellerstein et al. [45]. The latter approach allows to choose two main parameters of the PI to fulfill the two requirements $K_s$, the settling time in control steps, and $M_p$, the maximum overshoot (as a percentage of the reference).

These two desires are linked to the new poles of the system $re^{j\theta}$ and $re^{-j\theta}$, where:

$$ \bullet r \approx e^{-\frac{4}{k_s}} $$

$$ \bullet \theta \approx \pi \frac{\log r}{\log M_p} $$

Lastly, the final two parameters are directly integrated into the controller, resulting in the following parameters:
The proportional parameter $K_p$ governs the strength of the controller's action in reaching the desired setpoint. However, relying solely on the proportional term is not sufficient to guarantee an error of zero in a steady state. To address this limitation, the integral part $K_I$ is introduced. The integral gain allows the controller to accumulate the error over time, which helps to address any steady-state error that remains even after the proportional control has been applied. By combining both the proportional and integral actions, the PI controller is capable of effectively regulating the system, ensuring that it converges to the desired setpoint with minimal error. In general, another possibility could be the PID control, as shown in Figure 1.8, where the derivative action brings a quicker answer but also more sensitivity to noise.

In short, the PI controller operates by taking the error between the reference value and the actual system output and then adjusting the system's input to minimize this error. The two parameters, $K_p$ and $K_I$, respectively control the proportional and integral actions of the controller, if chosen carefully, ensuring a robust and precise control strategy for the system.

<figure><img src="image_24.png" /><figcaption>Figure 2.9: Proportional-Integrative controller</figcaption></figure>

Then the PI was designed by taking into account the model 2.10 and the technique employed by J. Hellerstein et al. [45]. The latter approach allows to choose two main parameters of the PI to fulfill the two requirements $K_s$, the settling time in control steps, and $M_p$, the maximum overshoot (as a percentage of the reference).

These two desires are linked to the new poles of the system $re^{j\theta}$ and $re^{-j\theta}$, where:

$$ \bullet r \approx e^{-\frac{4}{k_s}} $$

$$ \bullet \theta \approx \pi \frac{\log r}{\log M_p} $$

Lastly, the final two parameters are directly integrated into the controller, resulting in the following parameters:
$$ \begin{cases} K_p = \frac{\xi - r^2}{b} \\ K_I = \frac{1 - 2r \cos \theta + r^2}{b} \end{cases} \qquad (2.12) $$

For further details, all the computations are explained in Appendix A.

In the end, the team chose as value for the PI controller $K_s = 12$ and $M_p = 0$. This selection ensures that the final system will achieve the desired output within 12 time steps, and importantly, there should be no overshoots in the response. Considering the expression of $\theta$ in light of the preceding statement, the final poles will be real.

Consequently, the two parameters of the controller are $K_p = 1.13$ and $K_I = 0.98$.

### 2.2.3. PI performances and limitations

To test the behavior of the closed-loop system, the team conducts an experiment using three different file sizes, with the goal of maintaining the file server's load at a constant level of three. However, their testing objective is not solely to assess the PI controller's ability to maintain the desired output; they also want to observe its interaction with the HP jobs. Then a step disturbance is designed which loads the file server of 2 units. As mentioned earlier, the HP jobs take absolute priority over the BE, and when they arrive (in this case, around 2000 s), the controller has to reduce the number of jobs sent to the file server to avoid overloading it. This event led to a significant overshoot in the system. Once the HP jobs are completed, the controller has to adjust and start sending a slightly higher number of jobs again, resulting in an undershoot.

In Figure 2.10, it can be observed that the final behavior depends on the file size scenario. The center scenario appears to be the most favorable, as the control is accurately tuned to the true file size of the tasks. However, in the other two scenarios, there seem to be different issues.

When dealing with a file size of 50 MByte, the PI controller is tuned with a weight that is twice the actual, leading to a slower settling time than expected. Conversely, when the controller is tuned with a weight ($f$) that is half the true one, there is a speed-up in the system but with a drawback of an overshoot at the start.

The primary limitation of this approach stems from the variability in outcomes, contingent upon the disparity between the current state of $f$ and the one implemented.

Furthermore, an additional constraint arises from the fact that the evaluation of $\tilde{b}$ relies on the specific cluster. As a result, the constructed controller not only adheres to a predetermined file size of 100 MByte but is also tailored to a specific cluster choice.
$$ \left\{ \begin{aligned} K_p &= \frac{\xi - r^2}{b} \\ K_I &= \frac{1 - 2r \cos \theta + r^2}{b} \end{aligned} \right. \qquad (2.12) $$

For further details, all the computations are explained in Appendix A.

In the end, the team chose as value for the PI controller $K_s = 12$ and $M_p = 0$. This selection ensures that the final system will achieve the desired output within 12 time steps, and importantly, there should be no overshoots in the response. Considering the expression of $\theta$ in light of the preceding statement, the final poles will be real.

Consequently, the two parameters of the controller are $K_p = 1.13$ and $K_I = 0.98$.

### 2.2.3. PI performances and limitations

To test the behavior of the closed-loop system, the team conducts an experiment using three different file sizes, with the goal of maintaining the file server's load at a constant level of three. However, their testing objective is not solely to assess the PI controller's ability to maintain the desired output; they also want to observe its interaction with the HP jobs. Then a step disturbance is designed which loads the file server of 2 units. As mentioned earlier, the HP jobs take absolute priority over the BE, and when they arrive (in this case, around 2000 s), the controller has to reduce the number of jobs sent to the file server to avoid overloading it. This event led to a significant overshoot in the system. Once the HP jobs are completed, the controller has to adjust and start sending a slightly higher number of jobs again, resulting in an undershoot.

In Figure 2.10, it can be observed that the final behavior depends on the file size scenario. The center scenario appears to be the most favorable, as the control is accurately tuned to the true file size of the tasks. However, in the other two scenarios, there seem to be different issues.

When dealing with a file size of 50 MByte, the PI controller is tuned with a weight that is twice the actual, leading to a slower settling time than expected. Conversely, when the controller is tuned with a weight ($f$) that is half the true one, there is a speed-up in the system but with a drawback of an overshoot at the start.

The primary limitation of this approach stems from the variability in outcomes, contingent upon the disparity between the current state of $f$ and the one implemented.

Furthermore, an additional constraint arises from the fact that the evaluation of $\tilde{b}$ relies on the specific cluster. As a result, the constructed controller not only adheres to a predetermined file size of 100 MByte but is also tailored to a specific cluster choice.
The objective of this study is to devise a more versatile controller solution capable of accommodating different *f* and various clusters, while yielding equivalent outcomes.

<figure><img src="image_25.png" /><figcaption>**Figure 2.10:** Average of five different experiments with three different file size and a step disturbance equal to 2. The dashed red line shows the reference and the dashed black line is the settling time (h is the discretization time equal to 30s). (a) Case of *f* = 50MByte (b) Case of *f* = 100MByte (c) Case of *f* = 200MByte</figcaption></figure>
The objective of this study is to devise a more versatile controller solution capable of accommodating different *f* and various clusters, while yielding equivalent outcomes.

<figure><img src="image_25.png" /><figcaption>**Figure 2.10:** Average of five different experiments with three different file size and a step disturbance equal to 2. The dashed red line shows the reference and the dashed black line is the settling time (h is the discretization time equal to 30s). (a) Case of *f* = 50MByte (b) Case of *f* = 100MByte (c) Case of *f* = 200MByte</figcaption></figure>
<figure><img src="image_26.png" /></figure>
<figure><img src="image_26.png" /></figure>
# 3 | Adaptive Control Design

Up to this point, our examination of the file system process has revealed the influence of two distinct factors: the quantity of BE jobs dispatched by CIGRI and the file size ($f$) associated with each individual task. Because only the number of BE jobs is controllable then, only this quantity is considered as input of the system.

The developed controller, designed by selecting a nominal value for $f$, exhibited divergent outcomes based on varying operational conditions, as elucidated in Chapter 2.2.3. For instance, when the actual $f$ was halved from its nominal value, an observable deceleration in system performance was detected. On the other hand, when the actual file size was doubled, an initial overshoot behavior emerged, despite the team's initial design intentions to mitigate such overshooting tendencies.

In light of these observations, the primary objective becomes the formulation of an algorithm capable of dynamically adjusting the parameters $K_p$ and $K_I$ in response to changing operational conditions. Such a strategy aligns with the principles of *Adaptive Control* [46].

Next, we will explore Adaptive Control, with a particular focus on the Self-tuning technique and its fundamental principles. This chapter will conclude by delving into three distinct algorithms, along with their respective advantages and disadvantages.

## 3.1. Adaptive Control

The field of Adaptive Control addresses a critical challenge in designing control systems for situations where system parameters are either unknown or subject to changes over time. This approach offers a means to leverage system data effectively, allowing control systems to automatically adapt and meet desired conditions, even in the presence of varying process parameters. In addition, adaptive control proves beneficial in scenarios where there is a significant simplification of the system model [47, 48, 49].

Adaptive controllers can be categorized into two main types: *direct* and *indirect*. The distinction between these lies in the primary goal of the estimation process. Direct adaptive control focuses on estimating the most suitable parameters for the controller itself. In contrast, indirect adaptive control involves estimating the parameters of the underlying
# 3 | Adaptive Control Design

Up to this point, our examination of the file system process has revealed the influence of two distinct factors: the quantity of BE jobs dispatched by CIGRI and the file size ($f$) associated with each individual task. Because only the number of BE jobs is controllable then, only this quantity is considered as input of the system.

The developed controller, designed by selecting a nominal value for $f$, exhibited divergent outcomes based on varying operational conditions, as elucidated in Chapter 2.2.3. For instance, when the actual $f$ was halved from its nominal value, an observable deceleration in system performance was detected. On the other hand, when the actual file size was doubled, an initial overshoot behavior emerged, despite the team's initial design intentions to mitigate such overshooting tendencies.

In light of these observations, the primary objective becomes the formulation of an algorithm capable of dynamically adjusting the parameters $K_p$ and $K_I$ in response to changing operational conditions. Such a strategy aligns with the principles of *Adaptive Control* [46].

Next, we will explore Adaptive Control, with a particular focus on the Self-tuning technique and its fundamental principles. This chapter will conclude by delving into three distinct algorithms, along with their respective advantages and disadvantages.

## 3.1. Adaptive Control

The field of Adaptive Control addresses a critical challenge in designing control systems for situations where system parameters are either unknown or subject to changes over time. This approach offers a means to leverage system data effectively, allowing control systems to automatically adapt and meet desired conditions, even in the presence of varying process parameters. In addition, adaptive control proves beneficial in scenarios where there is a significant simplification of the system model [47, 48, 49].

Adaptive controllers can be categorized into two main types: *direct* and *indirect*. The distinction between these lies in the primary goal of the estimation process. Direct adaptive control focuses on estimating the most suitable parameters for the controller itself. In contrast, indirect adaptive control involves estimating the parameters of the underlying
process and subsequently utilizing this information to update the controller.

Considering that the controller relies on the process parameter denoted by *b*, the algorithm will be formulated to estimate this parameter of the system. Subsequently, we will delve into a discussion about an indirect adaptive approach.

Additionally, it is crucial for the algorithm to perform online parameter estimation due to the dynamic variations in the parameter *f*.

In the light of the aforementioned prerequisites, we endeavored to configure a *Self-Tuning* controller for the system. This pursuit aims to seamlessly integrate the parameter estimation process into the control framework, addressing the dynamic nature of the parameter *b*.

### 3.1.1. Self-Tuning

The concept of Self-Tuning was initially introduced by Astrom and Wittenmark in their seminal work [50]. In their article, they associated Self-Tuning with a crucial property wherein the controller parameters converge to the theoretically designed controller values if the process were fully known. Remarkably, they demonstrated that such convergence could still occur even if the estimated values differ from the actual values of the process. This approach allows the controller to adapt and optimize its performance based on real-time parameter estimations, enabling it to maintain effective control even in the presence of uncertainties and variations in the system. The utilization of the identification algorithm provides a means to continuously monitor and estimate the changing process parameters, ensuring the controller's responsiveness to dynamic environments and improving overall system performance.

However, one significant limitation of this technique lies in the assumption that the estimated parameters are entirely accurate and equivalent to the true values of the process. This assumption is known as the *Certainty Equivalence Principle* (CEP). While the CEP facilitates the convergence of controller parameters to the theoretically optimal values, it relies on the assumption that the estimated parameters are error-free and perfectly represent the true underlying process. In practice, this assumption may not always hold true, leading to potential discrepancies between the actual system behavior and the estimated model.
process and subsequently utilizing this information to update the controller.

Considering that the controller relies on the process parameter denoted by *b*, the algorithm will be formulated to estimate this parameter of the system. Subsequently, we will delve into a discussion about an indirect adaptive approach.

Additionally, it is crucial for the algorithm to perform online parameter estimation due to the dynamic variations in the parameter *f*.

In the light of the aforementioned prerequisites, we endeavored to configure a *Self-Tuning* controller for the system. This pursuit aims to seamlessly integrate the parameter estimation process into the control framework, addressing the dynamic nature of the parameter *b*.

### 3.1.1. Self-Tuning

The concept of Self-Tuning was initially introduced by Astrom and Wittenmark in their seminal work [50]. In their article, they associated Self-Tuning with a crucial property wherein the controller parameters converge to the theoretically designed controller values if the process were fully known. Remarkably, they demonstrated that such convergence could still occur even if the estimated values differ from the actual values of the process. This approach allows the controller to adapt and optimize its performance based on real-time parameter estimations, enabling it to maintain effective control even in the presence of uncertainties and variations in the system. The utilization of the identification algorithm provides a means to continuously monitor and estimate the changing process parameters, ensuring the controller's responsiveness to dynamic environments and improving overall system performance.

However, one significant limitation of this technique lies in the assumption that the estimated parameters are entirely accurate and equivalent to the true values of the process. This assumption is known as the *Certainty Equivalence Principle* (CEP). While the CEP facilitates the convergence of controller parameters to the theoretically optimal values, it relies on the assumption that the estimated parameters are error-free and perfectly represent the true underlying process. In practice, this assumption may not always hold true, leading to potential discrepancies between the actual system behavior and the estimated model.
<figure><img src="image_27.png" /><figcaption>Figure 3.1: Classic scheme of self-tuning approach.</figcaption></figure>

Figure 3.1 illustrates the various components involved in the self-tuning technique. Starting from the left, we have $C(\hat{S})$, where the controller relies solely on the estimated parameter of the system. This dependency on the estimated parameter is a direct consequence of CEP. The true process is represented by the variable $S$, while the identification algorithm (ID) operates in real-time to compute and determine the parameter values of the process $(\hat{S})$. These identified parameters are then transmitted to the controller, enabling it to update and adjust itself accordingly.

### 3.1.2. Fundamental Algorithm Framework: Basis for Subsequent Variations

Self-tuning regulators have been extensively studied, leading to the development of various algorithms. In this discussion, we will focus on a simpler algorithm that will be modified according to the needs. By starting with this straightforward approach, it will become easier to comprehend the underlying quantities and the associated issues. Throughout all the algorithms, we will consider $\theta$ as a vector that gathers all the unknown parameters. The simpler solution begins with a Least-Square Algorithm [51], which centers around minimizing the following cost function:

$$J(\theta) = \frac{1}{N} \sum_{i=1}^{N} (y(i) - \hat{y}(i | i-1, \theta))^2 \quad (3.1)$$

Where:

* N: number of data

* $y(i)$ measured output at instant i
<figure><img src="image_27.png" /><figcaption>Figure 3.1: Classic scheme of self-tuning approach.</figcaption></figure>

Figure 3.1 illustrates the various components involved in the self-tuning technique. Starting from the left, we have $C(\hat{S})$, where the controller relies solely on the estimated parameter of the system. This dependency on the estimated parameter is a direct consequence of CEP. The true process is represented by the variable $S$, while the identification algorithm (ID) operates in real-time to compute and determine the parameter values of the process $(\hat{S})$. These identified parameters are then transmitted to the controller, enabling it to update and adjust itself accordingly.

### 3.1.2. Fundamental Algorithm Framework: Basis for Subsequent Variations

Self-tuning regulators have been extensively studied, leading to the development of various algorithms. In this discussion, we will focus on a simpler algorithm that will be modified according to the needs. By starting with this straightforward approach, it will become easier to comprehend the underlying quantities and the associated issues. Throughout all the algorithms, we will consider $\theta$ as a vector that gathers all the unknown parameters. The simpler solution begins with a Least-Square Algorithm [51], which centers around minimizing the following cost function:

$$J(\theta) = \frac{1}{N} \sum_{i=1}^{N} (y(i) - \hat{y}(i | i-1, \theta))^2 \quad (3.1)$$

Where:

* N: number of data

* $y(i)$ measured output at instant i
* $\hat{y}(i|i-1, \theta) = i$-th estimated output by considering (i-1)-th data. Namely the formula is $\hat{y}(i|i-1, \theta) = \phi(i-1)' \cdot \theta$. Where $\phi$ is the regression vector, it collects the output and input of the system. For example being $\theta = [a, b]'$ then $\phi(i-1) = [y(i-1), u(i-d)]'$ where $d$ is the delay.

To minimize the above const function, the derivative respect $\theta$ is computed and forced equal to zero. In this way, the optimal $\theta$ is discovered.

$$ \hat{\theta} = \left[ \sum_{i=1}^{N} \phi(i-1)\phi(i-1)' \right]^{-1} \cdot \sum_{i=1}^{N} \phi(i-1)y(i) \quad (3.2) $$

## Tackling the singularity issue

Unfortunately, the above expression cannot be used due to the unpredictability of the information matrix $\phi$, which could approach singularity and lead to large spikes in the estimated parameters. As a result, an alternative cost function is utilized:

$$ J(\theta) = \frac{1}{N} \sum_{i=1}^{N} (y(i) - \hat{y}(i|i-1, \theta))^2 + (\theta - \bar{\theta})' \bar{S} (\theta - \bar{\theta}) \quad (3.3) $$

Where $\bar{\theta}$ is the initial guess for the parameters while $\bar{S}$ is a positive definite and non-singular matrix, indicating the level of confidence or trust in this initial guess. A larger $\bar{S}$ implies a higher level of trust in the initial parameter estimate. Then the new formula for $\hat{\theta}$ is:

$$ \hat{\theta} = \left[ \bar{S} + \sum_{i=1}^{N} \phi(i-1)\phi(i-1)' \right]^{-1} \cdot \left[ \bar{S}\bar{\theta} + \sum_{i=1}^{N} \phi(i-1)y(i) \right] \quad (3.4) $$

## Solving the memory and computational issue

Now that we have addressed the singularity issue and obtained a well-defined $\hat{\theta}$ using the updated formula 3.4, the data is acquired sequentially in real-time. For efficiency in memory allocation and computational processing, it is desirable to perform the computations recursively. This way, the result at time step $i-1$ can be used to obtain the estimates at time step $i$. In this context, it makes sense to replace the variable $N$ with $t$. The change from $N$ to $t$ is reasonable because the Self-tuning approach is an online process where the algorithm computes the estimates at each time step. Therefore, at each instant, the algorithm repeats the computation, and the number of data points considered
* $\hat{y}(i|i-1, \theta) = i$-th estimated output by considering (i-1)-th data. Namely the formula is $\hat{y}(i|i-1, \theta) = \phi(i-1)' \cdot \theta$. Where $\phi$ is the regression vector, it collects the output and input of the system. For example being $\theta = [a, b]'$ then $\phi(i-1) = [y(i-1), u(i-d)]'$ where $d$ is the delay.

To minimize the above const function, the derivative respect $\theta$ is computed and forced equal to zero. In this way, the optimal $\theta$ is discovered.

$$ \hat{\theta} = \left[ \sum_{i=1}^{N} \phi(i-1)\phi(i-1)' \right]^{-1} \cdot \sum_{i=1}^{N} \phi(i-1)y(i) \quad (3.2) $$

## Tackling the singularity issue

Unfortunately, the above expression cannot be used due to the unpredictability of the information matrix $\phi$, which could approach singularity and lead to large spikes in the estimated parameters. As a result, an alternative cost function is utilized:

$$ J(\theta) = \frac{1}{N} \sum_{i=1}^{N} (y(i) - \hat{y}(i|i-1, \theta))^2 + (\theta - \bar{\theta})' \bar{S} (\theta - \bar{\theta}) \quad (3.3) $$

Where $\bar{\theta}$ is the initial guess for the parameters while $\bar{S}$ is a positive definite and non-singular matrix, indicating the level of confidence or trust in this initial guess. A larger $\bar{S}$ implies a higher level of trust in the initial parameter estimate. Then the new formula for $\hat{\theta}$ is:

$$ \hat{\theta} = \left[ \bar{S} + \sum_{i=1}^{N} \phi(i-1)\phi(i-1)' \right]^{-1} \cdot \left[ \bar{S}\bar{\theta} + \sum_{i=1}^{N} \phi(i-1)y(i) \right] \quad (3.4) $$

## Solving the memory and computational issue

Now that we have addressed the singularity issue and obtained a well-defined $\hat{\theta}$ using the updated formula 3.4, the data is acquired sequentially in real-time. For efficiency in memory allocation and computational processing, it is desirable to perform the computations recursively. This way, the result at time step $i-1$ can be used to obtain the estimates at time step $i$. In this context, it makes sense to replace the variable $N$ with $t$. The change from $N$ to $t$ is reasonable because the Self-tuning approach is an online process where the algorithm computes the estimates at each time step. Therefore, at each instant, the algorithm repeats the computation, and the number of data points considered
in the Least-Square estimation is equal to the number of iterations of the algorithm, which corresponds to the current time step $t$. Afterward, we need to re-define the matrix $S$:

$$S(t) = \bar{S} + \sum_{i=1}^{t} \phi(i-1)\phi(i-1)' \quad (3.5)$$

$$S(t+1) = S(t) + \phi(t)\phi(t)' \quad (3.6)$$

After this modification, this matrix can be called *information matrix*, because inside has the $\phi$ vector, which brings the new informations. The updated optimal parameter will be:

$$\hat{\theta}_{t+1} = \hat{\theta}_t + S(t+1)^{-1}\phi(t)(y(t+1) - \phi(t)'\hat{\theta}_t) \quad (3.7)$$

To simplify the computation of $S(t+1)^{-1}$, we use a lemma from linear algebra found in Chapter 2 of [52]. This lemma enables us to obtain $S(t+1)^{-1}$ from $S(t)^{-1}$, facilitating the recursive update. Additionally, a new variable, denoted as $V(t) = S(t)^{-1}$, is introduced and referred to as the *covariance matrix*. By introducing this new variable, the algorithm can be further streamlined. The updated algorithm is as follows:

$$V(t+1) = V(t) - \frac{V(t)\phi(t)\phi(t)'V(t)}{1 + \phi(t)'V(t)\phi(t)} \quad (3.8)$$

$$\hat{\theta}_{t+1} = \hat{\theta}_t + V(t+1)\phi(t)(y(t+1) - \phi(t)'\hat{\theta}_t) \quad (3.9)$$

Before we proceed further, we would like to add some comments to the expression 3.9. In this expression, the estimated parameter at time step $t+1$ is computed based on the parameter estimate at the previous time step, $\hat{\theta}_t$, with an updating term. This updating term represents the difference between the measured output $y(t+1)$ and the estimated output $\hat{y}(t+1)$, namely the prediction error $\epsilon$, weighted by the product of the covariance matrix and the regression vector.
in the Least-Square estimation is equal to the number of iterations of the algorithm, which corresponds to the current time step $t$. Afterward, we need to re-define the matrix $S$:

$$S(t) = \bar{S} + \sum_{i=1}^{t} \phi(i-1)\phi(i-1)' \quad (3.5)$$

$$S(t+1) = S(t) + \phi(t)\phi(t)' \quad (3.6)$$

After this modification, this matrix can be called *information matrix*, because inside has the $\phi$ vector, which brings the new informations. The updated optimal parameter will be:

$$\hat{\theta}_{t+1} = \hat{\theta}_t + S(t+1)^{-1}\phi(t)(y(t+1) - \phi(t)'\hat{\theta}_t) \quad (3.7)$$

To simplify the computation of $S(t+1)^{-1}$, we use a lemma from linear algebra found in Chapter 2 of [52]. This lemma enables us to obtain $S(t+1)^{-1}$ from $S(t)^{-1}$, facilitating the recursive update. Additionally, a new variable, denoted as $V(t) = S(t)^{-1}$, is introduced and referred to as the *covariance matrix*. By introducing this new variable, the algorithm can be further streamlined. The updated algorithm is as follows:

$$V(t+1) = V(t) - \frac{V(t)\phi(t)\phi(t)'V(t)}{1 + \phi(t)'V(t)\phi(t)} \quad (3.8)$$

$$\hat{\theta}_{t+1} = \hat{\theta}_t + V(t+1)\phi(t)(y(t+1) - \phi(t)'\hat{\theta}_t) \quad (3.9)$$

Before we proceed further, we would like to add some comments to the expression 3.9. In this expression, the estimated parameter at time step $t+1$ is computed based on the parameter estimate at the previous time step, $\hat{\theta}_t$, with an updating term. This updating term represents the difference between the measured output $y(t+1)$ and the estimated output $\hat{y}(t+1)$, namely the prediction error $\epsilon$, weighted by the product of the covariance matrix and the regression vector.
## Forgetting factor for time-varying parameters

When dealing with time-varying parameters, it becomes essential to account for the evolving nature of the system and give more weight to recent data while gradually forgetting older data. To achieve this, a *forgetting factor*, denoted as $\mu$, is introduced [53]. The forgetting factor varies between 0 and 1, and when it is equal to 1, the formula presented earlier is recovered.

$$S(t + 1) = \mu \cdot S(t) + \phi(t)\phi(t)' \qquad (3.10)$$

$$V(t + 1) = \frac{V(t)}{\mu} - \frac{V(t)\phi(t)\phi(t)'V(t)}{1 + \phi(t)'V(t)\phi(t)} \cdot \frac{1}{\mu^2} \qquad (3.11)$$

When $\mu$ is closer to 1, the algorithm becomes slower to follow time-varying parameters, as it gives more weight to historical data and is less sensitive to rapid changes. However, this approach also makes the algorithm less susceptible to noise, as it considers a larger amount of data. On the other hand, with a smaller value of $\mu$, the algorithm becomes more responsive to fast-varying parameters, enabling it to track rapid changes in the system more effectively. However, a smaller $\mu$ also means that noise has a more significant impact on the parameter estimates, potentially leading to less accurate results.

## The singularity problem strikes back

Despite the benefits of introducing the forgetting factor, a potential concern arises with the latter formula. The inclusion of $\mu$ may reintroduce the singularity issue, leading to the occurrence of *bursting* or *blow-up* phenomena in the control system [54]. The singularity problem manifests as sudden, large spikes in the estimated parameters, causing instability in the control performance.
## Forgetting factor for time-varying parameters

When dealing with time-varying parameters, it becomes essential to account for the evolving nature of the system and give more weight to recent data while gradually forgetting older data. To achieve this, a *forgetting factor*, denoted as $\mu$, is introduced [53]. The forgetting factor varies between 0 and 1, and when it is equal to 1, the formula presented earlier is recovered.

$$S(t + 1) = \mu \cdot S(t) + \phi(t)\phi(t)' \quad (3.10)$$

$$V(t + 1) = \frac{V(t)}{\mu} - \frac{V(t)\phi(t)\phi(t)'V(t)}{1 + \phi(t)'V(t)\phi(t)} \cdot \frac{1}{\mu^2} \quad (3.11)$$

When $\mu$ is closer to 1, the algorithm becomes slower to follow time-varying parameters, as it gives more weight to historical data and is less sensitive to rapid changes. However, this approach also makes the algorithm less susceptible to noise, as it considers a larger amount of data. On the other hand, with a smaller value of $\mu$, the algorithm becomes more responsive to fast-varying parameters, enabling it to track rapid changes in the system more effectively. However, a smaller $\mu$ also means that noise has a more significant impact on the parameter estimates, potentially leading to less accurate results.

## The singularity problem strikes back

Despite the benefits of introducing the forgetting factor, a potential concern arises with the latter formula. The inclusion of $\mu$ may reintroduce the singularity issue, leading to the occurrence of *bursting* or *blow-up* phenomena in the control system [54]. The singularity problem manifests as sudden, large spikes in the estimated parameters, causing instability in the control performance.
<figure><img src="image_28.png" /><figcaption>Figure 3.2: Effect of the bursting phenomena in $\hat{y}$ [54].</figcaption></figure>

In this scenario, the bursting phenomena occur because the system lacks sufficient new information, leading to insufficient excitation of the system. When the system does not receive enough new data, the estimation process may become less accurate and prone to large spikes in the estimated parameters. Indeed it is usual to identify self-tuning as an approach that needs persistent excitation. To mitigate the bursting phenomena, various approaches can be implemented. For instance, the constant trace algorithm can be utilized to ensure that the covariance matrix, denoted as $V$, does not approach infinity. By limiting the growth of the covariance matrix, the algorithm remains more stable and avoids the issue of unbounded growth, which can lead to bursting behavior. Another method known as directional forgetting can be employed, where the forgetting factor $\mu$ is not applied uniformly to all elements of the covariance matrix. By selectively applying $\mu$ to specific elements of the matrix, the algorithm can focus more on relevant information, reducing the impact of noise or outliers. Other techniques and algorithms are also available to address the bursting phenomena, and these are discussed in detail in the work of P. Navratil and al. [55].

## 3.2. Exploring Algorithmic Approaches: A Triad of Implementations

In this section, we show three distinct algorithms aimed at estimating the parameter $b$. Since our focus is on estimation, the symbol $\hat{b}$ will denote the estimated value. In this initial exposition of the algorithms, we will disregard the influence of the HP disturbance. The mathematical representation of the process model is given by:

$$y(k + 1) = \xi y(k) + bu(k) + e(k) \qquad (3.12)$$
<figure><img src="image_28.png" /><figcaption>Figure 3.2: Effect of the bursting phenomena in $\hat{y}$ [54].</figcaption></figure>

In this scenario, the bursting phenomena occur because the system lacks sufficient new information, leading to insufficient excitation of the system. When the system does not receive enough new data, the estimation process may become less accurate and prone to large spikes in the estimated parameters. Indeed it is usual to identify self-tuning as an approach that needs persistent excitation. To mitigate the bursting phenomena, various approaches can be implemented. For instance, the constant trace algorithm can be utilized to ensure that the covariance matrix, denoted as $V$, does not approach infinity. By limiting the growth of the covariance matrix, the algorithm remains more stable and avoids the issue of unbounded growth, which can lead to bursting behavior. Another method known as directional forgetting can be employed, where the forgetting factor $\mu$ is not applied uniformly to all elements of the covariance matrix. By selectively applying $\mu$ to specific elements of the matrix, the algorithm can focus more on relevant information, reducing the impact of noise or outliers. Other techniques and algorithms are also available to address the bursting phenomena, and these are discussed in detail in the work of P. Navratil and al. [55].

## 3.2. Exploring Algorithmic Approaches: A Triad of Implementations

In this section, we show three distinct algorithms aimed at estimating the parameter $b$. Since our focus is on estimation, the symbol $\hat{b}$ will denote the estimated value. In this initial exposition of the algorithms, we will disregard the influence of the HP disturbance. The mathematical representation of the process model is given by:

$$y(k + 1) = \xi y(k) + bu(k) + e(k) \qquad (3.12)$$
Upon inspection, a novel variable emerges within the model, signifying the noise, e, originating from the sensor due to external processes external to the file system. The research team has conducted an assessment of this noise and has determined that it conforms to a white noise with standard deviation of 0.59.

The estimated model takes the following form:

$$ \hat{y}(k + 1) = \xi y(k) + \hat{b}(k)u(k) \quad (3.13) $$

Given that there is just a singular parameter to be estimated, then the symbol $\phi$ represents a scalar, specifically equal to $u$, and correspondingly, $V$ is a scalar as well.

### 3.2.1. Parallel Estimation

Before delving into the code and explaining the reasons for choosing this algorithm, it is important to clarify the concept of *Parallel Estimation* [52]. In computer science, parallel computation typically involves splitting a job into different resources. However, in this context, parallel computing refers to performing the same computation simultaneously with slightly different conditions. Having explained the concept of parallel estimation in this context, let's now explore the rationale behind selecting this particular algorithm.

The chosen algorithm employs a recursive least-squares estimator with variable forgetting factor. At each step, a $\mu$ is chosen among different values to minimize the discrepancy between the measured output and the estimated output. As a result, this algorithm is capable of effectively tracking both fast and slow dynamics, and it prevents the occurrence of the blowing-up phenomena. A close experiment is shown in [56].

Following the MATLAB code:

```matlab
function [hat_o, V_o] = parallel (y, y_b, f, b_i, V_i, x)
    define forget.factor, n = length(forget.factor)
    for w = 1:n
        m = forget.factor(w)
        V_vector(w) = computed with 3.11
        b_vector(w) = computed with 3.9
        residual(w) = abs(y - x_b - b_vector(w)f)
        pos = find.minimumPosition(residual)
        b_o = b_vector(pos), V_o = V_vector(pos)
    end
```

One can see that the algorithm takes as input
Upon inspection, a novel variable emerges within the model, signifying the noise, e, originating from the sensor due to external processes external to the file system. The research team has conducted an assessment of this noise and has determined that it conforms to a white noise with standard deviation of 0.59.

The estimated model takes the following form:

$$ \hat{y}(k + 1) = \xi y(k) + \hat{b}(k)u(k) \quad (3.13) $$

Given that there is just a singular parameter to be estimated, then the symbol $\phi$ represents a scalar, specifically equal to $u$, and correspondingly, $V$ is a scalar as well.

### 3.2.1. Parallel Estimation

Before delving into the code and explaining the reasons for choosing this algorithm, it is important to clarify the concept of *Parallel Estimation* [52]. In computer science, parallel computation typically involves splitting a job into different resources. However, in this context, parallel computing refers to performing the same computation simultaneously with slightly different conditions. Having explained the concept of parallel estimation in this context, let's now explore the rationale behind selecting this particular algorithm.

The chosen algorithm employs a recursive least-squares estimator with variable forgetting factor. At each step, a $\mu$ is chosen among different values to minimize the discrepancy between the measured output and the estimated output. As a result, this algorithm is capable of effectively tracking both fast and slow dynamics, and it prevents the occurrence of the blowing-up phenomena. A close experiment is shown in [56].

Following the MATLAB code:

```matlab
function [hat_o, V_o] = parallel(y, y_b, phi, b_i, V_i, xi)
    define forget.factor, n = length(forget.factor)
    for w = 1:n
        mu = forget.factor(w)
        V_vector(w) = computed with 3.11
        b_vector(w) = computed with 3.9
        residual(w) = abs(y - xi - b_vector(w))
        pos = find.minimumPosition(residual)
        b_o = b_vector(pos), V_o = V_vector(pos)
    end
```

One can see that the algorithm takes as input
* $y$: measured output

* $y_b$: measured output of the time step before

* $\phi$: regression matrix, in this case is equal to $u$

* $\hat{b}_i$: is the estimated parameter of time step before. In case of inizialization is the starting condition chosen by the user.

* $V_i$: is the covariance value of the previus time step. In case of inizialization is the starting condition chosen by the user.

* $\xi$: is the value estimated from the filter with equation 2.2.1

The following algorithm, utilizing the function *find.minimumPosition*, serves to determine the position of the smallest residual within the vector. Subsequently, it strategically selects the best values for $\mu$, consequently also the value for $\hat{b}$ and $V$.

A pivotal aspect of this first algorithm lies in its ability to circumvent the imposition of a fixed forgetting factor. Indeed, if $\hat{y}$ exhibits pronounced oscillations for the approaching of the bursting phenomena, the algorithm dynamically adjusts the forgetting factor to 1, thereby arresting the approach towards singularity. Simultaneously, in response to changes in $f$, the algorithm selects a smaller value of $\mu$.

To sum up, this technique estimates a time-varying parameter and self-adapts to its changing rate.

### 3.2.2. Robust Estimation

For this second algorithm, we are taking a step back from the traditional least-squares approach. Up until now, we have been discussing a least-square algorithm, which assumes that the noise is small. However, when dealing with significant errors, the impact on $\hat{b}$ can be substantial due to the squared term in the cost function. To achieve a *Robust Estimation* [52], we need to modify the prediction error in formula 3.9. Instead of plug in the difference between the measured output and the estimated one, we will introduce a function that behaves differently for different prediction error ($\epsilon$) magnitudes. Specifically, for larger errors, the function will be more gradual, deviating from linearity, while for smaller errors, the function will resemble a linear one. This modification allows the algorithm to handle larger errors more effectively, making it more robust in the presence of substantial noise. The specific function that we have chosen is:

$$f(\epsilon(k)) = \frac{\epsilon(k)}{1 + \alpha |\epsilon(k)|} \qquad (3.14)$$
* $y$: measured output

* $y_b$: measured output of the time step before

* $\phi$: regression matrix, in this case is equal to $u$

* $\hat{b}_i$: is the estimated parameter of time step before. In case of inizialization is the starting condition chosen by the user.

* $V_i$: is the covariance value of the previus time step. In case of inizialization is the starting condition chosen by the user.

* $\xi$: is the value estimated from the filter with equation 2.2.1

The following algorithm, utilizing the function *find.minimumPosition*, serves to determine the position of the smallest residual within the vector. Subsequently, it strategically selects the best values for $\mu$, consequently also the value for $\hat{b}$ and $V$.

A pivotal aspect of this first algorithm lies in its ability to circumvent the imposition of a fixed forgetting factor. Indeed, if $\hat{y}$ exhibits pronounced oscillations for the approaching of the bursting phenomena, the algorithm dynamically adjusts the forgetting factor to 1, thereby arresting the approach towards singularity. Simultaneously, in response to changes in $f$, the algorithm selects a smaller value of $\mu$.

To sum up, this technique estimates a time-varying parameter and self-adapts to its changing rate.

### 3.2.2. Robust Estimation

For this second algorithm, we are taking a step back from the traditional least-squares approach. Up until now, we have been discussing a least-square algorithm, which assumes that the noise is small. However, when dealing with significant errors, the impact on $\hat{b}$ can be substantial due to the squared term in the cost function. To achieve a *Robust Estimation* [52], we need to modify the prediction error in formula 3.9. Instead of plug in the difference between the measured output and the estimated one, we will introduce a function that behaves differently for different prediction error ($\epsilon$) magnitudes. Specifically, for larger errors, the function will be more gradual, deviating from linearity, while for smaller errors, the function will resemble a linear one. This modification allows the algorithm to handle larger errors more effectively, making it more robust in the presence of substantial noise. The specific function that we have chosen is:

$$f(\epsilon(k)) = \frac{\epsilon(k)}{1 + \alpha |\epsilon(k)|} \qquad (3.14)$$
$$ \epsilon(k + 1) = y(k + 1) - \xi y(k) - \hat{b}(k)u(k) \quad (3.15) $$

As consequence the expression 3.9 becomes:

$$ \hat{b}(k + 1) = \hat{b}(k) + V(k + 1)\phi(k)f(\epsilon(k)) \quad (3.16) $$

In addition, the revised formula introduces a novel parameter denoted as $\alpha$, which plays a pivotal role in the noise reduction process. The magnitude of $\alpha$ directly influences the extent of noise reduction achieved. It is important to note that as $\alpha$ increases, the degree of noise reduction becomes more pronounced. However, a significant increase in the value of $\alpha$ is accompanied by a notable deceleration of the algorithm's estimation. This phenomenon can be attributed to the fact that excessively high values of $\alpha$ not only mitigate the impact of noise but also diminish the algorithm's adaptability to varying working conditions. Additionally, one can note that the previous algorithm corresponds to the specific scenario where $\alpha$ is set to 0.

We would like to emphasize that the parallel estimation remains a fundamental aspect of the algorithm, but instead of the prediction error ($\epsilon$), we now utilize the function $f(\epsilon)$ as outlined in the new formula 3.16.
$$ \epsilon(k + 1) = y(k + 1) - \xi y(k) - \hat{b}(k)u(k) \qquad (3.15) $$

As consequence the expression 3.9 becomes:

$$ \hat{b}(k + 1) = \hat{b}(k) + V(k + 1)\phi(k)f(\epsilon(k)) \qquad (3.16) $$

In addition, the revised formula introduces a novel parameter denoted as $\alpha$, which plays a pivotal role in the noise reduction process. The magnitude of $\alpha$ directly influences the extent of noise reduction achieved. It is important to note that as $\alpha$ increases, the degree of noise reduction becomes more pronounced. However, a significant increase in the value of $\alpha$ is accompanied by a notable deceleration of the algorithm's estimation. This phenomenon can be attributed to the fact that excessively high values of $\alpha$ not only mitigate the impact of noise but also diminish the algorithm's adaptability to varying working conditions. Additionally, one can note that the previous algorithm corresponds to the specific scenario where $\alpha$ is set to 0.

We would like to emphasize that the parallel estimation remains a fundamental aspect of the algorithm, but instead of the prediction error ($\epsilon$), we now utilize the function $f(\epsilon)$ as outlined in the new formula 3.16.
### 3.2.3. Selective Memory Estimation

This latest algorithm introduces a profound departure from the previous two. Notably, a key innovation within this algorithm lies in its capability to turn off during periods without new information. The rationale behind incorporating this feature stems from the experimental context, where the parameter $b$ is anticipated to remain constant over extended durations, punctuated by sudden and abrupt changes like a step function. Then, we used the *Selective Memory* algorithm [57]. This algorithm updates the estimated parameter only if new information is available. By doing so, it can efficiently learn from new data points while maintaining stability and reducing unnecessary updates when the system remains relatively unchanged. Implementing this algorithm in our experimental setup could provide the best of both worlds – fast learning and adaptability when needed, combined with stability and reduced oscillations in periods of stability. This approach appears promising for addressing the specific characteristics of our future implementation into the cluster, ensuring accurate and efficient parameter estimation.

Following the new algorithm split into several stages:

**Step 0:** Defining $r(k)$ as an estimate of the variance of the unmodeled dynamics and $M_0$ as the memory length. Choose $r_0 > 0, \theta(0), V(0) > 0, 1 < M_0 < \inf$. Set $r(0) = r_0, \sigma = 1 - \frac{1}{M_0}$ and then update $k$, the new value will be $k = 1$

**Step 1:** Select a function for $r(k)$

$$r(k) = \max[\sigma \times r(k-1) + (1-\sigma) \times \epsilon(k)^2, r_0]$$

Where $\epsilon(k) = y(k) - ay(k-1) - \hat{b}(k-1)\phi(k-1)$. Recall that $\phi(k-1) = u(k-1)$.

**Step 2:** Set $B(k) = 0$ and

$$A(k) = \begin{cases} 1, & \text{if } \frac{\phi(k-1)V(k-1)\phi(k-1)}{r(k)} \ge 1/M_0 \\ 0, & \text{otherwise} \end{cases}$$

**Step 3:** If $A(k) = 0$, set:

$$B(k) = \begin{cases} 1, & \text{if } r(k) \ge \max_{1 \le i \le k} r(k-i) \\ 0, & \text{otherwise} \end{cases}$$

**Step 4:**

$$\hat{b}(k) = \hat{b}(k-1) + \Delta(k) \times \frac{V(k-1)\phi(k-1)\epsilon(k)}{r(k) + \phi(k-1)V(k-1)\phi(k-1)} \quad (3.17)$$
### 3.2.3. Selective Memory Estimation

This latest algorithm introduces a profound departure from the previous two. Notably, a key innovation within this algorithm lies in its capability to turn off during periods without new information. The rationale behind incorporating this feature stems from the experimental context, where the parameter $b$ is anticipated to remain constant over extended durations, punctuated by sudden and abrupt changes like a step function. Then, we used the *Selective Memory* algorithm [57]. This algorithm updates the estimated parameter only if new information is available. By doing so, it can efficiently learn from new data points while maintaining stability and reducing unnecessary updates when the system remains relatively unchanged. Implementing this algorithm in our experimental setup could provide the best of both worlds – fast learning and adaptability when needed, combined with stability and reduced oscillations in periods of stability. This approach appears promising for addressing the specific characteristics of our future implementation into the cluster, ensuring accurate and efficient parameter estimation.

Following the new algorithm split into several stages:

**Step 0:** Defining $r(k)$ as an estimate of the variance of the unmodeled dynamics and $M_0$ as the memory length. Choose $r_0 > 0, \theta(0), V(0) > 0, 1 < M_0 < \inf$. Set $r(0) = r_0, \sigma = 1 - \frac{1}{M_0}$ and then update $k$, the new value will be $k = 1$

**Step 1:** Select a function for $r(k)$

$$r(k) = \max[\sigma \times r(k-1) + (1-\sigma) \times \epsilon(k)^2, r_0]$$

Where $\epsilon(k) = y(k) - ay(k-1) - \hat{b}(k-1)\phi(k-1)$. Recall that $\phi(k-1) = u(k-1)$.

**Step 2:** Set $B(k) = 0$ and

$$A(k) = \begin{cases} 1, & \text{if } \frac{\phi(k-1)V(k-1)\phi(k-1)}{r(k)} \ge 1/M_0 \\ 0, & \text{otherwise} \end{cases}$$

**Step 3:** If $A(k) = 0$, set:

$$B(k) = \begin{cases} 1, & \text{if } r(k) \ge \max_{1 \le i \le k} r(k-i) \\ 0, & \text{otherwise} \end{cases}$$

**Step 4:**

$$\hat{b}(k) = \hat{b}(k-1) + \Delta(k) \times \frac{V(k-1)\phi(k-1)\epsilon(k)}{r(k) + \phi(k-1)V(k-1)\phi(k-1)} \quad (3.17)$$
Step 5 :

$$V(k) = V(k-1) - \Delta(k) \times \frac{V(k-1)\phi(k-1)\phi(k-1)'V(k-1)}{r(k) + \phi(k-1)'V(k-1)\phi(k-1)} \quad (3.18)$$

First of all, we would like to clarify that the covariance matrix $V(k)$ in this new algorithm is different from the previous ones. It does not include any forgetting factor, but instead, it incorporates an estimate of the variance in the denominator. This is because the algorithm utilizes a different information matrix called the Fisher information matrix, which is defined as follows:

$$S(k) = S(k-1) + \frac{\Delta(k)}{r(k)}\phi(k-1)\phi(k-1)' \quad (3.19)$$

With this intrinsic difference highlighted, let us shed light on the last two steps of the algorithm. The update process appears similar to the previous algorithms, but this time, the updating involves the parameter $\Delta$. This parameter can only take values of 0 or 1, based on the outcomes of Step 2 and Step 3. The parameter will be updated only if $\Delta$ equals 1.

It is worth noting that this algorithm shares some similarities with the widely known dead zone algorithm [46], as both select data to use for updating the parameter. However, a key difference lies in the selection rule between the two approaches. The selective memory algorithm focuses on the degree of excitation (for parameter $A$), while the dead zone algorithm considers the prediction error, which is more sensitive to noise. Due to the noise in the system, the selective memory approach was preferred, as it handles noisy data more effectively and provides more reliable parameter estimates.

An additional aspect to consider for this algorithm is its initial condition. To ensure that the algorithm updates properly from the beginning, it's advisable to choose a larger initial covariance condition (greater than 100). Additionally, for robustness and optimal performance, it is recommended to set a small value for $r_0$ and make $M_0$ large, preferably in the range of 100 to 1000. This approach will help ensure both the reliability and effectiveness of the algorithm.

Nevertheless, the selective memory algorithm has a limitation—it may not be suitable for long-run adaptations as the parameter may converge and stop updating. To address this limitation, a re-start mechanism is implemented in the final code. When there is a modification of $f$, the algorithm is restarted to ensure it can adapt effectively to changes in the system behavior. This re-start strategy is feasible in the real system, where the condition for re-starting the algorithm would be the launch of a new campaign (as defined
Step 5 :

$$V(k) = V(k-1) - \Delta(k) \times \frac{V(k-1)\phi(k-1)\phi(k-1)'V(k-1)}{r(k) + \phi(k-1)'V(k-1)\phi(k-1)} \quad (3.18)$$

First of all, we would like to clarify that the covariance matrix $V(k)$ in this new algorithm is different from the previous ones. It does not include any forgetting factor, but instead, it incorporates an estimate of the variance in the denominator. This is because the algorithm utilizes a different information matrix called the Fisher information matrix, which is defined as follows:

$$S(k) = S(k-1) + \frac{\Delta(k)}{r(k)}\phi(k-1)\phi(k-1)' \quad (3.19)$$

With this intrinsic difference highlighted, let us shed light on the last two steps of the algorithm. The update process appears similar to the previous algorithms, but this time, the updating involves the parameter $\Delta$. This parameter can only take values of 0 or 1, based on the outcomes of Step 2 and Step 3. The parameter will be updated only if $\Delta$ equals 1.

It is worth noting that this algorithm shares some similarities with the widely known dead zone algorithm [46], as both select data to use for updating the parameter. However, a key difference lies in the selection rule between the two approaches. The selective memory algorithm focuses on the degree of excitation (for parameter $A$), while the dead zone algorithm considers the prediction error, which is more sensitive to noise. Due to the noise in the system, the selective memory approach was preferred, as it handles noisy data more effectively and provides more reliable parameter estimates.

An additional aspect to consider for this algorithm is its initial condition. To ensure that the algorithm updates properly from the beginning, it's advisable to choose a larger initial covariance condition (greater than 100). Additionally, for robustness and optimal performance, it is recommended to set a small value for $r_0$ and make $M_0$ large, preferably in the range of 100 to 1000. This approach will help ensure both the reliability and effectiveness of the algorithm.

Nevertheless, the selective memory algorithm has a limitation—it may not be suitable for long-run adaptations as the parameter may converge and stop updating. To address this limitation, a re-start mechanism is implemented in the final code. When there is a modification of $f$, the algorithm is restarted to ensure it can adapt effectively to changes in the system behavior. This re-start strategy is feasible in the real system, where the condition for re-starting the algorithm would be the launch of a new campaign (as defined
in Chapter 2.1.1).

**reinizialization function** define $V(0)$

if $new\_campaign = true$

$$V(i) = V(0)$$

## 3.3. Explicitly taking into account the HP disturbance

In the previous section, we focused on the scenario where the file server contained only BE jobs. The new section investigates a more complex setup where the file system is shared between both BE and HP jobs.

As discussed in the first chapter, these jobs follow a preemptive priority rule. In addition, it is important to note that BE and HP jobs have different impacts on the file server, with HP jobs being more resource-intensive by nature. Consequently, we introduce two distinct coefficients: $b_u$, which represents the weight of a single BE task, and $b_d$, representing the weight of a single HP job into the file system. For the nature of the system, HP tasks are considered as a disturb because are beyond our control, and $d(k)$ is the number of HP tasks in the system at time instant $k$.

The final process is described by the following equation:

$$y(k + 1) = \xi y(k) + b_u u(k) + b_d d(k) + e(k) \quad (3.20)$$

Due to the incorporation of two parameters instead of just one, there will be a consequential alteration in the dimensions of the key quantities within the algorithm. Specifically, the parameter that was initially identified will now transform into a vector encompassing two distinct parameters denoted as $b_u$ and $b_d$. Consequently, the covariance matrix will adopt a square 2x2 structure, where the values for these two parameters will be situated along the main diagonal. Correspondingly, the regression matrix will evolve into a two-element vector: the first element representing the control input, and the second element representing the disturbance (referred to as HP jobs).

Another distinction arises due to the inherent dissimilarity between the two parameters, $b_u$ and $b_d$. Specifically, the framework operates under the premise that the influence of HP tasks on the file server's workload remains consistently uniform. This constancy produces $b_d$ as a parameter that remains invariant over time. Consequently, the integration of a
in Chapter 2.1.1).

reinizialization function define $V(0)$

if new\_campaign = true

$$V(i) = V(0)$$

## 3.3. Explicitly taking into account the HP disturbance

In the previous section, we focused on the scenario where the file server contained only BE jobs. The new section investigates a more complex setup where the file system is shared between both BE and HP jobs.

As discussed in the first chapter, these jobs follow a preemptive priority rule. In addition, it is important to note that BE and HP jobs have different impacts on the file server, with HP jobs being more resource-intensive by nature. Consequently, we introduce two distinct coefficients: $b_u$, which represents the weight of a single BE task, and $b_d$, representing the weight of a single HP job into the file system. For the nature of the system, HP tasks are considered as a disturb because are beyond our control, and $d(k)$ is the number of HP tasks in the system at time instant $k$.

The final process is described by the following equation:

$$y(k + 1) = \xi y(k) + b_u u(k) + b_d d(k) + e(k) \quad (3.20)$$

Due to the incorporation of two parameters instead of just one, there will be a consequential alteration in the dimensions of the key quantities within the algorithm. Specifically, the parameter that was initially identified will now transform into a vector encompassing two distinct parameters denoted as $b_u$ and $b_d$. Consequently, the covariance matrix will adopt a square 2x2 structure, where the values for these two parameters will be situated along the main diagonal. Correspondingly, the regression matrix will evolve into a two-element vector: the first element representing the control input, and the second element representing the disturbance (referred to as HP jobs).

Another distinction arises due to the inherent dissimilarity between the two parameters, $b_u$ and $b_d$. Specifically, the framework operates under the premise that the influence of HP tasks on the file server's workload remains consistently uniform. This constancy produces $b_d$ as a parameter that remains invariant over time. Consequently, the integration of a