forgetting factor becomes unnecessary for $b_d$, as each data point must exert an identical influence on the estimation process, aligned with the parameter's unchanging nature. Conversely, for the parameter $b_u$, the scenario is distinct. In summary, the methodology involves two separate estimations: one that integrates a forgetting factor for $b_u$ to accommodate its adaptive characteristics and another that excludes a forgetting factor for $b_d$ due to its stable, time-invariant quality.

In the end the final estimated output in case of HP disturbance will be:

$$ \hat{y}(k + 1) = \xi y(k) + \hat{b}_u u(k) + \hat{b}_d d(k) \quad (3.21) $$

### 3.3.1. Limitation of the double estimation

It is important to emphasize that we will be directing the algorithm to estimate two parameters utilizing nearly identical data. However, it is anticipated that this adjustment might lead to a deterioration in the results. This is because estimating a greater number of parameters necessitates a higher degree of system excitation, which might not be fully accommodated by our system that is constrained by a constant reference.

Although we extensively examined the modifications required to adapt various algorithms for generating dual estimations and subsequently simulated their outcomes, optimizing the benefits of this dual estimation necessitates a controller adjustment that incorporates $\hat{b}_d$. Presently, the controller exclusively depends on $\hat{b}_u$, diminishing the significance of $\hat{b}_d$ estimation from the controller's perspective. This configuration could potentially complicate the algorithm's ability to effectively discern between the two identifications. This challenge becomes more pronounced when dealing with algorithms characterized by continuous learning patterns as the Parallel and the Robust.
forgetting factor becomes unnecessary for $b_d$, as each data point must exert an identical influence on the estimation process, aligned with the parameter's unchanging nature. Conversely, for the parameter $b_u$, the scenario is distinct. In summary, the methodology involves two separate estimations: one that integrates a forgetting factor for $b_u$ to accommodate its adaptive characteristics and another that excludes a forgetting factor for $b_d$ due to its stable, time-invariant quality.

In the end the final estimated output in case of HP disturbance will be:

$$ \hat{y}(k + 1) = \xi y(k) + \hat{b}_u u(k) + \hat{b}_d d(k) \quad (3.21) $$

### 3.3.1. Limitation of the double estimation

It is important to emphasize that we will be directing the algorithm to estimate two parameters utilizing nearly identical data. However, it is anticipated that this adjustment might lead to a deterioration in the results. This is because estimating a greater number of parameters necessitates a higher degree of system excitation, which might not be fully accommodated by our system that is constrained by a constant reference.

Although we extensively examined the modifications required to adapt various algorithms for generating dual estimations and subsequently simulated their outcomes, optimizing the benefits of this dual estimation necessitates a controller adjustment that incorporates $\hat{b}_d$. Presently, the controller exclusively depends on $\hat{b}_u$, diminishing the significance of $\hat{b}_d$ estimation from the controller's perspective. This configuration could potentially complicate the algorithm's ability to effectively discern between the two identifications. This challenge becomes more pronounced when dealing with algorithms characterized by continuous learning patterns as the Parallel and the Robust.
# 4 | Validation of Algorithms

This chapter is dedicated to assessing the impact of the three previously discussed algorithms on the system. To gain insight into their performance characteristics, these algorithms underwent preliminary testing within a simulation framework. This allowed us to discern the strengths and weaknesses of each algorithm. Subsequently, we proceeded to evaluate these algorithms within the actual system. It is important to note that, for reasons explained in the following sections, only one algorithm will be discussed in the real system.

Within the second part of this chapter, we address the selection of optimal initial conditions, followed by a validation process with *f* which changes runtime. Finally, we will conclude with a comparative analysis between the PI and the Adaptive PI, considering various values of *f*.

## 4.1. Validation in Simulation

For the simulation frame all the system and algorithms were established inside the Simulink frame with a discrete solver with a constant step equal to 30 seconds. Each simulation represents the outcome derived from an average of five experiments. This approach is adopted to mitigate the influence of system noise. The initial phase involves tuning the algorithm to ensure a consistent basis for result comparison. Subsequently, a comparative analysis of output will be conducted under two distinct conditions: one without HP jobs, and the other involving the presence of HP jobs.

### 4.1.1. Choice of parameters: $\alpha$

In order to facilitate a comparative analysis of various algorithms within the Simulink framework, one has to commence by fine-tuning the algorithm's parameters. In this context, the focus shall primarily be on refining the smoothing parameter $\alpha$ of the Robust Algorithm. This decision stems from the fact that the remaining parameters exhibit negligible influence on outcomes within the simulation environment. However, it is worth noting that in the experimental configuration, the results are intricately tied to the se-
# 4 | Validation of Algorithms

This chapter is dedicated to assessing the impact of the three previously discussed algorithms on the system. To gain insight into their performance characteristics, these algorithms underwent preliminary testing within a simulation framework. This allowed us to discern the strengths and weaknesses of each algorithm. Subsequently, we proceeded to evaluate these algorithms within the actual system. It is important to note that, for reasons explained in the following sections, only one algorithm will be discussed in the real system.

Within the second part of this chapter, we address the selection of optimal initial conditions, followed by a validation process with *f* which changes runtime. Finally, we will conclude with a comparative analysis between the PI and the Adaptive PI, considering various values of *f*.

## 4.1. Validation in Simulation

For the simulation frame all the system and algorithms were established inside the Simulink frame with a discrete solver with a constant step equal to 30 seconds. Each simulation represents the outcome derived from an average of five experiments. This approach is adopted to mitigate the influence of system noise. The initial phase involves tuning the algorithm to ensure a consistent basis for result comparison. Subsequently, a comparative analysis of output will be conducted under two distinct conditions: one without HP jobs, and the other involving the presence of HP jobs.

### 4.1.1. Choice of parameters: $\alpha$

In order to facilitate a comparative analysis of various algorithms within the Simulink framework, one has to commence by fine-tuning the algorithm's parameters. In this context, the focus shall primarily be on refining the smoothing parameter $\alpha$ of the Robust Algorithm. This decision stems from the fact that the remaining parameters exhibit negligible influence on outcomes within the simulation environment. However, it is worth noting that in the experimental configuration, the results are intricately tied to the se-
lection of these two values. In this case, the specific choices for these parameters were established as $\hat{b}(0) = 0.03$ and $V(0) = 100$. Notably, the initial covariance condition was set to a relatively elevated value. This choice was made due to the inverse relationship between the magnitude of this value and the reliability of the initial condition of $\hat{b}$. While the forgetting factor is $[0.5,0.6,0.7,0.8,0.9,1]'$, we select a minimum of 0.5 due to the noise of the system.

To choose the best possible $\alpha$, a dedicated experiment is devised. This experimental design involved maintaining a constant reference of three for the output, coupled with the introduction of a time-varying $b$. To closely emulate the forthcoming experimental setup, a step function was adopted. This choice was deliberate, aligning with the experimental procedure where adjustments to parameter $b$ necessitate the initiation of separate job campaigns with distinct $f$ values. The step function was deemed appropriate due to its congruence with this process. Furthermore, the included visual depiction is an aggregate of outcomes from five distinct experiments. This consolidation was necessary in light of inherent sensor noise.

Subsequently, the resulting outcomes of the Robust Algorithm are depicted in the following pictures, showcasing the effects of varying $\alpha$ values in the range of 0.5 to 3, with increments of 0.5. The blue line represents the behavior of $\hat{b}$, while the red dashed line illustrates the behavior of $\tilde{b}$. An observable trend is that as $\alpha$ increases, oscillations within the estimation diminish. However, this improvement comes at the cost of a notable deceleration in the estimation process with higher values of the parameter. This is more clear in the final row, where a step-down change in the true parameter induces a significant gap between the red and blue lines. This gap signifies reduced agility of the algorithm in tracking the true time-varying parameter compared to the first row.
lection of these two values. In this case, the specific choices for these parameters were established as $\hat{b}(0) = 0.03$ and $V(0) = 100$. Notably, the initial covariance condition was set to a relatively elevated value. This choice was made due to the inverse relationship between the magnitude of this value and the reliability of the initial condition of $\hat{b}$. While the forgetting factor is $[0.5,0.6,0.7,0.8,0.9,1]'$, we select a minimum of 0.5 due to the noise of the system.

To choose the best possible $\alpha$, a dedicated experiment is devised. This experimental design involved maintaining a constant reference of three for the output, coupled with the introduction of a time-varying $b$. To closely emulate the forthcoming experimental setup, a step function was adopted. This choice was deliberate, aligning with the experimental procedure where adjustments to parameter $b$ necessitate the initiation of separate job campaigns with distinct $f$ values. The step function was deemed appropriate due to its congruence with this process. Furthermore, the included visual depiction is an aggregate of outcomes from five distinct experiments. This consolidation was necessary in light of inherent sensor noise.

Subsequently, the resulting outcomes of the Robust Algorithm are depicted in the following pictures, showcasing the effects of varying $\alpha$ values in the range of 0.5 to 3, with increments of 0.5. The blue line represents the behavior of $\hat{b}$, while the red dashed line illustrates the behavior of $\tilde{b}$. An observable trend is that as $\alpha$ increases, oscillations within the estimation diminish. However, this improvement comes at the cost of a notable deceleration in the estimation process with higher values of the parameter. This is more clear in the final row, where a step-down change in the true parameter induces a significant gap between the red and blue lines. This gap signifies reduced agility of the algorithm in tracking the true time-varying parameter compared to the first row.
<figure><img src="image_29.png" /><figcaption>Figure 4.1: Identification results for varying $\alpha$ in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to $\hat{b}$, while the red dashed line corresponds to $\tilde{b}$.</figcaption></figure>

On the other hand, the impact of $\alpha$ appears negligible in the tracking aspect. In this depiction, it might appear that the initial load of the file server approximates 1, but this is not the case. Despite the starting condition being 0, the noise level appears pronounced. The choice of presenting the average of five experiments is deliberate, even though the noise isn't fully mitigated. This decision aligns with the intention to maintain consistency with the forthcoming real-world setup.

<figure><img src="image_30.png" /><figcaption>Figure 4.2: Tracking results for varying $\alpha$ in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to $y$, while the red dashed line corresponds to $y_{ref}$.</figcaption></figure>
<figure><img src="image_29.png" /><figcaption>Figure 4.1: Identification results for varying $\alpha$ in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to $\hat{b}$, while the red dashed line corresponds to $\tilde{b}$.</figcaption></figure>

On the other hand, the impact of $\alpha$ appears negligible in the tracking aspect. In this depiction, it might appear that the initial load of the file server approximates 1, but this is not the case. Despite the starting condition being 0, the noise level appears pronounced. The choice of presenting the average of five experiments is deliberate, even though the noise isn't fully mitigated. This decision aligns with the intention to maintain consistency with the forthcoming real-world setup.

<figure><img src="image_30.png" /><figcaption>Figure 4.2: Tracking results for varying $\alpha$ in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to $y$, while the red dashed line corresponds to $y_{ref}$.</figcaption></figure>
To gain a more insightful understanding of the impact of α on the performances, we computed boxplots to depict the relative percentage error in absolute value for both the identification error ($\tilde{b} - \hat{b}$) and the tracking error. The boxplots in Figure 4.3 provide a visual representation of the distribution of the results and allow us to compare the performance with different values of α. Upon analyzing picture (a), one can note that the error decreases by increasing the parameter α, however, in the case of α = 3, it appears that the boxplot starts to expand attributable to the slowdown. On the other hand, picture (b) in 4.3 confirms the idea that α does not have a strong impact on the output. Taking into account only the boxplot result, we find the results for α values above and equal 1.5 to be particularly satisfactory, indeed 75% of data have a relative percentage error of 10% or less. However looking at Figure 4.1 it is clear that the last two cases present a slowdown that cannot be ignored. Considering the trade-off between relative error and slowdown, we would recommend selecting α = 2 as it seems to provide a favorable compromise between smoothness and adaptability to time-varying parameters.

<figure><img src="image_31.png" /><figcaption>Figure 4.3: Boxplots depicting the relative percentage error in absolute value across various α values. (a) Shows the identification error, while (b) shows the tracking error.</figcaption></figure>

### 4.1.2. Comparison of algorithms

In the preceding section, we examined the diverse outcomes associated with varying values of α. Having established our choice of alpha, we can now proceed to observe the distinct results achieved by applying the three algorithms. The Parallel and Robust Algorithms have as $\hat{b}(0) = 0.03$, $V(0) = 100$, $\mu = [0.5, 0.6, 0.7, 0.8, 0.9, 1]'$ while the initial conditions for the Selective algorithm are $r(0) = 10^{-3}$, $M_0 = 100$, $\hat{b}(0) = 0.03$ and $V(0) = 100$, where values of the Selective are the ones suggested in [57]. Illustrated in Figure 4.5, we present the identification results for three specific cases. The leftmost plot corresponds to the Parallel Algorithm, the middle plot represents the Robust Algorithm with $\alpha = 2$, and the final plot showcases the outcome of the Selective Algorithm. A noticeable trend emerges from left to right: a consistent reduction in oscillations across all cases. This
To gain a more insightful understanding of the impact of α on the performances, we computed boxplots to depict the relative percentage error in absolute value for both the identification error ($\tilde{b} - \hat{b}$) and the tracking error. The boxplots in Figure 4.3 provide a visual representation of the distribution of the results and allow us to compare the performance with different values of α. Upon analyzing picture (a), one can note that the error decreases by increasing the parameter α, however, in the case of α = 3, it appears that the boxplot starts to expand attributable to the slowdown. On the other hand, picture (b) in 4.3 confirms the idea that α does not have a strong impact on the output. Taking into account only the boxplot result, we find the results for α values above and equal 1.5 to be particularly satisfactory, indeed 75% of data have a relative percentage error of 10% or less. However looking at Figure 4.1 it is clear that the last two cases present a slowdown that cannot be ignored. Considering the trade-off between relative error and slowdown, we would recommend selecting α = 2 as it seems to provide a favorable compromise between smoothness and adaptability to time-varying parameters.

<figure><img src="image_31.png" /><figcaption>Figure 4.3: Boxplots depicting the relative percentage error in absolute value across various α values. (a) Shows the identification error, while (b) shows the tracking error.</figcaption></figure>

### 4.1.2. Comparison of algorithms

In the preceding section, we examined the diverse outcomes associated with varying values of α. Having established our choice of alpha, we can now proceed to observe the distinct results achieved by applying the three algorithms. The Parallel and Robust Algorithms have as $\hat{b}(0) = 0.03$, $V(0) = 100$, $\mu = [0.5, 0.6, 0.7, 0.8, 0.9, 1]'$ while the initial conditions for the Selective algorithm are $r(0) = 10^{-3}$, $M_0 = 100$, $\hat{b}(0) = 0.03$ and $V(0) = 100$, where values of the Selective are the ones suggested in [57]. Illustrated in Figure 4.5, we present the identification results for three specific cases. The leftmost plot corresponds to the Parallel Algorithm, the middle plot represents the Robust Algorithm with $\alpha = 2$, and the final plot showcases the outcome of the Selective Algorithm. A noticeable trend emerges from left to right: a consistent reduction in oscillations across all cases. This
reduction is a direct consequence of the implementation of the Robust algorithm, tailored
to mitigate the influence of noise through the adjustment of the parameter $\alpha$. Conversely,
the Selective algorithm incorporates a memory mechanism that restricts learning over a
finite period, which explains the observed stabilization of the identification results beyond
a certain time frame. The presence of overshooting and undershooting phenomena can
be attributed to the algorithm's re-initialization process.

Instead of tracking there seem to be no noticeable improvements, probably because the
impact of the noise is bigger than the one of $\hat{b}$.

<figure><img src="image_32.png" /><figcaption>Figure 4.4: Identification results. $\hat{b}$ is shown in blue line, and $\tilde{b}$ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

<figure><img src="image_33.png" /><figcaption>Figure 4.5: Tracking results. $y$ is shown in blue line, and $y_{ref}$ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

