## Appendix A Turnaround Time  
In the forthcoming sections of this Appendices A-D, as we explore **turnaround time**, **response time**, and **throughput** in more detail, all the ensuing graphs maintain a consistent structure. The y-axis represents time units from the global timer in GPenSIM, and the x-axis denotes the job ID in ascending order. It is essential to underscore that the jobs are sequenced based on their arrival times. Jobs with lower IDs will arrive in the system first, although there may be instances where some jobs arrive simultaneously. The initial figure in each subsection corresponds to short jobs, while the subsequent figure pertains to mixed jobs. It is crucial to note that a local queue may consist entirely of either short or long jobs. The mixed dataset simulation, having a longer overall duration, exhibits a wider spread in the arrival times of jobs throughout the simulation compared with the short dataset.  
Figures A1 and A2 visually represent turnaround times for individual jobs in the short and mixed datasets.  
The graphs show that FCFS shows a more linear trend, aligning with our expectations. This linearity is a result of the scheduling policy, where each job is processed in the order of its arrival in the queues. As jobs arrive later, they have to wait for the completion of the earlier jobs, leading to an increase in turnaround time for the later jobs. This wait time contributes to the linear progression of turnaround times in the FCFS scheduling algorithm.  
In the case of SJF, noticeable spikes in turnaround times are observed. This phenomenon primarily stems from jobs with longer remaining times experiencing starvation, introducing variations in turnaround times based on when a job with an extended execution time arrives in the queue.  
In contrast, RR exhibits significant variability in turnaround time, which depends on a job's total time as it runs for a fixed time quantum before switching out. This is particularly noticeable in Figure A6, where odd-numbered jobs have a short total time, while even-numbered jobs have a long total time, resulting in a zigzag pattern in the graph.  
Given that all jobs arrive with the highest priority in MLFQ, jobs with long running times may encounter notably high turnaround times when multiple jobs are present in the queue. These jobs often rely on the boosting mechanism to secure CPU time. This pattern is evident in both the short and mixed datasets.  
Since CFS selects jobs to run based on their \(\mathrm{vruntime}\), all jobs will eventually have a chance to run. However, the niceness parameter influences how frequently they will run, with lower niceness leading to a slower accumulation of \(\mathrm{vruntime}\) compared with higher niceness. This is especially apparent in Figure A5, where some early-arriving jobs still exhibit a high turnaround time. This suggests that these jobs may have an above-average niceness level or a significantly longer total time than other jobs.  
Figure 17: Turnaround time for short jobs.  
arrived jobs are consistently placed at the back of the queue, resulting in a \(|local\_queue|\cdot time\_quantum\) response time. While RR exhibits a reasonable response time, a computer with numerous concurrent tasks could lead to a subpar user experience.  
Both MLFQ and CFS exhibit remarkably low response times. CFS, however, displays significant outlines, particularly for jobs with high niceness levels. These jobs must wait until all lower niceness level jobs have been executed, resulting in extended response times. MLFQ, on the other hand, maintains low response times overall, with the highest outlines reaching around 25 time units. Both of these schedulers would be suitable choices for computers with interactive tasks, given the crucial importance of response time for a positive user experience. Their performance underscores the necessity of implementing some form of priority system to ensure responsive handling of interactive tasks.  
Figure 14: Response time for mixed jobs.