so-tp1/informe/4-informe.md

\newpage

Ejercicio 4

El ejercicio 4 se implementó utilizando un Map de C++, esto permite poder acceder rápidamente a las tareas y debido a que mantiene el orden[^ej4footnote], se puede utilizar como reemplazo a una cola. En dicho Map se almacena un struct con datos del proceso actual como: pid, state y quantum_count, a los que se accede utilizando el pid como clave.

En el constructor se leen los parámetros que recibe la cola y se inicializa un array con los quantums correspondiente a cada core (de 0 a N).

Cada vez que se carga un nuevo proceso, el mismo se almacena en en Map. Al haber un tick se controla que no se haya cumplido el quantum establecido para dicho nucleo, si se cumplió o si la tarea realiza una llamada bloqueante se libera y se carga la siguiente tarea.

Para probar el funcionamiento del scheduler se ejecutaron el lote de TaskBatch utilizados en el ejercicio 3 con 1, 2 y 4 cores para evaluar como escala el mismo en dichos casos. Para todos los casos se graficó el diagrama de gantt. En las pruebas realizadas se utilizaron los siguientes valores:

• Quantum: 10
• Context Switch: 2
• Core Switch: 5

1 Core

En este caso se observa que quantums mas grándes ayudan a mejorar los tiempos totales de ejecución, pero aumentan la latencia y waiting time por proceso debido a los cambios de contexto.

2 Cores

El tener más de un core, en principio, disminuye en gran parte la latencia del proceso, pero la "ingenuidad" de la implementacion termina dañando el rendimiento general. Ya que el scheduler no considera el costo de cambio de CPU, utilizando el primero que se encuentra libre.

4 Cores

Por la misma razón que en el ejemplo de 2 cores, se ve que aumentar la cantidad de cores no mejora los tiempos de ejecución de los procesos. Es más, debido a que se busca el primer core disponible, hay un core que prácticamente no se utiliza, estando idle.

A continuación se muestra una tabla con los valores promedio calculados para cada prueba:

Ejecucion	Latencia	Waiting Time	Turnaround	Throughtput
1 Core	11.25	42	57.5	0.057
2 Cores	3	25	40.5	0.065
4 Cores	2	11.75	30.25	0.081

Como se mencionaba en los ejemplos anteriores, se puede ver que el aumento de cores mejora el rendimiento general del scheduler, pero no de manera lineal. Posiblemente pueda mejorarse mucho más el rendimiento evitando hacer tantos core switch e intentando ocupar todos los cores libres.

[^ej4footnote]: Container Properties: http://www.cplusplus.com/reference/map/map/