To substantiate the efficacy of the Selective Algorithm and ascertain potential improve-
ments in terms of tracking performance, we have incorporated three distinct box plots for
the identification and the tracking error into the analysis. These box plots aim to offer
valuable insights into the distribution of relative percentage errors in absolute values.
reduction is a direct consequence of the implementation of the Robust algorithm, tailored
to mitigate the influence of noise through the adjustment of the parameter $\alpha$. Conversely,
the Selective algorithm incorporates a memory mechanism that restricts learning over a
finite period, which explains the observed stabilization of the identification results beyond
a certain time frame. The presence of overshooting and undershooting phenomena can
be attributed to the algorithm's re-initialization process.

Instead of tracking there seem to be no noticeable improvements, probably because the
impact of the noise is bigger than the one of $\hat{b}$.

<figure><img src="image_32.png" /><figcaption>Figure 4.4: Identification results. $\hat{b}$ is shown in blue line, and $\tilde{b}$ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

<figure><img src="image_33.png" /><figcaption>Figure 4.5: Tracking results. $y$ is shown in blue line, and $y_{ref}$ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

To substantiate the efficacy of the Selective Algorithm and ascertain potential improve-
ments in terms of tracking performance, we have incorporated three distinct box plots for
the identification and the tracking error into the analysis. These box plots aim to offer
valuable insights into the distribution of relative percentage errors in absolute values.
<figure><img src="image_34.png" /><figcaption>Figure 4.6: Each boxplot represents the relative percentage error in absolute value for each algorithm. (a) Represents the identification error, and (b) represents the tracking error.</figcaption></figure>

By incorporating this statistical visualization, we can delve more deeply into the performance of the algorithms. The results presented in (a) of Figure 4.6 provide strong evidence supporting our assertion that the final algorithm we present is optimal in terms of identification capabilities. This assertion is reinforced by the significant reduction in error observed when transitioning from the Parallel Algorithm to the Selective Algorithm. To elaborate, the initial algorithm reveals that 75% of the data points exhibit a relative percentage error below 15%. However, with the Selective Algorithm, an equivalent proportion of data points exhibit errors below 5%. This distinct shift in the distribution of errors serves to underscore the markedly superior performance of the Selective Algorithm from the identification standpoint.

On the contrary, in graph (b) of Figure 4.6, a significant shift occurred. The Selective Algorithm, which previously occupied the first position, has now been superseded by the Robust Algorithm. In fact, looking at the error values in the graph (b) of figure 4.6, one can see that the Robust error values are smaller than the other algorithms. It is worth noting that performance disparities among algorithms are not as strong as in the case of Figure (a). This suggests that the algorithms show relatively similar levels of tracking performance, with less pronounced differences between them. The similarity in tracking errors among the results can be attributed to the findings presented in the tuning section. This analysis revealed that the influence of noise surpasses the impact of $\hat{b}$ in the controller. To gain deeper insights into the role of identification within the output, further simulations are warranted. In this work, we have selected a set of five experiments to gain consistency with the forthcoming experimental setup section.

Ultimately, considering the outcomes, one can note that the Selective Algorithm achieves
<figure><img src="image_34.png" /><figcaption>Figure 4.6: Each boxplot represents the relative percentage error in absolute value for each algorithm. (a) Represents the identification error, and (b) represents the tracking error.</figcaption></figure>

By incorporating this statistical visualization, we can delve more deeply into the performance of the algorithms. The results presented in (a) of Figure 4.6 provide strong evidence supporting our assertion that the final algorithm we present is optimal in terms of identification capabilities. This assertion is reinforced by the significant reduction in error observed when transitioning from the Parallel Algorithm to the Selective Algorithm. To elaborate, the initial algorithm reveals that 75% of the data points exhibit a relative percentage error below 15%. However, with the Selective Algorithm, an equivalent proportion of data points exhibit errors below 5%. This distinct shift in the distribution of errors serves to underscore the markedly superior performance of the Selective Algorithm from the identification standpoint.

On the contrary, in graph (b) of Figure 4.6, a significant shift occurred. The Selective Algorithm, which previously occupied the first position, has now been superseded by the Robust Algorithm. In fact, looking at the error values in the graph (b) of figure 4.6, one can see that the Robust error values are smaller than the other algorithms. It is worth noting that performance disparities among algorithms are not as strong as in the case of Figure (a). This suggests that the algorithms show relatively similar levels of tracking performance, with less pronounced differences between them. The similarity in tracking errors among the results can be attributed to the findings presented in the tuning section. This analysis revealed that the influence of noise surpasses the impact of $\hat{b}$ in the controller. To gain deeper insights into the role of identification within the output, further simulations are warranted. In this work, we have selected a set of five experiments to gain consistency with the forthcoming experimental setup section.

Ultimately, considering the outcomes, one can note that the Selective Algorithm achieves
superior results in the identification phase compared to the other algorithms. However, in the context of tracking, the algorithm for achieving the most favorable outcomes remains uncertain. Given these observations, we are inclined to conclude that the Selective algorithm stands as the most favorable choice among the three.

### 4.1.3. Case with HP disturbance

In this section, the algorithms are tasked with evaluating two distinct parameters, which have been elucidated in chapter 3.3 - $b_u$ and $b_d$. Consequently, the experimental setup in this scenario differs slightly from the other case. Specifically, we have extended the simulation duration to provide ample time for disturbance setup. Notably, while the profile of the variation in $b_u$ remains consistent, the approach for $b_d$ is different, as it remains constant at 0.30. To implement this, we designated the disturbance to manifest as an abrupt step change at 2000 seconds, persisting until 4000 seconds.

The visual representation in Figure 4.8 may suggest a continuous presence of the disturbance. This is due to the algorithm's characteristic behavior, which retains its previous computation even after the disturbance ceases. This perspective is pivotal in understanding the identification of $b_d$. The algorithm preserves its last computed value, leading to the red dashed line's persistence at the end of the disturbance interval.

<figure><img src="image_35.png" /><figcaption>Figure 4.7: The three algorithms' identification results: $\hat{b}_u$ is shown in blue line, and $b_u$ in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>
superior results in the identification phase compared to the other algorithms. However, in the context of tracking, the algorithm for achieving the most favorable outcomes remains uncertain. Given these observations, we are inclined to conclude that the Selective algorithm stands as the most favorable choice among the three.

### 4.1.3. Case with HP disturbance

In this section, the algorithms are tasked with evaluating two distinct parameters, which have been elucidated in chapter 3.3 - $b_u$ and $b_d$. Consequently, the experimental setup in this scenario differs slightly from the other case. Specifically, we have extended the simulation duration to provide ample time for disturbance setup. Notably, while the profile of the variation in $b_u$ remains consistent, the approach for $b_d$ is different, as it remains constant at 0.30. To implement this, we designated the disturbance to manifest as an abrupt step change at 2000 seconds, persisting until 4000 seconds.

The visual representation in Figure 4.8 may suggest a continuous presence of the disturbance. This is due to the algorithm's characteristic behavior, which retains its previous computation even after the disturbance ceases. This perspective is pivotal in understanding the identification of $b_d$. The algorithm preserves its last computed value, leading to the red dashed line's persistence at the end of the disturbance interval.

<figure><img src="image_35.png" /><figcaption>Figure 4.7: The three algorithms' identification results: $\hat{b}_u$ is shown in blue line, and $b_u$ in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>
<figure><img src="image_36.png" /><figcaption>Figure 4.8: The three algorithms’ identification results are displayed: $\hat{b}_d$ is shown in blue line, and $b_d$ in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

In Figure 4.7, the obtained result closely aligns with the preceding one. As depicted from left to right, a discernible reduction in oscillation becomes evident, and the Selective Algorithm maintains its prominent position. Furthermore, this scenario illuminates the influence of the disturbance on the calculation of $b_u$. Both the Parallel and Robust Algorithms fail to completely segregate the two calculations. Consequently, upon the disturbance’s introduction, a perturbation emerges in the computation of $\hat{b}_u$ even in the absence of alterations to this parameter. This issue subsequently ripples into the determination of $\hat{b}_d$ as well. Specifically, in Figures (a) and (b) of 4.8, one can readily observe the underestimation of the actual parameter. This phenomenon appears to arise from the overestimation of $b_u$ coinciding with the arrival of the disturbance. The updating depends on the disparity between the measured and estimated output, as depicted by:

$$ \epsilon(k + 1) = y(k + 1) - \xi y(k) - \hat{b}_u(k)u(k) - \hat{b}_d(k)d(k) \quad (4.1) $$

Then, an overestimation of $\hat{b}_u$ precipitates an inherent underestimation of $\hat{b}_d$. Furthermore, this overestimation could be attributed to the influence of $\hat{b}_u$ within the controller’s framework. The rationale lies in the fact that elevating $\hat{b}_u$ leads to a corresponding reduction in the control action—an essential adjustment considering the file server’s evolving responsibility of handling both HP and BE tasks. Conversely, the parameter $\hat{b}_d$ wields no influence over the control process.

In the context of Figure (c) within 4.7, the timing of disturbance introduction becomes less apparent. This outcome stems from the distinct learning rate characteristic of the selective algorithm. Unlike the preceding algorithms that always refine their estimates, this algorithm exclusively learns upon activation, as stipulated by the triggering condition we have imposed. Given this condition, $\hat{b}_u$ remains static unless alterations occur within the BE campaign. As a result, the $\hat{b}_u$ remains unaffected by the arrival of HP jobs, effectively avoiding their influence.
<figure><img src="image_36.png" /><figcaption>Figure 4.8: The three algorithms’ identification results are displayed: $\hat{b}_d$ is shown in blue line, and $b_d$ in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

In Figure 4.7, the obtained result closely aligns with the preceding one. As depicted from left to right, a discernible reduction in oscillation becomes evident, and the Selective Algorithm maintains its prominent position. Furthermore, this scenario illuminates the influence of the disturbance on the calculation of $b_u$. Both the Parallel and Robust Algorithms fail to completely segregate the two calculations. Consequently, upon the disturbance’s introduction, a perturbation emerges in the computation of $\hat{b}_u$ even in the absence of alterations to this parameter. This issue subsequently ripples into the determination of $\hat{b}_d$ as well. Specifically, in Figures (a) and (b) of 4.8, one can readily observe the underestimation of the actual parameter. This phenomenon appears to arise from the overestimation of $b_u$ coinciding with the arrival of the disturbance. The updating depends on the disparity between the measured and estimated output, as depicted by:

$$ \epsilon(k + 1) = y(k + 1) - \xi y(k) - \hat{b}_u(k)u(k) - \hat{b}_d(k)d(k) \quad (4.1) $$

Then, an overestimation of $\hat{b}_u$ precipitates an inherent underestimation of $\hat{b}_d$. Furthermore, this overestimation could be attributed to the influence of $\hat{b}_u$ within the controller’s framework. The rationale lies in the fact that elevating $\hat{b}_u$ leads to a corresponding reduction in the control action—an essential adjustment considering the file server’s evolving responsibility of handling both HP and BE tasks. Conversely, the parameter $\hat{b}_d$ wields no influence over the control process.

In the context of Figure (c) within 4.7, the timing of disturbance introduction becomes less apparent. This outcome stems from the distinct learning rate characteristic of the selective algorithm. Unlike the preceding algorithms that always refine their estimates, this algorithm exclusively learns upon activation, as stipulated by the triggering condition we have imposed. Given this condition, $\hat{b}_u$ remains static unless alterations occur within the BE campaign. As a result, the $\hat{b}_u$ remains unaffected by the arrival of HP jobs, effectively avoiding their influence.
In Figure 4.9, the tracking result is presented, superimposed with the impact of the HP jobs over time, indicated by the dashed black line. As the case of a single parameter, the distinction between the effects of different algorithms in the tracking is less evident. Furthermore, an observation of significance arises when examining the moment of disturbance introduction into the system; specifically, a heightened impact is noticeable upon the disturbance's arrival, in contrast to the case of its disappearance.

<figure><img src="image_37.png" /><figcaption>Figure 4.9: The three tracking results are displayed: $y$ is shown in blue line, and $y_{ref}$ in red dashed line, and the impact of HP jobs is depicted in black dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

## 4.2. Evaluation with experiments on the real platform

Only the Robust Algorithm will be implemented on the actual platform. The decision to exclude the Parallel Algorithm from implementation is rooted in the insights provided in Chapter 3. As demonstrated, the Robust algorithm represents an evolution of the Parallel Algorithm, sharing a common underlying structure. However, the Robust Algorithm specifically addresses the limitation of noise impact.

Regarding the Selective Algorithm, its omission is not a matter of preference but rather a consequence of observed behavior misalignment with initial expectations. The system encounters a delay during initiation, a factor not accounted for in the original model. This delay poses a significant challenge for the Selective Algorithm due to its narrow learning window. As a result, the algorithm prematurely halts its learning process, yielding suboptimal estimations. Efforts to mitigate this issue through alterations in initial conditions were unsuccessful in resolving the problem.

Another deviation from the simulation phase arises due to time constraints, preventing the implementation and real-platform testing of estimations for the two distinct parameters. Consequently, the forthcoming sections will exclusively present the estimation of only one parameter. Nevertheless, the disturbance will be introduced following the same
In Figure 4.9, the tracking result is presented, superimposed with the impact of the HP jobs over time, indicated by the dashed black line. As the case of a single parameter, the distinction between the effects of different algorithms in the tracking is less evident. Furthermore, an observation of significance arises when examining the moment of disturbance introduction into the system; specifically, a heightened impact is noticeable upon the disturbance's arrival, in contrast to the case of its disappearance.

<figure><img src="image_37.png" /><figcaption>Figure 4.9: The three tracking results are displayed: $y$ is shown in blue line, and $y_{ref}$ in red dashed line, and the impact of HP jobs is depicted in black dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</figcaption></figure>

## 4.2. Evaluation with experiments on the real platform

Only the Robust Algorithm will be implemented on the actual platform. The decision to exclude the Parallel Algorithm from implementation is rooted in the insights provided in Chapter 3. As demonstrated, the Robust algorithm represents an evolution of the Parallel Algorithm, sharing a common underlying structure. However, the Robust Algorithm specifically addresses the limitation of noise impact.

Regarding the Selective Algorithm, its omission is not a matter of preference but rather a consequence of observed behavior misalignment with initial expectations. The system encounters a delay during initiation, a factor not accounted for in the original model. This delay poses a significant challenge for the Selective Algorithm due to its narrow learning window. As a result, the algorithm prematurely halts its learning process, yielding suboptimal estimations. Efforts to mitigate this issue through alterations in initial conditions were unsuccessful in resolving the problem.

Another deviation from the simulation phase arises due to time constraints, preventing the implementation and real-platform testing of estimations for the two distinct parameters. Consequently, the forthcoming sections will exclusively present the estimation of only one parameter. Nevertheless, the disturbance will be introduced following the same
methodology outlined in the previous section. It will be subsequently demonstrated that
$\hat{b}$ serves the dual purpose of estimating the disturbance as well.

4.2.1. Experimental setup

In this master thesis, we focus on utilizing one of the clusters available at Nancy, specifi-
cally Grisou. Grisou comprises 46 nodes, each equipped with 2 CPU Intel Xeon E5-2630
v3. Each CPU contains 8 cores, resulting in a total of 16 cores per node [58]. For our
experiments, we reserved 4 nodes, with each node serving a specific role: one for the
controller CIGRI, one for the scheduler OAR, one for simulating the cluster itself, and
the last one for simulating the file system. The experiments are conducted using the
programming language *Ruby* on a Linux platform.

Due to the limitation on booking the entire cluster, we needed to find an alternative ap-
proach to conduct large-scale experiments. The inspiration for our solution comes from
the article [59], which proposes the use of a *sleep mode*. With this approach, the clus-
ter does not actively compute the jobs; instead, the jobs wait for a specific amount of
time within the cluster. By doing so, the computing power of a single CPU can be ef-
ficiently utilized to host several jobs in sleep mode. This allows us to treat the single
*physical resource* as multiple *virtual resources*. In our context, physical resources refer
to the physical nodes, while virtual resources denote the number of resources from the
perspective of OAR. The sleep mode duration is set to match the period of CIGRI for
simplicity.

