# A Novel Fault-Tolerant Aware Task Scheduler Using Deep Reinforcement Learning in Cloud Computing
## 5 Simulation and Results
### Analysis and Discussion of Results  
In this section, a detailed analysis and discussion of results which we presented earlier in Sections 5.2-5.13 are given. For the simulation of DRFTSA, we used Cloudsim [42] as the simulation platform. To evaluate our proposed DRFTSA, a real-time dataset was given as an input to the algorithm, i.e., the Google Cloud Jobs dataset from [43]. The entire dataset was categorized into two parts, i.e., regular and large datasets. After categorizing, different numbers of VMs for datasets are considered in different modes. For both regular and large datasets, we assigned VMs by fixing VMs in one scenario and varying VMs in another scenario. Extensive simulations were conducted by using the Google Cloud Jobs dataset, which is a real-time trace of a Google cluster. These VMs are varied linearly over the number of tasks in the dataset. The length of the tasks was 750,000 and when we used priorities for tasks and VMs and ran the simulation we observed that the proposed DRFTSA outperforms the existing approaches. DRFTSA was evaluated compared to existing algorithms, i.e., \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**No. of Tasks** & **PSO** & **GA** & **ACO** & **DRFTSA** \\ \hline
700 & 56.24 & 52.15 & 58.08 & 42.14 \\
800 & 53.14 & 58.06 & 61.43 & 34.23 \\
900 & 58.19 & 63.17 & 65.86 & 26.87 \\
1000 & 62.15 & 65.87 & 71.36 & 27.62 \\ \hline \hline \end{tabular}
\end{table} 
Table 15: Rate of failure for DRFTSA using large dataset by varying number of VMs. Figure 15: Calculation of rate of failure for large dataset by varying number of VMs. PSO, GA, and ACO approaches. When we compared the proposed DRFTSA against PSO, GA, and ACO, we observed that when VMs are fixed the makespan is slightly improved because there is fixed availability of VMs and even if we the increase workload on VMs that does not cause a significant change in makespan. However, when we vary the number of VMs, makespan improves compared with fixed VMs. Table 16 presents the improvement in average makespan of DRFTSA for regular and large datasets over existing algorithms. For the energy consumption, when we look at Table 17 it is clearly seen that for fixed number of VMs, energy consumption is not improved drastically but, when we varied VMs, energy consumption is improved compared to a fixed number of VMs. Table 17 presents the improvement in average energy consumption of DRFTSA for regular and large datasets over existing algorithms. Improvement of the rate of failure is observed in Table 18 as, if we fix VMs and keep on increasing load, a chance of failure occurs due to unavailable resources or unsuitable resources. However, when changing VMs, we observed that there is a clear improvement in the rate of failure, i.e., failures are greatly reduced. Table 18 presents the improvement in the average rate of failure of DRFTSA for regular and large datasets over existing algorithms. Cloud Jobs. The entire dataset is divided into two categories, i.e., regular and large datasets. These two categories of workload are given as an input to the algorithm for checking the efficacy of the scheduler. Extensive simulations are conducted on Cloudsim by considering VMs in different scenarios of fixed and varied VMs. For evaluating the efficacy of the proposed DRFTSA scheduler, we compared our proposed approach with the existing state-of-the-art algorithms, i.e., PSO, GA, and ACO. From the results, it is evident that the proposed DRFTSA shows a huge impact compared to the existing approaches by improving average makespan, rate of failure, and energy consumption for both scenarios, i.e., for fixed VMs and varied VMs. The main limitation in this research is that the scheduler not able to predict the upcoming tasks on the cloud application console. In future, we need to examine our DQN model to evaluate parameters i.e., total power cost, migration time, and trust-based parameters, and to evaluate the relationship between fault tolerance and trust.