so-tp1/informe/8-informe.md

Ejercicio 8

Para este ejercicio se nos pide comparar experimentalmente varios de los schedulers que fueron trabajos en los ejercicios anteriores Round Robin, FIFO, SJF y RSJF.

Para poder entender los posibles escenarios para testear estos schedulers, identificamos dos componentes básicas(uso de CPU e I/O) que nos permitieron conformar los tipos de tareas(TasCPU, TaskConsola, TaskBATCH) que utilizamos en ejercicios anteriores. Dado que son dos componentes, inicialmente nos planteamos 3 tipos de escenarios:

• Escenario 1: Lotes con tasks que solo usen CPU.
• Escenario 2: Lotes con tasks que usen escencialmente I/O.
• Escenario 3: Alguna combinación de los dos anterior.

Pero luego, analizando los diferentes schedulers llegamos a la conclusión que excepto Round Robin ninguno de los otros tres schedulers sabe manejar bien las llamadas I/O y las terminan tratando como si fueran de uso de CPU, por lo tanto los escenarios 2 y 3 y su posterior análisis no agregan a la comparación más de lo que los casos del escenario 1 puedan agregar.

Entonces adentrandonos en el escenario 1, donde solo utilizaremos tareas que usen CPU, nos parece que las siguientes casos son los más relevantes:

• Escenario A: Lote con tasks chicas en relación al Quantum.
• Escenario B: Lote con tasks grandes en relación al Quantum.
• Escenario C: Un mix de los dos anteriores.

Experimentación

En esta sección analizaremos los diferentes escenarios planteados que nos interesan (A, B, C), para todos ellos utilizaremos Quantums, Context Switch y Core Switch de costo 4, 2 y 8 respectivamente, además de probar con 1 y 2 cores.

Escenario A:

En este escenario, nos plantemos utilizar varias tasks de tamaño chico en relación al Quantum. Consideramos que las tareas son de tamaño chico si su duración es cercana a 1 quantums y para experimentar utilizamos el siguiente lote:

Task	Tipo	Release time	n
0	TaskCPU	0	2
1	TaskCPU	0	4
2	TaskCPU	0	6
3	TaskCPU	4	2
4	TaskCPU	4	4
5	TaskCPU	4	6

A1

El siguiente grafico muestra los valores promedios obtenidos para cada scheduler.

A continuación se puede ver una tabla con los valores de Latencia, Turnaround y tiempo Ready.

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	14	14	16	12
M. Ready	15	14	16	15
M. Turnaround	5	4	4	7
Idle	1	1	1	1

De los diagramas de Gantt (ver anexo) y de los valores calculados se puede observar que todos los schedulers se comportan de manera similar (como un FCFS), ya que hasta el Round Robin deja terminar las tareas debido a que tienen una duración menor al quantum del mismo.

A2

A continuación se ejecuta el mismo lote pero en schedulers de dos cores.

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	6	5	6	5
M. Ready	8	5	6	5
M. Turnaround	6	4	4	4
Idle	3	5	1	5

Se puede observar que en todos los casos, el aumento de cores beneficia en mas de un 100% los tiempos de ejecución de cada scheduler, ninguno beneficiandose más en particular.

Escenario B:

En este escenario, nos plantemos utilizar varias tasks de tamaño grande en relación al Quantum. Consideramos que las tareas son de tamaño chico si su duración es cercana a 5 quantums y para experimentar utilizamos el siguiente lote:

Task	Tipo	Release time	n
0	TaskCPU	0	16
1	TaskCPU	0	20
2	TaskCPU	0	24
3	TaskCPU	20	16
4	TaskCPU	20	20
5	TaskCPU	20	24

1 Core

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	16	44	50	44
M. Ready	115	44	50	59
M. Turnaround	119	20	20	35
Idle	1	1	1	1

En procesos con un tamaño superior a los quantums, se puede observar que todos los schedulers no reentrantes siguen comportandose como el scheduler FCFS, ya que no dependen del quantum o del orden. En particular se puede ver que la latencia del Round Robin es 3 veces menor que el resto, pero el tiempo Ready y Turnaround llega a ser más del doble que el resto de las tareas.

2 Cores

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	9	13	15	12
M. Ready	111	13	15	16
M. Turnaround	122	20	20	24
Idle	7	9	17	3

Al duplicar la cantidad de cores vuelve a verse un aumento sustancial en la latencia y tiempos de ejecución de cada scheduler, excepto en el Round Robin, donde los beneficios son casi despreciables (salvo en la latencia).

Escenario C:

En este escenario, nos plantemos utilizar varias tasks de tamaño mezclado en relación al Quantum. Para generar el lotes del escenario C agarramos tasks de A y B en igual cantidad y promediamos su realease time, finalmente experimentamos con el siguiente lote:

Task	Tipo	Release time	n
0	TaskCPU	0	2
1	TaskCPU	0	4
2	TaskCPU	0	16
3	TaskCPU	0	20
4	TaskCPU	12	2
5	TaskCPU	12	4
6	TaskCPU	12	16
7	TaskCPU	12	20

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	22	32	42	24
M. Ready	46	32	42	44
M. Turnaround	34	10	10	31
Idle	1	1	1	1

Métrica	SchedRR	SchedFCFS	SchedSJF	SchedRSJF
M. Latency	14	11	14	6
M. Ready	30	11	14	15
M. Turnaround	27	10	10	20
Idle	5	9	9	3

Conclusión

De los casos evaluados se puede confirmar que el scheduler Round Robin tiene un tiempo de respuesta(latencia) mucho mejor que el resto de los schedulers, por otro lado es el peor schedulers comparados en cuando a Waiting Time y turnaround a lo largo de todos los escenarios. En particular se ve que sin ningún tipo de "CPU pinning" el rendimiento no mejora linealmente con la cantidad de cores, para mas información respecto a esto se puede ver las pruebas del Ejercicio 4.

En los casos sin I/O, o sea en todos los experimentos realizados, se encontró que el scheduler FCFS tiene el mejor comportamiento en las métricas evaluadas exceptuando a la latencia. Por otro lado notamos en que el escenario A y B, el comportamiento de FCFS, SJF y RJSF tienen métricas muy similares aun teniendo diagramas de Gantt diferentes, nos inclinamos a creer que esto se debe principalmente a que el tamaño y la distribución de las tareas es bastante similar,

Anexo

Los diagramas de Gantt de los lotes utilizados en la experimentación no fueron agregados en el informe ya por ser muchos generaban más ruido que claridad en la explicación, los mismo se encuentran en la subcarpeta de imágenes y son nombrados de la siguiente forma ejercio8<Escenario>_<Scheduler>_<n cores>core.png.