In this section, we intend to highlight the significant challenges associated with the actual
platform. These challenges serve to provide rationale for conducting only five experiments
for each simulation iteration. It is important to note that the execution time of a single
experiment spans several hours. Consequently, limitations stemming from the user pol-
icy prevent us from conducting simulations in quantities of our choosing. Furthermore,
each experiment is subject to pronounced heterogeneity due to variations in the utilized
nodes and the scheduler employed. Specifically, the scheduler utilized in the experiments
represents an updated version of the one currently deployed in the cluster. Regrettably,
this scheduler component is prone to overload occurrences with insufficiently clear justifi-
cations, largely attributed to its *beta* version status which renders it susceptible to bugs.
Having established the simulation of the cluster, we now turn our attention to the simula-
tion of the file server. In light of the main objective of this thesis - the overloading of the
file server, in the experiments we use a real file server with some approximations. Indeed
considering that the real bottleneck of this system is the writing task, in the experiment
the fill of the file system will represent only this process. This is justified by the lighter
methodology outlined in the previous section. It will be subsequently demonstrated that
$\hat{b}$ serves the dual purpose of estimating the disturbance as well.

4.2.1. Experimental setup

In this master thesis, we focus on utilizing one of the clusters available at Nancy, specifi-
cally Grisou. Grisou comprises 46 nodes, each equipped with 2 CPU Intel Xeon E5-2630
v3. Each CPU contains 8 cores, resulting in a total of 16 cores per node [58]. For our
experiments, we reserved 4 nodes, with each node serving a specific role: one for the
controller CIGRI, one for the scheduler OAR, one for simulating the cluster itself, and
the last one for simulating the file system. The experiments are conducted using the
programming language *Ruby* on a Linux platform.

Due to the limitation on booking the entire cluster, we needed to find an alternative ap-
proach to conduct large-scale experiments. The inspiration for our solution comes from
the article [59], which proposes the use of a *sleep mode*. With this approach, the clus-
ter does not actively compute the jobs; instead, the jobs wait for a specific amount of
time within the cluster. By doing so, the computing power of a single CPU can be ef-
ficiently utilized to host several jobs in sleep mode. This allows us to treat the single
*physical resource* as multiple *virtual resources*. In our context, physical resources refer
to the physical nodes, while virtual resources denote the number of resources from the
perspective of OAR. The sleep mode duration is set to match the period of CIGRI for
simplicity.

In this section, we intend to highlight the significant challenges associated with the actual
platform. These challenges serve to provide rationale for conducting only five experiments
for each simulation iteration. It is important to note that the execution time of a single
experiment spans several hours. Consequently, limitations stemming from the user pol-
icy prevent us from conducting simulations in quantities of our choosing. Furthermore,
each experiment is subject to pronounced heterogeneity due to variations in the utilized
nodes and the scheduler employed. Specifically, the scheduler utilized in the experiments
represents an updated version of the one currently deployed in the cluster. Regrettably,
this scheduler component is prone to overload occurrences with insufficiently clear justifi-
cations, largely attributed to its *beta* version status which renders it susceptible to bugs.
Having established the simulation of the cluster, we now turn our attention to the simula-
tion of the file server. In light of the main objective of this thesis - the overloading of the
file server, in the experiments we use a real file server with some approximations. Indeed
considering that the real bottleneck of this system is the writing task, in the experiment
the fill of the file system will represent only this process. This is justified by the lighter
impact of the other two operations of the file system, namely reading and storing.

4.2.2. Initial parameter condition

Initial Condition for $\hat{b}$

Now that we have the opportunity to assess the algorithms within the actual experimental framework, we can also explore alternative optimal initial conditions. Our first objective is to determine the optimal $\hat{b}_0$ value. In order to structure the experiments, a singular campaign was devised, resulting in a fixed data volume of $f = 200$ MBytes. During the testing phase, three distinct initial conditions were employed: 0.5, 0.15, and 0.03. The selection of the initial condition of 0.5 facilitates a less aggressive control action, as both $K_p$ and $K_I$ are contingent on the inverse of the estimation. In the case of $\hat{b}(0) = 0.15$, we opted to assign a value equivalent to $\tilde{b}$. Lastly, for the third initial condition, we utilized the value previously employed in the simulation setup. This approach aims to investigate the impact of different initial conditions on the algorithm's performance within a real-world context.

<figure><img src="image_38.png" /><figcaption>Figure 4.10: Results with different initial conditions. In row (a), we examine the scenario where $\hat{b}(0) = 0.5$, while in row (b), we observe the case where $\hat{b}(0) = 0.15$.</figcaption></figure>

One can see from Figure 4.10 that the simulation comprises only two cases, deviating from the initially anticipated three simulations. This unexpected outcome arises due to the simulation halting when $\hat{b}(0) = 0.03$. This particular circumstance was not predicted in advance, as the existing model of the file server fails to account for the initial delay for the system to turn on.

As illustrated in Figure 4.11, the value of $\hat{b}$ initially decreases, mirroring the behavior observed in the other two experiments. However, due to the initial small value of $\hat{b}$, the control action rapidly escalates to an extremely high value, notably 100. This corresponds
impact of the other two operations of the file system, namely reading and storing.

4.2.2. Initial parameter condition

Initial Condition for $\hat{b}$

Now that we have the opportunity to assess the algorithms within the actual experimental framework, we can also explore alternative optimal initial conditions. Our first objective is to determine the optimal $\hat{b}_0$ value. In order to structure the experiments, a singular campaign was devised, resulting in a fixed data volume of $f = 200$ MBytes. During the testing phase, three distinct initial conditions were employed: 0.5, 0.15, and 0.03. The selection of the initial condition of 0.5 facilitates a less aggressive control action, as both $K_p$ and $K_I$ are contingent on the inverse of the estimation. In the case of $\hat{b}(0) = 0.15$, we opted to assign a value equivalent to $\tilde{b}$. Lastly, for the third initial condition, we utilized the value previously employed in the simulation setup. This approach aims to investigate the impact of different initial conditions on the algorithm's performance within a real-world context.

<figure><img src="image_38.png" /><figcaption>Figure 4.10: Results with different initial conditions. In row (a), we examine the scenario where $\hat{b}(0) = 0.5$, while in row (b), we observe the case where $\hat{b}(0) = 0.15$.</figcaption></figure>

One can see from Figure 4.10 that the simulation comprises only two cases, deviating from the initially anticipated three simulations. This unexpected outcome arises due to the simulation halting when $\hat{b}(0) = 0.03$. This particular circumstance was not predicted in advance, as the existing model of the file server fails to account for the initial delay for the system to turn on.

As illustrated in Figure 4.11, the value of $\hat{b}$ initially decreases, mirroring the behavior observed in the other two experiments. However, due to the initial small value of $\hat{b}$, the control action rapidly escalates to an extremely high value, notably 100. This corresponds
to an instance where, within a single time step, the CIGRI system dispatches an excessive 100 BE jobs. Consequently, the file server load surpasses the value of 8 (where the overloading experience starts with the value of 7), when the reference value stands at three. At this juncture, a cascade of issues emerges. With the file server experiencing overload conditions, it initiates a self-preservation mechanism, resulting in system-wide deceleration. Consequently, the number of jobs in the waiting queue surges, further compounding the system's slowdown due to the scheduler's responsiveness being inversely proportional to the queue's length. Evidently, the value of $\hat{b}(0) = 0.03$ proves to be unviable within the real-world setup, as it triggers a series of unfavorable events leading to system performance degradation. This underscores the complexity and unpredictability of system behavior under certain initial conditions.

<figure><img src="image_39.png" /><figcaption>Figure 4.11: Results for the scenario where $\hat{b}(0) = 0.03$. The blue line represents the average across five distinct experiments. Within the estimation visualization, the red dashed line corresponds to $\tilde{b}$, while in the file server load illustration, the red dashed line signifies the reference load.</figcaption></figure>

Now, focusing our attention back on Figure 4.10, we can discern a consistent pattern in both cases: an initial decrease in the estimated value. This insight has been gleaned from the experimentation process. It has come to light that the system requires a certain amount of time to initiate, manifesting as an initial delay. This delay subsides after the first 3-4 time steps. However, owing to this initial delay, the estimation is notably underestimated during this phase. This underscores the reason why opting for an excessively small initial condition for $\hat{b}(0)$ is inadvisable. The consequences of this underestimation are twofold. Firstly, it results in an overshoot in the control action. Notably, the overshoot is more pronounced in Figure (b), primarily due to the estimated value reaching lower
to an instance where, within a single time step, the CIGRI system dispatches an excessive 100 BE jobs. Consequently, the file server load surpasses the value of 8 (where the overloading experience starts with the value of 7), when the reference value stands at three. At this juncture, a cascade of issues emerges. With the file server experiencing overload conditions, it initiates a self-preservation mechanism, resulting in system-wide deceleration. Consequently, the number of jobs in the waiting queue surges, further compounding the system's slowdown due to the scheduler's responsiveness being inversely proportional to the queue's length. Evidently, the value of $\hat{b}(0) = 0.03$ proves to be unviable within the real-world setup, as it triggers a series of unfavorable events leading to system performance degradation. This underscores the complexity and unpredictability of system behavior under certain initial conditions.

<figure><img src="image_39.png" /><figcaption>Figure 4.11: Results for the scenario where $\hat{b}(0) = 0.03$. The blue line represents the average across five distinct experiments. Within the estimation visualization, the red dashed line corresponds to $\tilde{b}$, while in the file server load illustration, the red dashed line signifies the reference load.</figcaption></figure>

Now, focusing our attention back on Figure 4.10, we can discern a consistent pattern in both cases: an initial decrease in the estimated value. This insight has been gleaned from the experimentation process. It has come to light that the system requires a certain amount of time to initiate, manifesting as an initial delay. This delay subsides after the first 3-4 time steps. However, owing to this initial delay, the estimation is notably underestimated during this phase. This underscores the reason why opting for an excessively small initial condition for $\hat{b}(0)$ is inadvisable. The consequences of this underestimation are twofold. Firstly, it results in an overshoot in the control action. Notably, the overshoot is more pronounced in Figure (b), primarily due to the estimated value reaching lower
levels compared to the scenario depicted in Figure (a). This discrepancy in the overshoot
can be attributed to the different initial conditions. Secondly, this underestimation also
affects the tracking process, leading to overshoot in the early stages due to the reduction
in the estimation.

Given these observations, a deliberate decision was made - select an initial value of 0.5. This choice facilitates a soft starting of the control action, effectively preventing overshoots that could otherwise lead to system overloads. It's worth noting that while 0.5 was the chosen solution in this context, it's not the exclusive solution. It is believed that any initial condition greater than 0.5 would yield satisfactory results, thereby offering flexibility in the choice of an appropriate starting point for $\hat{b}(0)$.

Initial Covariance condition

Having selected the optimal initial value for the estimated value, our focus now shifts to
determining the suitable initial condition for the covariance parameter.

<figure><img src="image_40.png" /><figcaption>Figure 4.12: Outcomes based on variations in initial Covariance values. Figure (a) cor-
responds to an initial condition of 100, while Figure (b) employs an initial value of 10⁴,
and Figure (c) utilizes 10⁶ as its starting point.</figcaption></figure>

As evident from Figure 4.12, the impact of altering the second parameter, namely the ini-
tial covariance, is relatively modest. The observed discrepancy primarily surfaces in the
final overshoot within the tracking outcome. It is worth noting that the system exhibits
a substantial degree of inherent noise, and our analysis is based on averaging results from
just five experiments. Therefore, it is plausible that the observed improvements are not
levels compared to the scenario depicted in Figure (a). This discrepancy in the overshoot can be attributed to the different initial conditions. Secondly, this underestimation also affects the tracking process, leading to overshoot in the early stages due to the reduction in the estimation.

Given these observations, a deliberate decision was made - select an initial value of 0.5. This choice facilitates a soft starting of the control action, effectively preventing overshoots that could otherwise lead to system overloads. It's worth noting that while 0.5 was the chosen solution in this context, it's not the exclusive solution. It is believed that any initial condition greater than 0.5 would yield satisfactory results, thereby offering flexibility in the choice of an appropriate starting point for $\hat{b}(0)$.

## Initial Covariance condition

Having selected the optimal initial value for the estimated value, our focus now shifts to determining the suitable initial condition for the covariance parameter.

<figure><img src="image_40.png" /><figcaption>Figure 4.12: Outcomes based on variations in initial Covariance values. Figure (a) corresponds to an initial condition of 100, while Figure (b) employs an initial value of $10^4$, and Figure (c) utilizes $10^6$ as its starting point.</figcaption></figure>

As evident from Figure 4.12, the impact of altering the second parameter, namely the initial covariance, is relatively modest. The observed discrepancy primarily surfaces in the final overshoot within the tracking outcome. It is worth noting that the system exhibits a substantial degree of inherent noise, and our analysis is based on averaging results from just five experiments. Therefore, it is plausible that the observed improvements are not
solely attributed to the covariance modification.

Nevertheless, considering the outcomes of this study, we have opted to select an initial value of $V(0) = 10^4$. This choice is underpinned by Figure 4.12, where this particular initial covariance value displays the least pronounced overshoot. It is important to acknowledge that the decision to increase this value is based on the consideration that higher initial covariance values may render the initial condition on $\hat{b}$ less dependable.

### 4.2.3. Experiment Result with Varying File Size

Once the algorithm has been fine-tuned ($\alpha = 2, \hat{b}_0 = 0.5, V(0) = 10^4$), the next phase involves an examination of the conclusive outcome through an experiment encompassing with two distinct campaigns. The initial campaign has a file size of 100 Mbyte with 2000 jobs, while the other has $f$ equal to 200 Mbyte with 1000 tasks. In the context of the experimental setup, the beginning of the second campaign is not deterministic. Indeed the second campaign will start only when all the jobs of the previous campaign are sent, then in different experiments, the second campaign starts at a different time.

As one can see from the initial row, we refrained from displaying solely the average of the five experiments, as such an approach would oversimplify the analysis because of the motivation above. Relying solely on the average could potentially yield misleading outcomes due to the divergence in experiment completion times for the first campaign. One can note this variability in Fig. 4.13, where certain experiments initiate the new campaign around 3000 seconds, while others commence closer to 4000 seconds.
solely attributed to the covariance modification.

Nevertheless, considering the outcomes of this study, we have opted to select an initial value of $V(0) = 10^4$. This choice is underpinned by Figure 4.12, where this particular initial covariance value displays the least pronounced overshoot. It is important to acknowledge that the decision to increase this value is based on the consideration that higher initial covariance values may render the initial condition on $\hat{b}$ less dependable.

### 4.2.3. Experiment Result with Varying File Size

Once the algorithm has been fine-tuned ($\alpha = 2, \hat{b}_0 = 0.5, V(0) = 10^4$), the next phase involves an examination of the conclusive outcome through an experiment encompassing with two distinct campaigns. The initial campaign has a file size of 100 Mbyte with 2000 jobs, while the other has $f$ equal to 200 Mbyte with 1000 tasks. In the context of the experimental setup, the beginning of the second campaign is not deterministic. Indeed the second campaign will start only when all the jobs of the previous campaign are sent, then in different experiments, the second campaign starts at a different time.

As one can see from the initial row, we refrained from displaying solely the average of the five experiments, as such an approach would oversimplify the analysis because of the motivation above. Relying solely on the average could potentially yield misleading outcomes due to the divergence in experiment completion times for the first campaign. One can note this variability in Fig. 4.13, where certain experiments initiate the new campaign around 3000 seconds, while others commence closer to 4000 seconds.
<figure><img src="image_41.png" /><figcaption>**Figure 4.13:** Results of the system using the adaptive PI. In Figure (a), the average of five $\hat{b}$ estimations is denoted by the blue line, while individual experiment outcomes are depicted using thinner lines. The red dashed lines correspond to $\tilde{b}$ values for the distinct $f$ settings. In Figure (b), the blue line represents the average output from the five experiments, and the specific outcomes for each experiment are indicated by the thinner lines. Both figures incorporate a black dashed line designating the settling time.</figcaption></figure>

