so-tp1/informe/informe.md

---

title: Trabajo Práctico 1 - Scheduling author:

• Agusín Cangiani (344/09)
• David Ventura (673/13)
• Fabian Álvarez (674/13) geometry: margin=2cm ---

\newpage

\hypersetup{ colorlinks, linkcolor=black } \tableofcontents

\newpage

Ejercicio 1

Para el primer ejercicio de este trabajo práctico se nos pide implementar TaskConsola, una simulación de una tarea interativa que debe realizar llamadas bloquantes de duración aleatoria y luego de esto consumir un ciclo de cpu. Dicha tarea se contruye a partir de 3 parámetros n, bmin y bmax , donde el primero determina la cantidad de llamadas de bloqueantes a realizar y luego bmin y bmax determinan el rango de la duración de cada la llamada bloqueante.

La implementación de TaskConsola es bastante sencilla, se generan n iteraciones, donde en cada una de ellas se genera una llamada bloqueante con una duración de x ciclos de reloj y un ciclo de ejecución de cpu. Para determinar x utilizamos la siguiente fórmula:

  x = rand() % ( bmax - bmin + 1 ) + bmin

Para probar y generar el gráfico de Gantt de la implementación realizada utilizamos el siguiente lote de tareas del tipo TaskConsola:

Task	Release Time	n	bmin	bmax
0	3	5	1	3
1	5	2	4	8
2	5	2	4	8

El el gráfico se puede observar que las llamadas bloqueantes se mantienen dentro de los rangos establecidos por los parámtetros de las tareas.

\newpage

Ejercicio 2

En este ejercicio se nos pide experimentar con un scheduler del tipo FCFS(first come, first served), esto significa que atendera a las tareas en el orden de llegada y no liberará el procesador hasta concluir con el proceso asignado.

Para probar dicha implementación se unos brinda un lote de tareas compuesto por tareas del tipo TaskConsola y TaskCPU, donde el primer tipo ya fue expuesto en el primer ejercicio de este trabajo y la segundo es una tarea que solo consumirá consumirá una cantidad finita de ciclos de cpu(determinadas por parámetro). El siguiente cuadro muestra el lote utilizado:

Task	Tipo	Release time	n	bmin	bmax
0	TaskCPU	0	10
1	TaskConsola	5	5	1	4
2	TaskConsola	6	5	1	2
3	TaskCPU	8	10

Para probar este lote, se nos pide hacer correr el scheduler con un costo de cambio de contexto de 2 ciclos en máquinas de 1, 2 y 4 cores, además es válido aclarar que el costo de core switch es irrelevante para esta implementación.

1. Simulación con 1 core:

1. Simulación con 2 core:

1. Simulación con 4 core:

Finalmente se nos pide calcular latencia[^footnote] y throughtput[^footnote] en cada una de las pruebas, a lo cual elaboramos los siguientes cuantos:

A. Latencia:

Task	Tipo	1 Core	2 Cores	4 Cores
0	TaskCPU	2	2	2
1	TaskConsola	14	7	7
2	TaskConsola	36	14	8
3	TaskCPU	58	34	10
	Promedio	27.5	14.25	6.75

B. Throughtput:

Task	Tipo	1 Core	2 Core	4 Cores
0	TaskCPU	0	0	0
1	TaskConsola	0	0	0
2	TaskConsola	0	0	0
3	TaskCPU	0	0	0
	Promedio	0	0	0

AGREGAR UN CONCLUSIONE SOBRE LATENCIA Y THROUGTHPUT

[^footnote]: Latencia, Cantidad de ticks en ready hasta que se ejecuta la task. [^footnote]: Throughtput, Insert definition

\newpage

Ejercicio 3

\newpage

Ejercicio 4

Para el ejercicio 4 se ejecutaron 3 casos distintos con 1, 2 y 4 cores para evaluar como se modifica la eficiencia del mismo en dichos casos. Se utilizaron los siguientes valores:

• Quantum: ?????
• Context Switch: ???
• Core Switch: ???

1 Core

Se puede observar que el tener quantums muy chicos afecta negativamente el rendimiento del scheduler, ya que se pierde la mayoría del tiempo en context switch.

2 Cores

En este grafico se puede ver facilmente que la ingenuidad de la implementacion termina dañando el rendimiento general (Particularmente core-switch en ciclos 22 y 50)

4 Cores

Se ve que aumentar la cantidad de cores no mejora los tiempos de ejecución de los procesos, ya que en casi todo momento se encuentra un core en idle. Esto se debe a que este scheduler toma el primer nucleo libre y tiene en cuenta en que nucleo se encuentra el proceso actual. Esto provoca que haya cambio de nucleos constantemente en los procesos, sin aprovechar los cores libres.

\newpage

Ejercicio 5

Quantum 2

Quantum 5

Quantum 10

\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.

Uso intensivo CPU

Single core

Multi core

Uso intensivo IO

Single core

Multi core

Picos esporádicos CPU con IO

Single core

Multi core

Cuadro mágico

Voy a ver como armar gráficos en python, pero en caso se emergencia "sudo apt install libreoffice-calc"

\newpage

Ejercicio 9

\newpage

Definiciones

Latencia: Cantidad de ticks en ready hasta que se ejecuta la primera task. Esta métrica se puede extender para ver la latencia promedio de todos los procesos que corrió el scheduler.

Waiting time: Cantidad de ticks en ready durante toda la ejecución de un proceso.

Tiempo total de ejecución: Intervalo de ticks desde que se ejecuta un proceso hasta su terminación. --> buscar en las teóricas, la latencia del proceso puede o no ser incluida