# A System for Sustainable Usage of Computing Resources Leveraging Deep Learning Predictions
## 4 Results
#### Resource Usage Impact  
This section discusses the significance of the more detailed results we collected in view of understanding how the algorithm's application in a production system would influence power consumption. We devised an experiment for measuring the fitness of the  
Figure 11: Sample validation predictions—LSTM. Figure 12: MAE and loss—LSTM training. forecasts provided by the best algorithm implementation out of the ones that were studied, the RNN solution. We name ratio the amount of 5-minute time-intervals that the algorithm should consider as being under heavy load. The experiment was performed on the validation data, roughly 2 days, from the 24-25 January 2022. The \"ratio\" value represents the instant when a prediction considers scaling up the system (for example, from 1 to 2 containers). We simplified the model by assuming the system uses 0 units of power when the predicted value is below the threshold and 1 when the prediction is over the ratio value. By computing some statistics (which can be consulted in Table 6), we can compare the number of instances when the system should ideally scale up or down to the real predictions. We look at the real instances in which the system went over the threshold of computing power needed to scale up (the ratio) and measure how many times the prediction was correct, allowing us to understand the amount of true positives in the system. When the predicted or real value for the CPU usage is not above the ratio, we consider that the system is scaled down, using 0 units of power for that interval of time. Figure 14: MAE and loss—CNN training. Figure 13: MAE and loss—RNN training. We took both the training and the validation data in the table, in order to see that the performance of the system is not significantly worse on the validation data. The legend for Table 6 is the following:  
* Ratio--the CPU usage over which the system should scale up. * Real Over--the number of real instances in which the CPU usage surpassed the value (training + test data). * Forecast Over--the number of forecasts where the CPU usage is above the ratio value. * Real All % Over--the percentage of real predictions where the CPU usage values were over the ratio. * All % Over--the percentage of forecasts where the CPU usage values were over the ratio. * Val. Real Over--the number of real instances where the values where over the ratio in the validation data. * Val. Over--the number of forecast instances where the values where over the ratio in the validation data. * Val. Real %--the percentage of real measurements where the CPU usage values were over the ratio in the validation data. * Val.%--the percentage of forecasts where the CPU usage values were over the ratio in the validation data. We can observe that the real CPU usage is lower than the predicted one when taking the threshold lower than 0.4 (both for the training and validation data). For example, at 0.2 the forecast is over that value 79.8% of the time while the real values were around 55.2%. This shows a trend for the algorithm to overestimate the amount of CPU resources needed at a certain point in time, which is not necessarily something undesirable. However, in the context of lowering energy consumption, the best iteration of the algorithm for us is the one that provides forecasts at all the instances when they also occur (5 min in the future). However, when we look at the values when the ratio is larger than 0.4, it can be observed that the predictions and the real CPU usage converge. This means that on most instances where the CPU usage was over the ratio, the forecasting algorithm predicted similar values. As these are 5 min time-frames, this is desirable since the scaling does not have to occur instantly and can smoothly take place. This is to be expected of a heuristic in general and should be used only as an informative item. In practice, scaling around 40-50% seems to give results that are promising enough and would work in a real-life implementation.