Furthermore, it is essential to evaluate whether the system, when coupled with the algorithm, adheres to the overshoot requirement and time constraint. Analyzing Figure (b), we observe the tracking behavior, revealing an absence of overshooting. However, the ultimate system performance seems to be notably affected by the algorithm's presence. This observation is supported by the black dashed line in both plots, representing the anticipated time for the system to reach the reference value. In practice, the system attains this reference value after more than double the initially projected time. This deceleration appears to stem from the controller dispatching numerous jobs to achieve the reference value within the designated timeframe. Nevertheless, it is crucial to note that the identification algorithm must still converge to a specific value for $\hat{b}$, causing a delay. As depicted in Figure (a), $\hat{b}$ exhibits an increasing trend, resulting in a reduction of the control action and subsequently influencing the output in a similar manner.

The last key elements to address within Figure 4.13 pertain to the red dashed lines featured in (a). These lines correspond to the values of $\tilde{b}$ for the two distinct $f$ values. Specifically, for $f = 100$MByte, the approximation value is $\tilde{b} = 0.082$, while for $f = 200$MByte, it equates to $\tilde{b} = 0.15$. Importantly, in Figure (b), these values are lower than the parameter
<figure><img src="image_41.png" /><figcaption>Figure 4.13: Results of the system using the adaptive PI. In Figure (a), the average of five $\hat{b}$ estimations is denoted by the blue line, while individual experiment outcomes are depicted using thinner lines. The red dashed lines correspond to $\tilde{b}$ values for the distinct $f$ settings. In Figure (b), the blue line represents the average output from the five experiments, and the specific outcomes for each experiment are indicated by the thinner lines. Both figures incorporate a black dashed line designating the settling time.</figcaption></figure>

Furthermore, it is essential to evaluate whether the system, when coupled with the algorithm, adheres to the overshoot requirement and time constraint. Analyzing Figure (b), we observe the tracking behavior, revealing an absence of overshooting. However, the ultimate system performance seems to be notably affected by the algorithm's presence. This observation is supported by the black dashed line in both plots, representing the anticipated time for the system to reach the reference value. In practice, the system attains this reference value after more than double the initially projected time. This deceleration appears to stem from the controller dispatching numerous jobs to achieve the reference value within the designated timeframe. Nevertheless, it is crucial to note that the identification algorithm must still converge to a specific value for $\hat{b}$, causing a delay. As depicted in Figure (a), $\hat{b}$ exhibits an increasing trend, resulting in a reduction of the control action and subsequently influencing the output in a similar manner.

The last key elements to address within Figure 4.13 pertain to the red dashed lines featured in (a). These lines correspond to the values of $\tilde{b}$ for the two distinct $f$ values. Specifically, for $f = 100$MByte, the approximation value is $\tilde{b} = 0.082$, while for $f = 200$MByte, it equates to $\tilde{b} = 0.15$. Importantly, in Figure (b), these values are lower than the parameter
identified by the algorithm. It is important to note that the self-tuning technique does
not guarantee the precise replication of the actual system parameter; rather, it aims to
determine the parameter yielding optimal control. On the other hand, this outcome aligns
with the findings in Chapter 2.2.1, where a comparison between $\tilde{b}$ and $\tilde{b}$ highlighted un-
derestimation when $f$ exceeds 25MByte. Additionally, the observed trend, wherein larger
file sizes lead to greater underestimation, remains consistent.

4.3. PI vs. Adaptive PI

In this section, we present an analysis that involves the comparison of outcomes obtained
from two distinct systems. The first system, illustrated by the orange line, employs the
classic PI control, while the second system, represented by the blue line, incorporates
the Adaptive PI. Within the disturbance plot, we observe an additional dashed green
line, indicating the disturbance applied to the system, namely the HP jobs. Notably, the
appearance of this disturbance at the 2000s time mark is attributed to the scheduling
of HP jobs on the platform. In this scenario, a substantial quantity of HP jobs arrives,
significantly occupying more than half of the file server's reference. This phenomenon is
particularly evident in all instances of picture (b), where different file sizes of BE tasks
are considered. Across these cases, a conspicuous spike emerges due to the application of
the disturbance, accompanied by an undershoot as the disturbance subsides.

<figure><img src="image_42.png" /><figcaption>Figure 4.14: Experiment results with a $f=50MByte$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>
identified by the algorithm. It is important to note that the self-tuning technique does not guarantee the precise replication of the actual system parameter; rather, it aims to determine the parameter yielding optimal control. On the other hand, this outcome aligns with the findings in Chapter 2.2.1, where a comparison between $\tilde{b}$ and $\tilde{b}$ highlighted underestimation when $f$ exceeds 25MByte. Additionally, the observed trend, wherein larger file sizes lead to greater underestimation, remains consistent.

## 4.3. PI vs. Adaptive PI

In this section, we present an analysis that involves the comparison of outcomes obtained from two distinct systems. The first system, illustrated by the orange line, employs the classic PI control, while the second system, represented by the blue line, incorporates the Adaptive PI. Within the disturbance plot, we observe an additional dashed green line, indicating the disturbance applied to the system, namely the HP jobs. Notably, the appearance of this disturbance at the 2000s time mark is attributed to the scheduling of HP jobs on the platform. In this scenario, a substantial quantity of HP jobs arrives, significantly occupying more than half of the file server's reference. This phenomenon is particularly evident in all instances of picture (b), where different file sizes of BE tasks are considered. Across these cases, a conspicuous spike emerges due to the application of the disturbance, accompanied by an undershoot as the disturbance subsides.

<figure><img src="image_42.png" /><figcaption>Figure 4.14: Experiment results with a $f=50MByte$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>
<figure><img src="image_43.png" /><figcaption>Figure 4.15: Experiment results with a $f=100\text{MByte}$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>Figure 4.16: Experiment results with a $f=200\text{MByte}$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>
<figure><img src="image_43.png" /><figcaption>Figure 4.15: Experiment results with a $f=100\,\text{MByte}$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>Figure 4.16: Experiment results with a $f=200\,\text{MByte}$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>
<figure><img src="image_45.png" /><figcaption>Figure 4.17: Experiment results with a $f=400MByte$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>

Starting an in-depth analysis of the tracking results across varying file sizes. Our objective is to comprehensively dissect the outcomes, shedding light on disparities in terms of speed and initial overshoot. The culmination of our investigation will be summarized in Table 4.1. This table encapsulates and delineates the key findings of our analysis, providing a comprehensive overview of the convergence times and system behaviors across different file sizes.

Building upon the insights from the preceding section, we observed that the system, as identified by the combined identification algorithm and PI controller, exhibits an inertia exceeding our performance expectations. In the PI controller's design phase, we aimed for a settling time of 12 time steps, equivalent to 360 seconds. However, our empirical findings reveal that the new system's settling time is more than double this projected value. Moreover, a visual examination of the preceding diagram highlights a notable challenge even in the case of the system without the algorithm. Fulfilling the time requirement across all file sizes, denoted as $f$, proves to be intricate, except for the nominal case and the case of $f=200MBytes$.

Nonetheless, a discernible trend emerges – as the file size ($f$) diverges from its nominal value, the disparity between the convergence times of the two systems appears to narrow. However, the new control seems to take always more time to finish the transient.

Another crucial aspect of comparison between the two systems revolves around their ini-
<figure><img src="image_45.png" /><figcaption>**Figure 4.17:** Experiment results with a $f=400MByte$ for BE tasks: (a) Identification algorithm results (blue line) vs. $\tilde{b}$ (red dashed line). (b) Tracking comparison: Adaptive PI (blue), simple PI (orange), reference (red dashed), disturbance (green dashed), theoretical settling time (black dashed).</figcaption></figure>

Starting an in-depth analysis of the tracking results across varying file sizes. Our objective is to comprehensively dissect the outcomes, shedding light on disparities in terms of speed and initial overshoot. The culmination of our investigation will be summarized in Table 4.1. This table encapsulates and delineates the key findings of our analysis, providing a comprehensive overview of the convergence times and system behaviors across different file sizes.

Building upon the insights from the preceding section, we observed that the system, as identified by the combined identification algorithm and PI controller, exhibits an inertia exceeding our performance expectations. In the PI controller's design phase, we aimed for a settling time of 12 time steps, equivalent to 360 seconds. However, our empirical findings reveal that the new system's settling time is more than double this projected value. Moreover, a visual examination of the preceding diagram highlights a notable challenge even in the case of the system without the algorithm. Fulfilling the time requirement across all file sizes, denoted as $f$, proves to be intricate, except for the nominal case and the case of $f=200MBytes$.

Nonetheless, a discernible trend emerges – as the file size ($f$) diverges from its nominal value, the disparity between the convergence times of the two systems appears to narrow. However, the new control seems to take always more time to finish the transient.

Another crucial aspect of comparison between the two systems revolves around their ini-
tial overshoot characteristics. In the design phase, we carefully choose the parameter $M_p$ to prevent overshooting and to steer clear of challenging overloading scenarios. This intention aligns with our observations discussed in Chapter 2.2.3. As previously demonstrated, the original system successfully met this no-overshoot criterion for $f$ equal to or less than the nominal value of 100MByte. However, this requirement remained unmet for cases involving larger file sizes, as illustrated in Figures 4.16 and 4.17. Additionally, upon examining the latter graph, one can see that the overshoot exceeds the critical threshold of 8. This implies a grave concern – the system could potentially experience severe overloading, resulting in deceleration or, in extreme scenarios, a complete halt to the experimental process.

In light of this, the newfound perspective reveals that the new control mechanism delivers more favorable outcomes. Indeed, even when it experiences overshoot in the same situations as the previous controller, it appears that the magnitude of overshoots does not increase significantly, thereby mitigating potential issues.

Further insights emerge when investigating the transient behavior, including a distinctive observation within Figure 4.17. Curiously, the system employing the simple PI control exhibits intricate transient characteristics, possibly attributed to the presence of complex poles. This peculiar transient phenomenon is visually depicted in the image. In contrast, the new control system demonstrates a lack of such transients.

Before transitioning to the discussion on the identification behavior, a final noteworthy point should be highlighted. This refers to the system's response when subjected to disturbances. Notably, in the majority of cases, the adaptive system exhibits a slower recovery in returning to the reference value compared to its counterpart utilizing the simple PI control. Thus, the Adaptive PI addresses the initial overshoot problem and provides an improved transient response, although it takes a bit more time.
tial overshoot characteristics. In the design phase, we carefully choose the parameter $M_p$ to prevent overshooting and to steer clear of challenging overloading scenarios. This intention aligns with our observations discussed in Chapter 2.2.3. As previously demonstrated, the original system successfully met this no-overshoot criterion for $f$ equal to or less than the nominal value of 100MByte. However, this requirement remained unmet for cases involving larger file sizes, as illustrated in Figures 4.16 and 4.17. Additionally, upon examining the latter graph, one can see that the overshoot exceeds the critical threshold of 8. This implies a grave concern – the system could potentially experience severe overloading, resulting in deceleration or, in extreme scenarios, a complete halt to the experimental process.

In light of this, the newfound perspective reveals that the new control mechanism delivers more favorable outcomes. Indeed, even when it experiences overshoot in the same situations as the previous controller, it appears that the magnitude of overshoots does not increase significantly, thereby mitigating potential issues.

Further insights emerge when investigating the transient behavior, including a distinctive observation within Figure 4.17. Curiously, the system employing the simple PI control exhibits intricate transient characteristics, possibly attributed to the presence of complex poles. This peculiar transient phenomenon is visually depicted in the image. In contrast, the new control system demonstrates a lack of such transients.

Before transitioning to the discussion on the identification behavior, a final noteworthy point should be highlighted. This refers to the system's response when subjected to disturbances. Notably, in the majority of cases, the adaptive system exhibits a slower recovery in returning to the reference value compared to its counterpart utilizing the simple PI control. Thus, the Adaptive PI addresses the initial overshoot problem and provides an improved transient response, although it takes a bit more time.
<table><caption>Table 4.1: A comparison of the two separate systems' outcomes for a different file size.</caption><thead><tr><td>f [MByte]</td><td>Settling Time</td><td>Initial overshoot</td></tr></thead><tbody><tr><td>50</td><td>The Adaptive PI's delay is 50% of the PI's settling time. Whereas the final PI has a delay of 67% of the theoretical settling time.</td><td>Both the PI and the Adaptive PI have no overshoot.</td></tr><tr><td>100 (nominal case)</td><td>Adaptive's delay is 177% of the standard PI's settling time. The conventional PI converges 17% faster than the theoretical settling time.</td><td>Both the PI and the Adaptive PI have no overshoot.</td></tr><tr><td>200</td><td>Adaptive's delay is 260% of the standard PI's settling time. The conventional PI converges 30% faster than the theoretical settling time.</td><td>Both the control have an overshoot of 40% of the reference.</td></tr><tr><td>400</td><td>The Adaptive PI has a 5% delay compared to the conventional PI. The traditional PI converges with a time delay of 178% of the predicted settling time.</td><td>The PI has an overshoot of 180% of the reference value, while the Adaptive PI has an overshoot of 53% of the reference.</td></tr></tbody></table>

An examination of the identification process reveals that the earlier segment, preceding the disturbance, closely resembles the observations detailed in the preceding section, as one can see in Figure 4.18.

As the disturbance is introduced around the 2000s mark, the identification algorithm promptly gauges the disturbance's effect on the file system. Notably, the estimated impact of the disturbance appears to converge at approximately 2 units. This outcome arises due to the omission of disturbance consideration within the model. Consequently, the algorithms interpret the disturbance's arrival as a modification in the weight of BE tasks within the file server. This interpretation, in turn, contributes to the extended delay exhibited by the new system compared to the previous one.
<table><caption>Table 4.1: A comparison of the two separate systems' outcomes for a different file size.</caption><thead><tr><td>f [MByte]</td><td>Settling Time</td><td>Initial overshoot</td></tr></thead><tbody><tr><td>50</td><td>The Adaptive PI's delay is 50% of the PI's settling time. Whereas the final PI has a delay of 67% of the theoretical settling time.</td><td>Both the PI and the Adaptive PI have no overshoot.</td></tr><tr><td>100 (nominal case)</td><td>Adaptive's delay is 177% of the standard PI's settling time. The conventional PI converges 17% faster than the theoretical settling time.</td><td>Both the PI and the Adaptive PI have no overshoot.</td></tr><tr><td>200</td><td>Adaptive's delay is 260% of the standard PI's settling time. The conventional PI converges 30% faster than the theoretical settling time.</td><td>Both the control have an overshoot of 40% of the reference.</td></tr><tr><td>400</td><td>The Adaptive PI has a 5% delay compared to the conventional PI. The traditional PI converges with a time delay of 178% of the predicted settling time.</td><td>The PI has an overshoot of 180% of the reference value, while the Adaptive PI has an overshoot of 53% of the reference.</td></tr></tbody></table>

An examination of the identification process reveals that the earlier segment, preceding the disturbance, closely resembles the observations detailed in the preceding section, as one can see in Figure 4.18.

As the disturbance is introduced around the 2000s mark, the identification algorithm promptly gauges the disturbance's effect on the file system. Notably, the estimated impact of the disturbance appears to converge at approximately 2 units. This outcome arises due to the omission of disturbance consideration within the model. Consequently, the algorithms interpret the disturbance's arrival as a modification in the weight of BE tasks within the file server. This interpretation, in turn, contributes to the extended delay exhibited by the new system compared to the previous one.
<figure><img src="image_46.png" /><figcaption>Figure 4.18: Zoomed-in estimation results prior to the disturbance's arrival. In picture (a), we observe the scenario with a data size of $f=50$ MByte. In picture (b), the scenario with $f=100$ MByte is depicted, in (c), the scenario with $f=200$ MByte is presented, and in (d) the case with $f=400$ MByte.</figcaption></figure>
<figure><img src="image_46.png" /><figcaption>Figure 4.18: Zoomed-in estimation results prior to the disturbance's arrival. In picture (a), we observe the scenario with a data size of $f=50$ MByte. In picture (b), the scenario with $f=100$ MByte is depicted, in (c), the scenario with $f=200$ MByte is presented, and in (d) the case with $f=400$ MByte.</figcaption></figure>
<figure><img src="image_47.png" /></figure>
<figure><img src="image_47.png" /></figure>
# 5 | Conclusion and Future work

