\newpage

Ejercicio 8

A continuación se muestran los diferentes casos de prueba realizados para comparar los diferentes tipos de schedulers. Se eligieron los siguientes casos de prueba ya que creemos que son los casos que más se acercan a la realidad:

Uso intensivo CPU: Para simular casos de, por ejemplo, procesamiento de imágen o video.
Uso intensivo IO: Para simular situaciones en las que se lea mucha información del disco continuamente (como falta de memoria RAM).
Picos esporádicos CPU con IO: Para simular casos de uso normal de usuario.

Para cada caso se creó un lote de tareas específicos llamados cpu.tsk, cpu_ioh.tsk y cpuh_io.tsk respectivamente. En todos los gráficos de barras que se muestran a continuación se muestran los promedios obtenidos de cada ejecución. Cada barra representa que hizo cada ticks de CPU que hubo.

Uso intensivo CPU

Single core

Caso "básico" con 12 taskCPU, 1 core, context switch de 2 ticks, podemos observar que FCFS, RSJF y SJF se comportan de manera muy similar. En los tres casos se ve que la latencia y tiempo ready (waiting time) son muy similares. Esto se debe al tipo de implementación es similar, esperando a que termine cada tarea para desalojarla. En el caso del RSJF, como son tareas con CPU intensivo, no hay tantos cambios de contexto. En cambio, RR tiene una latencia mucho menor (~la mitad), pero por la naturaleza de este scheduler el mean turnaround time es mucho más alto (~7x).

\newpage

A diferencia del caso anterior, el context switch en esta prueba cuesta 12 ticks. La única modificación que hicimos fue mantener la relación entre ticks de context switch y quantums ( (2,5) => (12,30) ) En éste caso se puede ver que todos los schedulers se comportan de manera similar, ya que como el quantum es mayor que el tiempo que demora cada tarea en completarse, todas se comportan como un scheduler FIFO.

Multi core

Caso "básico" con 12 taskCPU, 4 core, context switch de 2 ticks, podemos observar que FCFS y SJF se comportan de manera muy similar.

RSJF: Incrementa ligeramente la latencia y el turnaround comparado a SJF.

RR: tiene una latencia mucho menor (~la mitad), pero por la naturaleza de este scheduler el mean turnaround time es mucho más alto (~2.5x) que en los otros schedulers.

A diferencia del caso anterior, el context switch en esta prueba cuesta 12 ticks. La única modificación que hicimos fue mantener la relación entre ticks de context switch y quantums ( (2,5) => (12,30) ) En éste caso se puede ver que FCFS, RR y SJF se comportan de manera similar. Como en casos anteriores, el hecho de que el quantum sea muy alto, hace que todos los scheduler se comporten como el scheduler FIFO.

Uso intensivo IO

Single core

En este caso hay 15 tareas, 11 son TaskBatch y 4 TaskCPU. Tantos IO hacen que la performance del scheduler RR sea mejor de lo esperado (context switch barato en relacion a duracion de IO).

En este caso hay 15 tareas, 11 son TaskBatch y 4 TaskCPU. Tantos IO hacen que la performance del scheduler RR sea pésima (context switch caro en relacion a duracion de IO).

Multi core

En este caso se puede ver que el scheduler Round Robin, aunque con menor latencia, tiene mucho waiting time. Esto está relacionado con los informado en el ejercicio 4, que al no tener CPU pinning pierde la mayor parte del tiempo haciendo CPU switch.