This master thesis focuses on the saturation problem of the file system within a cluster. The idea was to develop an identification algorithm that could change the main parameters of the controller for each working condition. Additionally, our goal was to achieve more consistent outcomes across a range of operational scenarios. Notably, the proportional-integral (PI) controller exhibited divergent performance outcomes depending on the file size, with particularly problematic behavior observed when dealing with larger values of $f$.

As previously discussed, when $f$ reached 400 Mbytes, the PI controller displayed a substantial overshoot, potentially leading to system lock-ups. In contrast, the introduction of the Adaptive PI controller effectively mitigated this issue. In fact, it was observed that the overshoot remained relatively constant for values of $f$ exceeding 100 Mbytes.

Nevertheless, it is important to acknowledge that this solution is not without its drawbacks. In practice, while the Adaptive PI controller effectively addresses the overshoot problem, it tends to slow down the system. Consequently, results obtained using this algorithm consistently indicate a slower system performance compared to the non-algorithmic approach. This implies that during system initialization or transitions in working conditions, such as the arrival of high-priority jobs or changes in the value of $f$, the system supported by the algorithm experiences a longer period of idle resources compared to the traditional PI controller.

In addition to the findings presented in this thesis, there are several potential solutions that were not implemented in the actual system but hold promise for future improvements. First, let's discuss the Selective algorithm. Initially, we had high expectations for this algorithm because it closely aligned with the system's specifications. It was designed to learn only when necessary. However, this algorithm had limited time to adapt, and this limitation stemmed from our lack of knowledge about the real platform's startup delay. In light of this, we propose a possible solution: initiating the algorithm a few steps after the overall system startup. To achieve this, we can set an initial condition for $\hat{b}$ to remain constant for the first three steps, after which the algorithm can commence its learning process. This adjustment, we believe, can effectively address the problem
# 5 | Conclusion and Future work

This master thesis focuses on the saturation problem of the file system within a cluster. The idea was to develop an identification algorithm that could change the main parameters of the controller for each working condition. Additionally, our goal was to achieve more consistent outcomes across a range of operational scenarios. Notably, the proportional-integral (PI) controller exhibited divergent performance outcomes depending on the file size, with particularly problematic behavior observed when dealing with larger values of $f$.

As previously discussed, when $f$ reached 400 Mbytes, the PI controller displayed a substantial overshoot, potentially leading to system lock-ups. In contrast, the introduction of the Adaptive PI controller effectively mitigated this issue. In fact, it was observed that the overshoot remained relatively constant for values of $f$ exceeding 100 Mbytes.

Nevertheless, it is important to acknowledge that this solution is not without its drawbacks. In practice, while the Adaptive PI controller effectively addresses the overshoot problem, it tends to slow down the system. Consequently, results obtained using this algorithm consistently indicate a slower system performance compared to the non-algorithmic approach. This implies that during system initialization or transitions in working conditions, such as the arrival of high-priority jobs or changes in the value of $f$, the system supported by the algorithm experiences a longer period of idle resources compared to the traditional PI controller.

In addition to the findings presented in this thesis, there are several potential solutions that were not implemented in the actual system but hold promise for future improvements. First, let's discuss the Selective algorithm. Initially, we had high expectations for this algorithm because it closely aligned with the system's specifications. It was designed to learn only when necessary. However, this algorithm had limited time to adapt, and this limitation stemmed from our lack of knowledge about the real platform's startup delay. In light of this, we propose a possible solution: initiating the algorithm a few steps after the overall system startup. To achieve this, we can set an initial condition for $\hat{b}$ to remain constant for the first three steps, after which the algorithm can commence its learning process. This adjustment, we believe, can effectively address the problem
of underestimation, and the available learning time for the Selective Algorithm will be
sufficient.

Another technique that we developed for simulations that we did not test on the real platform is the use of a two-parameter model. We think that the two-parameter formula is better suited for the system than the single-parameter model. By considering two parameters, we incorporate information from the GANTT chart into the model, making more effective use of available data. Additionally, when relying solely on a single parameter, the theoretical interpretation of that parameter becomes muddled, as it combines the weight of only one BE task on the file server ($b_u$) with the weight of all HP jobs within the file server ($b_d \times d$). Therefore, we believe it would be advantageous to include other parameters in the model to ensure greater consistency with the actual processes occurring within the system.

Furthermore, we would like to reflect on a broader aspect that emerged from our experience during this research. In engineering we often focus on equations, expressions, and numerical results, sometimes overlooking the people behind the work. In the course of this study, collaboration between individuals from control theory and computer science was essential. It became evident that bridging the gap between these two fields required more than just merging different knowledge domains; it necessitated an understanding of the distinct thought processes and approaches to problem-solving that each field brings. This underlying difference in thinking patterns is not always obvious but can present significant challenges.

In conclusion, we believe that the algorithm contributes to achieving more consistent and homogeneous results. By estimating $\hat{b}$ in each iteration, it effectively addresses the challenge of pre-tuning the model for different clusters and helps prevent overloading of the file server when dealing with high values of $f$. However, it is important to acknowledge that this improvement comes at the cost of a system slowdown.
of underestimation, and the available learning time for the Selective Algorithm will be
sufficient.

Another technique that we developed for simulations that we did not test on the real
platform is the use of a two-parameter model. We think that the two-parameter formula
is better suited for the system than the single-parameter model. By considering two pa-
rameters, we incorporate information from the GANTT chart into the model, making
more effective use of available data. Additionally, when relying solely on a single parame-
ter, the theoretical interpretation of that parameter becomes muddled, as it combines the
weight of only one BE task on the file server (b_u) with the weight of all HP jobs within
the file server (b_d × d). Therefore, we believe it would be advantageous to include other
parameters in the model to ensure greater consistency with the actual processes occurring
within the system.

Furthermore, we would like to reflect on a broader aspect that emerged from our expe-
rience during this research. In engineering we often focus on equations, expressions, and
numerical results, sometimes overlooking the people behind the work. In the course of
this study, collaboration between individuals from control theory and computer science
was essential. It became evident that bridging the gap between these two fields required
more than just merging different knowledge domains; it necessitated an understanding of
the distinct thought processes and approaches to problem-solving that each field brings.
This underlying difference in thinking patterns is not always obvious but can present
significant challenges.

In conclusion, we believe that the algorithm contributes to achieving more consistent
and homogeneous results. By estimating $\hat{b}$ in each iteration, it effectively addresses the
challenge of pre-tuning the model for different clusters and helps prevent overloading of
the file server when dealing with high values of $f$. However, it is important to acknowledge
that this improvement comes at the cost of a system slowdown.
# A | Appendix A

<figure><img src="image_48.png" /><figcaption>Figure A.1: Close loop with a PI controller.</figcaption></figure>

The idea behind the choice of $k_p$ and $k_i$ is to build a sort of pole placement with a PI. To do this the book [45] considered the close-loop transfer function

$$C(z) = \frac{G(z)R(z)}{1 + G(z)R(z)} \qquad (A.1)$$

Where $G(z)$ is the system and $R(z)$ the controller that define the control action $u$, in this case

$$R(z) = K_p + \frac{K_i z}{z - 1} = \frac{(K_p + K_i)z - K_p}{z - 1} \qquad (A.2)$$

Afterward, the close loop transfer function can be defined as

$$C(z) = \frac{[(K_p + K_i)z - K_p]G(z)}{z - 1 + [(K_p + K_i)z - K_p]G(z)} \qquad (A.3)$$

The next step will be the computation of $K_p$ and $K_i$ in order to plug in the desired poles for the closed loop system. Then now there will be the estimation of the desired poles, by the assumption these poles are complex conjugates in the form of $r \exp^{j\theta}$. Then it considers the 2% criterion for the settling time $K_s$ in discrete time
# A | Appendix A

<figure><img src="image_48.png" /><figcaption>Figure A.1: Close loop with a PI controller.</figcaption></figure>

The idea behind the choice of $k_p$ and $k_i$ is to build a sort of pole placement with a PI. To do this the book [45] considered the close-loop transfer function

$$C(z) = \frac{G(z)R(z)}{1 + G(z)R(z)} \qquad (A.1)$$

Where $G(z)$ is the system and $R(z)$ the controller that define the control action $u$, in this case

$$R(z) = K_p + \frac{K_i z}{z - 1} = \frac{(K_p + K_i)z - K_p}{z - 1} \qquad (A.2)$$

Afterward, the close loop transfer function can be defined as

$$C(z) = \frac{[(K_p + K_i)z - K_p]G(z)}{z - 1 + [(K_p + K_i)z - K_p]G(z)} \qquad (A.3)$$

The next step will be the computation of $K_p$ and $K_i$ in order to plug in the desired poles for the closed loop system. Then now there will be the estimation of the desired poles, by the assumption these poles are complex conjugates in the form of $r \exp^{j\theta}$. Then it considers the 2% criterion for the settling time $K_s$ in discrete time
$$K_s \approx \frac{-4}{\ln r} \qquad (A.4)$$

Then, in this specific case where the poles are complex conjugate the maximum overshoot $M_p$ can be computed as

$$M_p \approx r^{\pi/|\theta|} \qquad (A.5)$$

After the definition of these two fundamental parameters, it is possible to inverse the above relationship to compute the value of the poles by establishing the desire characteristic for the close loop

$$\begin{cases} r \approx \exp^{-4/K_s} \\ \theta \approx \pi \frac{\ln r}{\ln M_p} \end{cases} \qquad (A.6)$$

Then, one can determine the characteristic polynomial of the system

$$(z - r \exp^{j\theta})(z - r \exp^{-j\theta}) = z^2 - 2rcos(\theta)z + r^2 \qquad (A.7)$$

Then, by matching the denominator of A.3 and the right part of expression A.7, $K_p$ and $K_I$ are found

$$\begin{cases} K_p = \frac{a-r^2}{b} \\ K_I = \frac{1-2r \cos \theta + r^2}{b} \end{cases} \qquad (A.8)$$
$$K_s \approx \frac{-4}{\ln r} \qquad (A.4)$$

Then, in this specific case where the poles are complex conjugate the maximum overshoot $M_p$ can be computed as

$$M_p \approx r^{\pi/|\theta|} \qquad (A.5)$$

After the definition of these two fundamental parameters, it is possible to inverse the above relationship to compute the value of the poles by establishing the desire characteristic for the close loop

$$\begin{cases} r \approx \exp^{-4/K_s} \\ \theta \approx \pi \frac{\ln r}{\ln M_p} \end{cases} \qquad (A.6)$$

Then, one can determine the characteristic polynomial of the system

$$(z - r \exp^{j\theta})(z - r \exp^{-j\theta}) = z^2 - 2rcos(\theta)z + r^2 \qquad (A.7)$$

Then, by matching the denominator of A.3 and the right part of expression A.7, $K_p$ and $K_I$ are found

$$\begin{cases} K_p = \frac{a-r^2}{b} \\ K_I = \frac{1-2r \cos \theta + r^2}{b} \end{cases} \qquad (A.8)$$
Bibliography

[1] John Michalakes. "HPC for Weather Forecasting". In: *Parallel Algorithms in Computational Science and Engineering*. Ed. by Ananth Grama and Ahmed H. Sameh. Cham: Springer International Publishing, 2020, pp. 297–323. ISBN: 978-3-030-43736-7. DOI: 10.1007/978-3-030-43736-7_10. URL: https://doi.org/10.1007/978-3-030-43736-7_10.

[2] Richard M. Russell. "The CRAY-1 Computer System". In: *Commun. ACM* 21.1 (Jan. 1978), pp. 63–72. ISSN: 0001-0782. DOI: 10.1145/359327.359336. URL: https://doi.org/10.1145/359327.359336.

[3] *TOP500*. https://www.top500.org/lists/top500/2023/06/. I visited the site on 13.07.2023.

[4] Marián Vajteršic, Peter Zinterhof, and Roman Trobec. "Overview – Parallel Computing: Numerics, Applications, and Trends". In: *Parallel Computing: Numerics, Applications, and Trends*. Ed. by Roman Trobec, Marián Vajteršic, and Peter Zinterhof. London: Springer London, 2009, pp. 43–80. ISBN: 978-1-84882-409-6. DOI: 10.1007/978-1-84882-409-6_1. URL: https://doi.org/10.1007/978-1-84882-409-6_1.

[5] By Yixuan Li. "Picture of 2D Torus topology". In:(). URL: https://commons.wikimedia.org/w/index.php?curid=53610657.

[6] Charles E. Leiserson. "Fat-trees: Universal networks for hardware-efficient supercomputing". In: *IEEE Transactions on Computers* C-34.10 (1985), pp. 892–901. DOI: 10.1109/TC.1985.6312192.

[7] Daniel Reed, Dennis Gannon, and Jack Dongarra. *Reinventing High Performance Computing: Challenges and Opportunities*. 2022. arXiv: 2203.02544 [cs.DC].

[8] P. S. Kostenetskiy, R. A. Chulkevich, and V. I. Kozyrev. "HPC Resources of the Higher School of Economics". In: *Journal of Physics: Conference Series* 1740.1 (Jan. 2021), p. 012050. DOI: 10.1088/1742-6596/1740/1/012050. URL: https://dx.doi.org/10.1088/1742-6596/1740/1/012050.

[9] Rahil Parmar et al. "18 - 5G-enabled deep learning-based framework for healthcare mining: State of the art and challenges". In: *Blockchain Applications for Health-
Bibliography

[1] John Michalakes. "HPC for Weather Forecasting". In: *Parallel Algorithms in Computational Science and Engineering*. Ed. by Ananth Grama and Ahmed H. Sameh. Cham: Springer International Publishing, 2020, pp. 297–323. ISBN: 978-3-030-43736-7. DOI: 10.1007/978-3-030-43736-7_10. URL: https://doi.org/10.1007/978-3-030-43736-7_10.

[2] Richard M. Russell. "The CRAY-1 Computer System". In: *Commun. ACM* 21.1 (Jan. 1978), pp. 63–72. ISSN: 0001-0782. DOI: 10.1145/359327.359336. URL: https://doi.org/10.1145/359327.359336.

[3] *TOP500*. https://www.top500.org/lists/top500/2023/06/. I visited the site on 13.07.2023.

[4] Marián Vajteršic, Peter Zinterhof, and Roman Trobec. "Overview – Parallel Computing: Numerics, Applications, and Trends". In: *Parallel Computing: Numerics, Applications, and Trends*. Ed. by Roman Trobec, Marián Vajteršic, and Peter Zinterhof. London: Springer London, 2009, pp. 43–80. ISBN: 978-1-84882-409-6. DOI: 10.1007/978-1-84882-409-6_1. URL: https://doi.org/10.1007/978-1-84882-409-6_1.

[5] By Yixuan Li. "Picture of 2D Torus topology". In:(). URL: https://commons.wikimedia.org/w/index.php?curid=53610657.

[6] Charles E. Leiserson. "Fat-trees: Universal networks for hardware-efficient supercomputing". In: *IEEE Transactions on Computers* C-34.10 (1985), pp. 892–901. DOI: 10.1109/TC.1985.6312192.

[7] Daniel Reed, Dennis Gannon, and Jack Dongarra. *Reinventing High Performance Computing: Challenges and Opportunities*. 2022. arXiv: 2203.02544 [cs.DC].

[8] P. S. Kostenetskiy, R. A. Chulkevich, and V. I. Kozyrev. "HPC Resources of the Higher School of Economics". In: *Journal of Physics: Conference Series* 1740.1 (Jan. 2021), p. 012050. DOI: 10.1088/1742-6596/1740/1/012050. URL: https://dx.doi.org/10.1088/1742-6596/1740/1/012050.

[9] Rahil Parmar et al. "18 - 5G-enabled deep learning-based framework for healthcare mining: State of the art and challenges". In: *Blockchain Applications for Health-
*care Informatics*. Ed. by Sudeep Tanwar. Academic Press, 2022, pp. 401–420. ISBN: 978-0-323-90615-9. DOI: https://doi.org/10.1016/B978-0-323-90615-9.00016-5. URL: https://www.sciencedirect.com/science/article/pii/B9780323906159000165.

[10] Rama. *CC BY-SA 2.0* fr. https://commons.wikimedia.org/w/index.php?curid=345858.

[11] Raphael Bleuse. "Apprehending heterogeneity at (very) large scale". PhD thesis. Université Grenoble Alpes, 2017.

[12] "Backfill scheduling". In: https://www.ibm.com/docs/en/spectrum-lsf/10.1.0?topic=jobs-backfill-scheduling().

[13] Francieli Zanon Boito et al. "A Checkpoint of Research on Parallel I/O for High-Performance Computing". In: *ACM Comput. Surv.* 51.2 (Mar. 2018). ISSN: 0360-0300. DOI: 10.1145/3152891. URL: https://doi.org/10.1145/3152891.

[14] D. Patterson and J. Hennessy. *Computer Organization and Design: the hardware/software interface*. 3rd edition. Elsevier, 2005, pp. 468–610.

[15] Quentin Guilloteau et al. "Controlling the Injection of Best-Effort Tasks to Harvest Idle Computing Grid Resources". In: *2021 25th International Conference on System Theory, Control and Computing (ICSTCC)*. 2021, pp. 334–339. DOI: 10.1109/ICSTCC52150.2021.9607292.

[16] Agustín Gabriel Yabo et al. "A control-theory approach for cluster autonomic management: maximizing usage while avoiding overload". In: *2019 IEEE Conference on Control Technology and Applications (CCTA)*. 2019, pp. 189–195. DOI: 10.1109/CCTA.2019.8920473.

[17] Géza Ódor and Bálint Hartmann. "Heterogeneity effects in power grid network models". In: *Phys. Rev. E* 98 (2 Aug. 2018), p. 022305. DOI: 10.1103/PhysRevE.98.022305. URL: https://link.aps.org/doi/10.1103/PhysRevE.98.022305.

[18] P Horn. "IBM, Autonomic Computing: IBM's Perspective on the State of Information Technology". In: URL: https://people.scs.carleton.ca/soma/biosec/readings/autonomic computing.pdf().

[19] J.O. Kephart and D.M. Chess. "The vision of autonomic computing". In: *Computer* 36.1 (2003), pp. 41–50. DOI: 10.1109/MC.2003.1160055.

[20] Manish Parashar and Salim Hariri. "Autonomic Computing: An Overview". In: *Unconventional Programming Paradigms*. Ed. by Jean-Pierre Banâtre et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 257–269. ISBN: 978-3-540-31482-0.

[21] Danny Weyns. "Software Engineering of Self-adaptive Systems". In: *Handbook of Software Engineering*. Ed. by Sungdeok Cha, Richard N. Taylor, and Kyochul Kang.
*care Informatics*. Ed. by Sudeep Tanwar. Academic Press, 2022, pp. 401–420. ISBN: 978-0-323-90615-9. DOI: https://doi.org/10.1016/B978-0-323-90615-9.00016-5. URL: https://www.sciencedirect.com/science/article/pii/B9780323906159000165.

[10] Rama. *CC BY-SA 2.0* fr. https://commons.wikimedia.org/w/index.php?curid=345858.

[11] Raphael Bleuse. "Apprehending heterogeneity at (very) large scale". PhD thesis. Université Grenoble Alpes, 2017.

[12] "Backfill scheduling". In: https://www.ibm.com/docs/en/spectrum-lsf/10.1.0?topic=jobs-backfill-scheduling().

[13] Francieli Zanon Boito et al. "A Checkpoint of Research on Parallel I/O for High-Performance Computing". In: *ACM Comput. Surv.* 51.2 (Mar. 2018). ISSN: 0360-0300. DOI: 10.1145/3152891. URL: https://doi.org/10.1145/3152891.

[14] D. Patterson and J. Hennessy. *Computer Organization and Design: the hardware/software interface*. 3rd edition. Elsevier, 2005, pp. 468–610.

[15] Quentin Guilloteau et al. "Controlling the Injection of Best-Effort Tasks to Harvest Idle Computing Grid Resources". In: *2021 25th International Conference on System Theory, Control and Computing (ICSTCC)*. 2021, pp. 334–339. DOI: 10.1109/ICSTCC52150.2021.9607292.

[16] Agustín Gabriel Yabo et al. "A control-theory approach for cluster autonomic management: maximizing usage while avoiding overload". In: *2019 IEEE Conference on Control Technology and Applications (CCTA)*. 2019, pp. 189–195. DOI: 10.1109/CCTA.2019.8920473.

[17] Géza Ódor and Bálint Hartmann. "Heterogeneity effects in power grid network models". In: *Phys. Rev. E* 98 (2 Aug. 2018), p. 022305. DOI: 10.1103/PhysRevE.98.022305. URL: https://link.aps.org/doi/10.1103/PhysRevE.98.022305.

[18] P Horn. "IBM, Autonomic Computing: IBM's Perspective on the State of Information Technology". In: URL: https://people.scs.carleton.ca/soma/biosec/readings/autonomic computing.pdf().

[19] J.O. Kephart and D.M. Chess. "The vision of autonomic computing". In: *Computer* 36.1 (2003), pp. 41–50. DOI: 10.1109/MC.2003.1160055.

[20] Manish Parashar and Salim Hariri. "Autonomic Computing: An Overview". In: *Unconventional Programming Paradigms*. Ed. by Jean-Pierre Banâtre et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, pp. 257–269. ISBN: 978-3-540-31482-0.

[21] Danny Weyns. "Software Engineering of Self-adaptive Systems". In: *Handbook of Software Engineering*. Ed. by Sungdeok Cha, Richard N. Taylor, and Kyochul Kang.
Cham: Springer International Publishing, 2019, pp. 399-443. ISBN: 978-3-030-00262-6. DOI: 10.1007/978-3-030-00262-6_11. URL: https://doi.org/10.1007/978-3-030-00262-6_11.

[22] Tarek Abdelzaher et al. "Introduction to Control Theory And Its Application to Computing Systems". In: Performance Modeling and Engineering. Ed. by Zhen Liu and Cathy H. Xia. Boston, MA: Springer US, 2008, pp. 185-215. ISBN: 978-0-387-79361-0. DOI: 10.1007/978-0-387-79361-0_7. URL: https://doi.org/10.1007/978-0-387-79361-0_7.

[23] Sophie Cerf et al. "Sustaining Performance While Reducing Energy Consumption: A Control Theory Approach". In: Euro-Par 2021: Parallel Processing. Ed. by Leonel Sousa, Nuno Roma, and Pedro Tomás. Cham: Springer International Publishing, 2021, pp. 334-349. ISBN: 978-3-030-85665-6.

[24] IBM. "An architectural blueprint for autonomic computing". In: (2005). URL: https://users.cs.fiu.edu/~sadjadi/Teaching/Autonomic%20Grid%20Computing/CIS-6612-Summer-2006/AC-Blueprint-WhitePaper-V7.pdf.

[25] Eric Rutten, Nicolas Marchand, and Daniel Simon. "Feedback Control as MAPE-K Loop in Autonomic Computing". In: Software Engineering for Self-Adaptive Systems III. Assurances. Ed. by Rogério de Lemos et al. Cham: Springer International Publishing, 2017, pp. 349-373. ISBN: 978-3-319-74183-3.

[26] Xiaoyun Zhu et al. "What Does Control Theory Bring to Systems Research?" In: SIGOPS Oper. Syst. Rev. 43.1 (Jan. 2009), pp. 62-69. ISSN: 0163-5980. DOI: 10.1145/1496909.1496922. URL: https://doi.org/10.1145/1496909.1496922.

[27] Antonio Filieri et al. "Software Engineering Meets Control Theory". In: 2015 IEEE / ACM 10th International Symposium on Software Engineering for Adaptive and Self-Managing Systems. 2015, pp. 71-82. DOI: 10.1109/SEAMS.2015.12.

[28] Yuriy Brun et al. "Engineering Self-Adaptive Systems through Feedback Loops". In: Software Engineering for Self-Adaptive Systems. Ed. by Betty H. C. Cheng et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp. 48-70. ISBN: 978-3-642-02161-9. DOI: 10.1007/978-3-642-02161-9_3. URL: https://doi.org/10.1007/978-3-642-02161-9_3.

[29] Alessandro Vittorio Papadopoulos et al. "A dynamic modelling framework for control-based computing system design". In: Mathematical and Computer Modelling of Dynamical Systems 21.3 (2015), pp. 251-271. DOI: 10.1080/13873954.2014.942785. eprint: https://doi.org/10.1080/13873954.2014.942785. URL: https://doi.org/10.1080/13873954.2014.942785.
Cham: Springer International Publishing, 2019, pp. 399-443. ISBN: 978-3-030-00262-6. DOI: 10.1007/978-3-030-00262-6_11. URL: https://doi.org/10.1007/978-3-030-00262-6_11.

[22] Tarek Abdelzaher et al. "Introduction to Control Theory And Its Application to Computing Systems". In: Performance Modeling and Engineering. Ed. by Zhen Liu and Cathy H. Xia. Boston, MA: Springer US, 2008, pp. 185-215. ISBN: 978-0-387-79361-0. DOI: 10.1007/978-0-387-79361-0_7. URL: https://doi.org/10.1007/978-0-387-79361-0_7.

[23] Sophie Cerf et al. "Sustaining Performance While Reducing Energy Consumption: A Control Theory Approach". In: Euro-Par 2021: Parallel Processing. Ed. by Leonel Sousa, Nuno Roma, and Pedro Tomás. Cham: Springer International Publishing, 2021, pp. 334-349. ISBN: 978-3-030-85665-6.

[24] IBM. "An architectural blueprint for autonomic computing". In: (2005). URL: https://users.cs.fiu.edu/~sadjadi/Teaching/Autonomic%20Grid%20Computing/CIS-6612-Summer-2006/AC-Blueprint-WhitePaper-V7.pdf.

[25] Eric Rutten, Nicolas Marchand, and Daniel Simon. "Feedback Control as MAPE-K Loop in Autonomic Computing". In: Software Engineering for Self-Adaptive Systems III. Assurances. Ed. by Rogério de Lemos et al. Cham: Springer International Publishing, 2017, pp. 349-373. ISBN: 978-3-319-74183-3.

[26] Xiaoyun Zhu et al. "What Does Control Theory Bring to Systems Research?" In: SIGOPS Oper. Syst. Rev. 43.1 (Jan. 2009), pp. 62-69. ISSN: 0163-5980. DOI: 10.1145/1496909.1496922. URL: https://doi.org/10.1145/1496909.1496922.

[27] Antonio Filieri et al. "Software Engineering Meets Control Theory". In: 2015 IEEE / ACM 10th International Symposium on Software Engineering for Adaptive and Self-Managing Systems. 2015, pp. 71-82. DOI: 10.1109/SEAMS.2015.12.

[28] Yuriy Brun et al. "Engineering Self-Adaptive Systems through Feedback Loops". In: Software Engineering for Self-Adaptive Systems. Ed. by Betty H. C. Cheng et al. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp. 48-70. ISBN: 978-3-642-02161-9. DOI: 10.1007/978-3-642-02161-9_3. URL: https://doi.org/10.1007/978-3-642-02161-9_3.

[29] Alessandro Vittorio Papadopoulos et al. "A dynamic modelling framework for control-based computing system design". In: Mathematical and Computer Modelling of Dynamical Systems 21.3 (2015), pp. 251-271. DOI: 10.1080/13873954.2014.942785. eprint: https://doi.org/10.1080/13873954.2014.942785. URL: https://doi.org/10.1080/13873954.2014.942785.
[30] Stepan Shevtsov et al. "Control-Theoretical Software Adaptation: A Systematic Literature Review". In: *IEEE Transactions on Software Engineering* 44.8 (2018), pp. 784-810. DOI: 10.1109/TSE.2017.2704579.

[31] Alberto Leva et al. "How control-friendly is a computing system? And how control-friendly could it be?" In: *IFAC-PapersOnLine* 53.2 (2020). 21st IFAC World Congress, pp. 7857-7864. ISSN: 2405-8963. DOI: https://doi.org/10.1016/j.ifacol.2020.12.1962. URL: https://www.sciencedirect.com/science/article/pii/S240589632032591X.

[32] M. Kristic, Kokotovic P.V., and kanellakopoulos I. *Nonlinear and Adaptive Control Design*. 1st edition. New York: Wiley, 1995.

[33] Tharindu Patikirikorala et al. "An evaluation of multi-model self-managing control schemes for adaptive performance management of software systems". In: *Journal of Systems and Software* 85.12 (2012). Self-Adaptive Systems, pp. 2678-2696. ISSN: 0164-1212. DOI: https://doi.org/10.1016/j.jss.2012.05.077. URL: https://www.sciencedirect.com/science/article/pii/S0164121212001628.

[34] Konstantinos Angelopoulos, Alessandro Vittorio Papadopoulos, and John Mylopoulos. "Adaptive Predictive Control for Software Systems". In: *Proceedings of the 1st International Workshop on Control Theory for Software Engineering*. CTSE 2015. Bergamo, Italy: Association for Computing Machinery, 2015, pp. 17-21. ISBN: 9781450338141. DOI: 10.1145/2804337.2804340. URL: https://doi.org/10.1145/2804337.2804340.

[35] Tharindu Patikirikorala, Liuping Wang, and Alan Colman. "Towards optimal performance and resource management in web systems via model predictive control". In: *2011 Australian Control Conference*. 2011, pp. 469-474.

[36] Guangyi Cao and Arun A. Ravindran. "Energy Efficient Soft Real-Time Computing through Cross-Layer Predictive Control". In: *9th International Workshop on Feedback Computing (Feedback Computing 14)*. Philadelphia, PA: USENIX Association, June 2014. URL: https://www.usenix.org/conference/feedbackcomputing14/workshop-program/presentation/cao.

[37] Antonio Filieri, Henry Hoffmann, and Martina Maggio. "Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees". In: *Proceedings of the 36th International Conference on Software Engineering*. ICSE 2014. Hyderabad, India: Association for Computing Machinery, 2014, pp. 299-310. ISBN: 9781450327565. DOI: 10.1145/2568225.2568272. URL: https://doi.org/10.1145/2568225.2568272.

[38] "Picture of Grid5000". In: (2023). URL: https://www.grid5000.fr/w/File:G5k-backbone.png.
[30] Stepan Shevtsov et al. "Control-Theoretical Software Adaptation: A Systematic Literature Review". In: *IEEE Transactions on Software Engineering* 44.8 (2018), pp. 784-810. DOI: 10.1109/TSE.2017.2704579.

[31] Alberto Leva et al. "How control-friendly is a computing system? And how control-friendly could it be?" In: *IFAC-PapersOnLine* 53.2 (2020). 21st IFAC World Congress, pp. 7857-7864. ISSN: 2405-8963. DOI: https://doi.org/10.1016/j.ifacol.2020.12.1962. URL: https://www.sciencedirect.com/science/article/pii/S240589632032591X.

[32] M. Kristic, Kokotovic P.V., and kanellakopoulos I. *Nonlinear and Adaptive Control Design*. 1st edition. New York: Wiley, 1995.

[33] Tharindu Patikirikorala et al. "An evaluation of multi-model self-managing control schemes for adaptive performance management of software systems". In: *Journal of Systems and Software* 85.12 (2012). Self-Adaptive Systems, pp. 2678-2696. ISSN: 0164-1212. DOI: https://doi.org/10.1016/j.jss.2012.05.077. URL: https://www.sciencedirect.com/science/article/pii/S0164121212001628.

[34] Konstantinos Angelopoulos, Alessandro Vittorio Papadopoulos, and John Mylopoulos. "Adaptive Predictive Control for Software Systems". In: *Proceedings of the 1st International Workshop on Control Theory for Software Engineering*. CTSE 2015. Bergamo, Italy: Association for Computing Machinery, 2015, pp. 17-21. ISBN: 9781450338141. DOI: 10.1145/2804337.2804340. URL: https://doi.org/10.1145/2804337.2804340.

[35] Tharindu Patikirikorala, Liuping Wang, and Alan Colman. "Towards optimal performance and resource management in web systems via model predictive control". In: *2011 Australian Control Conference*. 2011, pp. 469-474.

[36] Guangyi Cao and Arun A. Ravindran. "Energy Efficient Soft Real-Time Computing through Cross-Layer Predictive Control". In: *9th International Workshop on Feedback Computing (Feedback Computing 14)*. Philadelphia, PA: USENIX Association, June 2014. URL: https://www.usenix.org/conference/feedbackcomputing14/workshop-program/presentation/cao.

[37] Antonio Filieri, Henry Hoffmann, and Martina Maggio. "Automated Design of Self-Adaptive Software with Control-Theoretical Formal Guarantees". In: *Proceedings of the 36th International Conference on Software Engineering*. ICSE 2014. Hyderabad, India: Association for Computing Machinery, 2014, pp. 299-310. ISBN: 9781450327565. DOI: 10.1145/2568225.2568272. URL: https://doi.org/10.1145/2568225.2568272.

[38] "Picture of Grid5000". In: (2023). URL: https://www.grid5000.fr/w/File:G5k-backbone.png.
[39] Yiannis Georgiou, Olivier Richard, and Nicolas Capit. "Evaluations of the Lightweight Grid CIGRI upon the Grid5000 Platform". In: *Third IEEE International Conference on e-Science and Grid Computing (e-Science 2007)*. 2007, pp. 279-286. DOI: 10.1109/E-SCIENCE.2007.32.

[40] N. Capit et al. "A batch scheduler with high level components". In: *CCGrid 2005. IEEE International Symposium on Cluster Computing and the Grid, 2005*. Vol. 2. 2005, 776-783 Vol. 2. DOI: 10.1109/CCGRID.2005.1558641.

[41] U. Narayan Bhat. *An Introduction to Queueing Theory*. Birkhauser, 2008.

[42] Ali El Hadi Noura. *Integration of Scheduler Knowledge into CiGri Control Loop*. 2022.

[43] Domenico Ferrari and Songnian Zhou. "An Empirical Investigation of Load Indices For Load Balancing Applications". In: *Proceedings of Performance '87* the 12th International Symposium on Computer Performance Modeling.Measurement, and Evaluation (1988), pp. 515-528. URL: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-353.pdf.

[44] Joseph Emeras et al. "Analysis of the Jobs Resource Utilization on a Production System". In: *Job Scheduling Strategies for Parallel Processing*. Ed. by Narayan Desai and Walfredo Cirne. Berlin, Heidelberg: Springer Berlin Heidelberg, 2014, pp. 1-21. ISBN: 978-3-662-43779-7.

[45] Joseph L. Hellerstein et al. *Feedback Control of Computing Systems*. WILEY IN-TERSCIENCE, 2004.

[46] Ioan Doré Landau et al. *Adaptive Control: Algorithms, Analysis, and Applications*. Springer, 2011.

[47] Stepan Shevtsov and Danny Weyns. "Keep It SIMPLEX: Satisfying Multiple Goals with Guarantees in Control-Based Self-Adaptive Systems". In: *Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering*. FSE 2016. Seattle, WA, USA: Association for Computing Machinery, 2016, pp. 229-241. ISBN: 9781450342186. DOI: 10.1145/2950290.2950301. URL: https://doi.org/10.1145/2950290.2950301.

[48] Martina Maggio, Cristian Klein, and Karl-Erik Årzén. "Control strategies for predictable brownouts in cloud computing". In: *IFAC Proceedings Volumes* 47.3 (2014). 19th IFAC World Congress, pp. 689-694. ISSN: 1474-6670. DOI: https://doi.org/10.3182/20140824-6-ZA-1003.00669. URL: https://www.sciencedirect.com/science/article/pii/S1474667016416940.

[49] Stepan Shevtsov, M. Usman Iftikhar, and Danny Weyns. "SimCA vs ActivFORMS: Comparing Control- and Architecture-Based Adaptation on the TAS Exemplar". In: *Proceedings of the 1st International Workshop on Control Theory for Software*
[39] Yiannis Georgiou, Olivier Richard, and Nicolas Capit. "Evaluations of the Lightweight Grid CIGRI upon the Grid5000 Platform". In: *Third IEEE International Conference on e-Science and Grid Computing (e-Science 2007)*. 2007, pp. 279-286. DOI: 10.1109/E-SCIENCE.2007.32.

[40] N. Capit et al. "A batch scheduler with high level components". In: *CCGrid 2005. IEEE International Symposium on Cluster Computing and the Grid, 2005*. Vol. 2. 2005, 776-783 Vol. 2. DOI: 10.1109/CCGRID.2005.1558641.

[41] U. Narayan Bhat. *An Introduction to Queueing Theory*. Birkhauser, 2008.

[42] Ali El Hadi Noura. *Integration of Scheduler Knowledge into CiGri Control Loop*. 2022.

[43] Domenico Ferrari and Songnian Zhou. "An Empirical Investigation of Load Indices For Load Balancing Applications". In: *Proceedings of Performance '87* the 12th International Symposium on Computer Performance Modeling.Measurement, and Evaluation (1988), pp. 515-528. URL: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-353.pdf.

[44] Joseph Emeras et al. "Analysis of the Jobs Resource Utilization on a Production System". In: *Job Scheduling Strategies for Parallel Processing*. Ed. by Narayan Desai and Walfredo Cirne. Berlin, Heidelberg: Springer Berlin Heidelberg, 2014, pp. 1-21. ISBN: 978-3-662-43779-7.

[45] Joseph L. Hellerstein et al. *Feedback Control of Computing Systems*. WILEY IN-TERSCIENCE, 2004.

[46] Ioan Doré Landau et al. *Adaptive Control: Algorithms, Analysis, and Applications*. Springer, 2011.

[47] Stepan Shevtsov and Danny Weyns. "Keep It SIMPLEX: Satisfying Multiple Goals with Guarantees in Control-Based Self-Adaptive Systems". In: *Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering*. FSE 2016. Seattle, WA, USA: Association for Computing Machinery, 2016, pp. 229-241. ISBN: 9781450342186. DOI: 10.1145/2950290.2950301. URL: https://doi.org/10.1145/2950290.2950301.

[48] Martina Maggio, Cristian Klein, and Karl-Erik Årzén. "Control strategies for predictable brownouts in cloud computing". In: *IFAC Proceedings Volumes* 47.3 (2014). 19th IFAC World Congress, pp. 689-694. ISSN: 1474-6670. DOI: https://doi.org/10.3182/20140824-6-ZA-1003.00669. URL: https://www.sciencedirect.com/science/article/pii/S1474667016416940.

[49] Stepan Shevtsov, M. Usman Iftikhar, and Danny Weyns. "SimCA vs ActivFORMS: Comparing Control- and Architecture-Based Adaptation on the TAS Exemplar". In: *Proceedings of the 1st International Workshop on Control Theory for Software*
*Engineering*. CTSE 2015. Bergamo, Italy: Association for Computing Machinery, 2015, pp. 1–8. ISBN: 9781450338141. DOI: 10.1145/2804337.2804338. URL: https://doi.org/10.1145/2804337.2804338.

[50] K.J. Åström and B. Wittenmark. "On self tuning regulators". In: *Automatica* 9.2 (1973), pp. 185–199. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(73)90073-3. URL: https://www.sciencedirect.com/science/article/pii/0005109873900733.

[51] L. Ljung and T. Soderstrom. *Theory and practice of recursive identification*. MIT Press, 1983.

[52] Karl J. Astrom and Wittenmark Bjorn. *Adaptive Control*. second edition. DOVER PUBLICATIONS, 2008.

[53] K.J. Åström et al. "Theory and applications of self-tuning regulators". In: *Automatica* 13.5 (1977), pp. 457–476. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(77)90067-X. URL: https://www.sciencedirect.com/science/article/pii/000510987790067X.

[54] Brian D.O. Anderson. "Adaptive systems, lack of persistency of excitation and bursting phenomena". In: *Automatica* 21.3 (1985), pp. 247–258. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(85)90058-5. URL: https://www.sciencedirect.com/science/article/pii/0005109885900585.

[55] P Navrátil and V Bobál. "Recursive identification algorithms library". In: *Proceedings 17th International Conference on Process Control*. 2009, pp. 516–523.

[56] T.R. Fortescue, L.S. Kershenbaum, and B.E. Ydstie. "Implementation of self-tuning regulators with variable forgetting factors". In: *Automatica* 17.6 (1981), pp. 831–835. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(81)90070-4. URL: https://www.sciencedirect.com/science/article/pii/0005109881900704.

[57] Jennifer Hsu Hill and B. Erik Ydstie. "Adaptive control with selective memory". In: *International Journal of Adaptive Control and Signal Processing* 18.7 (2004), pp. 571–587. DOI: https://doi.org/10.1002/acs.819. eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/acs.819. URL: https://onlinelibrary.wiley.com/doi/abs/10.1002/acs.819.

[58] Grid5000. "Documentation about the cluster in NAncy". In:(). URL: https://www.grid5000.fr/w/Hardware.

[59] Quentin Guillentau et al. "Folding a Cluster containing a Distributed File-System". In: *HAL* (2023). URL: https://hal.science/hal-04038000.
*Engineering*. CTSE 2015. Bergamo, Italy: Association for Computing Machinery, 2015, pp. 1–8. ISBN: 9781450338141. DOI: 10.1145/2804337.2804338. URL: https://doi.org/10.1145/2804337.2804338.

[50] K.J. Åström and B. Wittenmark. "On self tuning regulators". In: *Automatica* 9.2 (1973), pp. 185–199. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(73)90073-3. URL: https://www.sciencedirect.com/science/article/pii/0005109873900733.

[51] L. Ljung and T. Soderstrom. *Theory and practice of recursive identification*. MIT Press, 1983.

[52] Karl J. Astrom and Wittenmark Bjorn. *Adaptive Control*. second edition. DOVER PUBLICATIONS, 2008.

[53] K.J. Åström et al. "Theory and applications of self-tuning regulators". In: *Automatica* 13.5 (1977), pp. 457–476. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(77)90067-X. URL: https://www.sciencedirect.com/science/article/pii/000510987790067X.

[54] Brian D.O. Anderson. "Adaptive systems, lack of persistency of excitation and bursting phenomena". In: *Automatica* 21.3 (1985), pp. 247–258. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(85)90058-5. URL: https://www.sciencedirect.com/science/article/pii/0005109885900585.

[55] P Navrátil and V Bobál. "Recursive identification algorithms library". In: *Proceedings 17th International Conference on Process Control*. 2009, pp. 516–523.

[56] T.R. Fortescue, L.S. Kershenbaum, and B.E. Ydstie. "Implementation of self-tuning regulators with variable forgetting factors". In: *Automatica* 17.6 (1981), pp. 831–835. ISSN: 0005-1098. DOI: https://doi.org/10.1016/0005-1098(81)90070-4. URL: https://www.sciencedirect.com/science/article/pii/0005109881900704.

[57] Jennifer Hsu Hill and B. Erik Ydstie. "Adaptive control with selective memory". In: *International Journal of Adaptive Control and Signal Processing* 18.7 (2004), pp. 571–587. DOI: https://doi.org/10.1002/acs.819. eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/acs.819. URL: https://onlinelibrary.wiley.com/doi/abs/10.1002/acs.819.

[58] Grid5000. "Documentation about the cluster in NAncy". In:(). URL: https://www.grid5000.fr/w/Hardware.

[59] Quentin Guillentau et al. "Folding a Cluster containing a Distributed File-System". In: *HAL* (2023). URL: https://hal.science/hal-04038000.
List of Figures

<table>
  <tbody>
    <tr>
      <td>1.1</td>
      <td>Torus design network [5].</td>
      <td>4</td>
    </tr>
    <tr>
      <td>1.2</td>
      <td>Fat tree network.</td>
      <td>4</td>
    </tr>
    <tr>
      <td>1.3</td>
      <td>Picture of CRAY-1 with his peculiar C shape [10].</td>
      <td>5</td>
    </tr>
    <tr>
      <td>1.4</td>
      <td>Representation of RJMS connected with both the user and cluster [11].</td>
      <td>6</td>
    </tr>
    <tr>
      <td>1.5</td>
      <td>Functional detail of the autonomic manager [24].</td>
      <td>10</td>
    </tr>
    <tr>
      <td>1.6</td>
      <td>Reinterpretation of MAPE-K loop [25].</td>
      <td>11</td>
    </tr>
    <tr>
      <td>1.7</td>
      <td>Simple control scheme.</td>
      <td>12</td>
    </tr>
    <tr>
      <td>1.8</td>
      <td>PID control loop in discrete time.</td>
      <td>15</td>
    </tr>
    <tr>
      <td>2.1</td>
      <td>Geography representation of Grid5000 [38].</td>
      <td>18</td>
    </tr>
    <tr>
      <td>2.2</td>
      <td>Schematic picture of CIGRI.</td>
      <td>19</td>
    </tr>
    <tr>
      <td>2.3</td>
      <td>Representation of two OARs for two different clusters. The queue linked to CIGRI is the Best-Effort queue while the other is the High-Preority queue.</td>
      <td>21</td>
    </tr>
    <tr>
      <td>2.4</td>
      <td>Example of a GANTT chart [42].</td>
      <td>22</td>
    </tr>
    <tr>
      <td>2.5</td>
      <td>Overall system [15].</td>
      <td>23</td>
    </tr>
    <tr>
      <td>2.6</td>
      <td>Picture of the file system closed loop.</td>
      <td>24</td>
    </tr>
    <tr>
      <td>2.7</td>
      <td>Study of the difference between the two approximations b̃ and b̃ for the different file size.</td>
      <td>28</td>
    </tr>
    <tr>
      <td>2.8</td>
      <td>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.</td>
      <td>29</td>
    </tr>
    <tr>
      <td>2.9</td>
      <td>Proportional-Integrative controller.</td>
      <td>31</td>
    </tr>
    <tr>
      <td>2.10</td>
      <td>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</td>
      <td>33</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Classic scheme of self-tuning approach.</td>
      <td>37</td>
    </tr>
  </tbody>
</table>
List of Figures

<table><tbody><tr><td>1.1</td><td>Torus design network [5].</td><td>4</td></tr><tr><td>1.2</td><td>Fat tree network.</td><td>4</td></tr><tr><td>1.3</td><td>Picture of CRAY-1 with his peculiar C shape [10].</td><td>5</td></tr><tr><td>1.4</td><td>Representation of RJMS connected with both the user and cluster [11].</td><td>6</td></tr><tr><td>1.5</td><td>Functional detail of the autonomic manager [24].</td><td>10</td></tr><tr><td>1.6</td><td>Reinterpretation of MAPE-K loop [25].</td><td>11</td></tr><tr><td>1.7</td><td>Simple control scheme.</td><td>12</td></tr><tr><td>1.8</td><td>PID control loop in discrete time.</td><td>15</td></tr><tr><td>2.1</td><td>Geography representation of Grid5000 [38].</td><td>18</td></tr><tr><td>2.2</td><td>Schematic picture of CIGRI.</td><td>19</td></tr><tr><td>2.3</td><td>Representation of two OARs for two different clusters. The queue linked to CIGRI is the Best-Effort queue while the other is the High-Preority queue.</td><td>21</td></tr><tr><td>2.4</td><td>Example of a GANTT chart [42].</td><td>22</td></tr><tr><td>2.5</td><td>Overall system [15].</td><td>23</td></tr><tr><td>2.6</td><td>Picture of the file system closed loop.</td><td>24</td></tr><tr><td>2.7</td><td>Study of the difference between the two approximations b̃ and b̃ for the different file size.</td><td>28</td></tr><tr><td>2.8</td><td>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.</td><td>29</td></tr><tr><td>2.9</td><td>Proportional-Integrative controller.</td><td>31</td></tr><tr><td>2.10</td><td>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</td><td>33</td></tr><tr><td>3.1</td><td>Classic scheme of self-tuning approach.</td><td>37</td></tr></tbody></table>
<table>
  <tbody>
    <tr>
      <td>3.2</td>
      <td>Effect of the bursting phenomena in ŷ [54].</td>
      <td>41</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Identification results for varying α in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to b̂, while the red dashed line corresponds to ˜b̂.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>Tracking results for varying α in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to y, while the red dashed line corresponds to y<sub>ref</sub>.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.3</td>
      <td>Boxplots depicting the relative percentage error in absolute value across various α values. (a) Shows the identification error, while (b) shows the tracking error.</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.4</td>
      <td>Identification results. b̂ is shown in blue line, and ˜b̂ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.5</td>
      <td>Tracking results. y is shown in blue line, and y<sub>ref</sub> in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.6</td>
      <td>Each boxplot represents the relative percentage error in absolute value for each algorithm. (a) Represents the identification error, and (b) represents the tracking error.</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.7</td>
      <td>The three algorithms' identification results: b̂<sub>u</sub> is shown in blue line, and b<sub>u</sub> in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.8</td>
      <td>The three algorithms' identification results are displayed: b̂<sub>d</sub> is shown in blue line, and b<sub>d</sub> in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>56</td>
    </tr>
    <tr>
      <td>4.9</td>
      <td>The three tracking results are displayed: y is shown in blue line, and y<sub>ref</sub> in red dashed line, and the impact of HP jobs is depicted in black dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>57</td>
    </tr>
    <tr>
      <td>4.10</td>
      <td>Results with different initial conditions. In row (a), we examine the scenario where b̂(0) = 0.5, while in row (b), we observe the case where b̂(0) = 0.15.</td>
      <td>59</td>
    </tr>
    <tr>
      <td>4.11</td>
      <td>Results for the scenario where b̂(0) = 0.03. The blue line represents the average across five distinct experiments. Within the estimation visualization, the red dashed line corresponds to ˜b̂, while in the file server load illustration, the red dashed line signifies the reference load.</td>
      <td>60</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>3.2</td>
      <td>Effect of the bursting phenomena in ŷ [54].</td>
      <td>41</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Identification results for varying α in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to b̂, while the red dashed line corresponds to ˜b̂.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>Tracking results for varying α in the range of 0.5 to 3 with increments of 0.5. The blue line corresponds to y, while the red dashed line corresponds to y<sub>ref</sub>.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.3</td>
      <td>Boxplots depicting the relative percentage error in absolute value across various α values. (a) Shows the identification error, while (b) shows the tracking error.</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.4</td>
      <td>Identification results. b̂ is shown in blue line, and ˜b̂ in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.5</td>
      <td>Tracking results. y is shown in blue line, and y<sub>ref</sub> in red dashed line. Figure (a) depicts results for the Parallel algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>4.6</td>
      <td>Each boxplot represents the relative percentage error in absolute value for each algorithm. (a) Represents the identification error, and (b) represents the tracking error.</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.7</td>
      <td>The three algorithms' identification results: b̂<sub>u</sub> is shown in blue line, and b<sub>u</sub> in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>55</td>
    </tr>
    <tr>
      <td>4.8</td>
      <td>The three algorithms' identification results are displayed: b̂<sub>d</sub> is shown in blue line, and b<sub>d</sub> in red dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>56</td>
    </tr>
    <tr>
      <td>4.9</td>
      <td>The three tracking results are displayed: y is shown in blue line, and y<sub>ref</sub> in red dashed line, and the impact of HP jobs is depicted in black dashed line. Figure (a) depicts results for the Parallel Algorithm, (b) for the Robust, and (c) for the Selective Algorithm.</td>
      <td>57</td>
    </tr>
    <tr>
      <td>4.10</td>
      <td>Results with different initial conditions. In row (a), we examine the scenario where b̂(0) = 0.5, while in row (b), we observe the case where b̂(0) = 0.15.</td>
      <td>59</td>
    </tr>
    <tr>
      <td>4.11</td>
      <td>Results for the scenario where b̂(0) = 0.03. The blue line represents the average across five distinct experiments. Within the estimation visualization, the red dashed line corresponds to ˜b̂, while in the file server load illustration, the red dashed line signifies the reference load.</td>
      <td>60</td>
    </tr>
  </tbody>
</table>
<figure><img src="image_49.png" /></figure>
<figure><img src="image_49.png" /></figure>
# List of Tables

4.1 A comparison of the two separate systems’ outcomes for a different file size. 68
List of Tables

4.1 A comparison of the two separate systems’ outcomes for a different file size. 68
<figure><img src="image_50.png" /></figure>
<figure><img src="image_50.png" /></figure>
List of Symbols

<table><thead><tr><th>Variable</th><th>Description</th><th>SI unit</th></tr></thead><tbody><tr><td>'</td><td>Transpose</td><td></td></tr><tr><td>α</td><td>Parameter for the robust algorithm</td><td></td></tr><tr><td>Δ</td><td>Parameter for select data</td><td></td></tr><tr><td>ε</td><td>Prediction error</td><td></td></tr><tr><td>θ</td><td>Vector which gather all the unknown parameter</td><td></td></tr><tr><td>θ̂</td><td>Estimation of Θ from the algorithm</td><td></td></tr><tr><td>μ</td><td>Forgetting factor</td><td></td></tr><tr><td>ξ</td><td>Parameter of the exponential filter</td><td></td></tr><tr><td>σ</td><td>Time constant for the variance r</td><td></td></tr><tr><td>φ</td><td>Regressor vector</td><td></td></tr><tr><td>b</td><td>Weight of a single BE job inside the file system</td><td></td></tr><tr><td>b̃</td><td>Eq. 2.6 for the computation of b</td><td></td></tr><tr><td>b̃̃</td><td>Eq. 2.7 for the computation of b</td><td></td></tr><tr><td>b̂</td><td>b estimated by the algorithm</td><td></td></tr><tr><td>b<sub>d</sub></td><td>Single HP job file server weight</td><td></td></tr><tr><td>b̂<sub>d</sub></td><td>Estimation of the algorithm of b<sub>d</sub></td><td></td></tr><tr><td>b<sub>u</sub></td><td>Single BE job file server weight, in the case of double estimation</td><td></td></tr><tr><td>b̂<sub>u</sub></td><td>Estimation of the algorithm of b<sub>u</sub></td><td></td></tr><tr><td>d</td><td>Disturbance (number of HP jobs)</td><td></td></tr><tr><td>e</td><td>Sensor's noise</td><td></td></tr><tr><td>f</td><td>File Size</td><td>MByte</td></tr></tbody></table>
List of Symbols

<table><thead><tr><th>Variable</th><th>Description</th><th>SI unit</th></tr></thead><tbody><tr><td>'</td><td>Transpose</td><td></td></tr><tr><td>α</td><td>Parameter for the robust algorithm</td><td></td></tr><tr><td>Δ</td><td>Parameter for select data</td><td></td></tr><tr><td>ε</td><td>Prediction error</td><td></td></tr><tr><td>θ</td><td>Vector which gather all the unknown parameter</td><td></td></tr><tr><td>θ̂</td><td>Estimation of Θ from the algorithm</td><td></td></tr><tr><td>μ</td><td>Forgetting factor</td><td></td></tr><tr><td>ξ</td><td>Parameter of the exponential filter</td><td></td></tr><tr><td>σ</td><td>Time constant for the variance r</td><td></td></tr><tr><td>φ</td><td>Regressor vector</td><td></td></tr><tr><td>b</td><td>Weight of a single BE job inside the file system</td><td></td></tr><tr><td>b̃</td><td>Eq. 2.6 for the computation of b</td><td></td></tr><tr><td>b̃̃</td><td>Eq. 2.7 for the computation of b</td><td></td></tr><tr><td>b̂</td><td>b estimated by the algorithm</td><td></td></tr><tr><td>b<sub>d</sub></td><td>Single HP job file server weight</td><td></td></tr><tr><td>b̂<sub>d</sub></td><td>Estimation of the algorithm of b<sub>d</sub></td><td></td></tr><tr><td>b<sub>u</sub></td><td>Single BE job file server weight, in the case of double estimation</td><td></td></tr><tr><td>b̂<sub>u</sub></td><td>Estimation of the algorithm of b<sub>u</sub></td><td></td></tr><tr><td>d</td><td>Disturbance (number of HP jobs)</td><td></td></tr><tr><td>e</td><td>Sensor's noise</td><td></td></tr><tr><td>f</td><td>File Size</td><td>MByte</td></tr></tbody></table>
<table><thead><tr><th>Variable</th><th>Description</th><th>SI unit</th></tr></thead><tbody><tr><td><i>h</i></td><td>Discretization time</td><td>s</td></tr><tr><td><i>K</i><sub>D</sub></td><td>Derivative coefficient for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>I</sub></td><td>Integrative coefficient for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>p</sub></td><td>Proportional parameter for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>s</sub></td><td>PI Settling Time in Iterations</td><td></td></tr><tr><td><i>M</i><sub>0</sub></td><td>Memory length</td><td></td></tr><tr><td><i>M</i><sub>p</sub></td><td>Initial overshoot allowed as a percentage of the output</td><td></td></tr><tr><td><i>n</i></td><td>Noise of the sensor</td><td></td></tr><tr><td><i>r</i></td><td>Estimating unconsidered model variance</td><td></td></tr><tr><td><i>S</i></td><td>Information matrix</td><td></td></tr><tr><td><i>u</i></td><td>Control action of the controller, number of BE jobs</td><td></td></tr><tr><td><i>V</i></td><td>Covariance matrix</td><td></td></tr><tr><td><i>y</i></td><td>Measured load of the file system</td><td></td></tr><tr><td><i>ŷ</i></td><td>Estimated load of the file system</td><td></td></tr></tbody></table>
<table><thead><tr><th>Variable</th><th>Description</th><th>SI unit</th></tr></thead><tbody><tr><td><i>h</i></td><td>Discretization time</td><td>s</td></tr><tr><td><i>K</i><sub>D</sub></td><td>Derivative coefficient for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>I</sub></td><td>Integrative coefficient for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>p</sub></td><td>Proportional parameter for the PI controller</td><td></td></tr><tr><td><i>K</i><sub>s</sub></td><td>PI Settling Time in Iterations</td><td></td></tr><tr><td><i>M</i><sub>0</sub></td><td>Memory length</td><td></td></tr><tr><td><i>M</i><sub>p</sub></td><td>Initial overshoot allowed as a percentage of the output</td><td></td></tr><tr><td><i>n</i></td><td>Noise of the sensor</td><td></td></tr><tr><td><i>r</i></td><td>Estimating unconsidered model variance</td><td></td></tr><tr><td><i>S</i></td><td>Information matrix</td><td></td></tr><tr><td><i>u</i></td><td>Control action of the controller, number of BE jobs</td><td></td></tr><tr><td><i>V</i></td><td>Covariance matrix</td><td></td></tr><tr><td><i>y</i></td><td>Measured load of the file system</td><td></td></tr><tr><td><i>ŷ</i></td><td>Estimated load of the file system</td><td></td></tr></tbody></table>
Acknowledgements

Firstly, I would like to thank the people who followed me at Grenoble, Sophie Cerf, Bogdan Robu, Raphael Bleuse, and Eric Rutten. Furthermore, I would like to thank also my relator, Alberto Leva, who gave me the chance to do this thesis abroad.

Afterward, I would like to thank all my friends in Milan both the ones from physics engineering and automation engineering. Your friendship was fundamental for me to continue my studies and follow what I like the most. Then, I would like to thank my friends from Civitanova Marche, you are my home when I think that I have no one. Thank you for helping me when I needed it.

Then I would like to thank my family. Moreover, I would like to thank my parents for their patience when I was a teenager. Without your choices, I couldn't be here, so thank you. Then I would like to mention also my brother, Luigi (Giggi), who is very important to me.

Lastly, I would like to thank my boyfriend, Stefano. Thank you for listening to me every time that I complain and I do not believe in myself. I do not know how I could handle all the changes without you. And I'm sure that whatever happens, you will make me smile, then thank you for being with me in this experience and the next.
Acknowledgements

Firstly, I would like to thank the people who followed me at Grenoble, Sophie Cerf, Bogdan Robu, Raphael Bleuse, and Eric Rutten. Furthermore, I would like to thank also my relator, Alberto Leva, who gave me the chance to do this thesis abroad.

Afterward, I would like to thank all my friends in Milan both the ones from physics engineering and automation engineering. Your friendship was fundamental for me to continue my studies and follow what I like the most. Then, I would like to thank my friends from Civitanova Marche, you are my home when I think that I have no one. Thank you for helping me when I needed it.

Then I would like to thank my family. Moreover, I would like to thank my parents for their patience when I was a teenager. Without your choices, I couldn't be here, so thank you. Then I would like to mention also my brother, Luigi (Giggi), who is very important to me.

Lastly, I would like to thank my boyfriend, Stefano. Thank you for listening to me every time that I complain and I do not believe in myself. I do not know how I could handle all the changes without you. And I'm sure that whatever happens, you will make me smile, then thank you for being with me in this experience and the next.
<figure><img src="image_51.png" /></figure>
<figure><img src="image_51.png" /></figure>
Ringraziamenti

Vorrei iniziare con i ringraziamenti per le persone che hanno reso questo lavoro possibile.
Vorrei ringraziare Sophie Cerf, Bogdan Robu, Raphael Bleuse e Eric Rutten per avermi
seguito a Grenoble durante i mesi che sono stata lì. Inoltre vorrei ringraziare anche il mio
relatore, il professor Alberto Leva, per avermi dato la possibilità di fare la tesi all'estero.

Vorrei ringraziare tutti i miei amici che ho conosciuto a Milano, sia quelli di ingegneria fisica che quelli di automazione. La vostra amicizia è state fondamentale per il normale conseguimento dei miei studi e mi avete dato sempre la forza di seguire ciò che più mi piacesse.

Poi, vorrei ringraziare i miei amici storici di Civitanova Marche, siete la mia casa quando
penso di non averne nessuna. Grazie per esserci sempre.

Vorrei ringraziare la mia famiglia. Soprattutto i miei genitori per la pazienza che hanno
avuto nei miei confronti quando ero un'adolescente. Senza le vostre scelte non sarei mai
diventata ciò che sono. Grazie. Vorrei anche ringraziare mio fratello, Luigi (Giggi), che è
davvero molto importante per me.

Infine, vorrei ringraziare il mio fidanzato Stefano. Grazie per aver sempre ascoltato tutte
le mie lamentele e tutte le volte che non credevo in me. Non so come avrei affrontato
questa nuova esperienza senza di te. Sono sicura che qualsiasi cosa accada, mi farai
sempre sorridere, quindi grazie per avermi seguito in questa esperienza ed esserci anche
nella prossima.
## Ringraziamenti

Vorrei iniziare con i ringraziamenti per le persone che hanno reso questo lavoro possibile. Vorrei ringraziare Sophie Cerf, Bogdan Robu, Raphael Bleuse e Eric Rutten per avermi seguito a Grenoble durante i mesi che sono stata lì. Inoltre vorrei ringraziare anche il mio relatore, il professor Alberto Leva, per avermi dato la possibilità di fare la tesi all'estero.

Vorrei ringraziare tutti i miei amici che ho conosciuto a Milano, sia quelli di ingegneria fisica che quelli di automazione. La vostra amicizia è state fondamentale per il normale conseguimento dei miei studi e mi avete dato sempre la forza di seguire ciò che più mi piacesse.

Poi, vorrei ringraziare i miei amici storici di Civitanova Marche, siete la mia casa quando penso di non averne nessuna. Grazie per esserci sempre.

Vorrei ringraziare la mia famiglia. Soprattutto i miei genitori per la pazienza che hanno avuto nei miei confronti quando ero un'adolescente. Senza le vostre scelte non sarei mai diventata ciò che sono. Grazie. Vorrei anche ringraziare mio fratello, Luigi (Giggi), che è davvero molto importante per me.

Infine, vorrei ringraziare il mio fidanzato Stefano. Grazie per aver sempre ascoltato tutte le mie lamentele e tutte le volte che non credevo in me. Non so come avrei affrontato questa nuova esperienza senza di te. Sono sicura che qualsiasi cosa accada, mi farai sempre sorridere, quindi grazie per avermi seguito in questa esperienza ed esserci anche nella prossima.
<figure><img src="image_52.png" /></figure>
<figure><img src="image_52.png" /></figure>