Ej8 más avanzado

informe/8-bis-informe.md

@@ -1,94 +0,0 @@
-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ásica(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 escenarios 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
-
--Mini intro: quamtum context switch
-- Creo que lo mejor es usar Quantum = 2, Context switch = 2, cores 1,2,4
-
-#### Escenario 2 y 3:
-- proponemos los siguentes lotes para los escenarios
-
-#### Escenario A:
-- proponemos los siguentes lotes para los escenarios
-
-| Task | Tipo        | Release time | n  |
-|------|-------------|--------------|----|
-| 0    | TaskCPU     | 0            | 4  |
-| 1    | TaskCPU     | 0            | 4  |
-| 2    | TaskCPU     | 4            | 4  |
-| 3    | TaskCPU     | 4            | 4  |
-| 4    | TaskCPU     | 8            | 4  |
-| 5    | TaskCPU     | 8            | 4  |
-
-#### Escenario B:
-
-| Task | Tipo        | Release time | n  |
-|------|-------------|--------------|----|
-| 0    | TaskCPU     | 0            | 10 |
-| 1    | TaskCPU     | 0            | 10 |
-| 2    | TaskCPU     | 4            | 10 |
-| 3    | TaskCPU     | 4            | 10 |
-| 4    | TaskCPU     | 8            | 10 |
-| 5    | TaskCPU     | 8            | 10 |
-
-#### Escenario B:
-
-| Task | Tipo        | Release time | n  |
-|------|-------------|--------------|----|
-| 0    | TaskCPU     | 0            | 4  |
-| 1    | TaskCPU     | 0            | 10 |
-| 2    | TaskCPU     | 4            | 4  |
-| 3    | TaskCPU     | 4            | 10 |
-| 4    | TaskCPU     | 8            | 4  |
-| 5    | TaskCPU     | 8            | 10 |
-
-
-
-
-
-latencia watigin time turnaroun de cada escenario
-
-
-### Conclusión
-
-
-
-
-
-
-
-[^tag]
-[^tag]:
-\newpage
-
-#### Anexos(Gantts)
-\newpage

informe/8-informe.md

@@ -1,104 +1,104 @@
-\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:
+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:
 
-* __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.
+- 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.
 
-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.
+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:
 
-### Uso intensivo CPU
+- 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.
 
-#### Single core
-![](informe/imagenes/caso_cpu_1_1.png)
+### Experimentación
 
-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).
+En esta sección analizaremos los diferentes escenarios planteados que nos interesan
+(*A*, *B*, *C*), para todos ellos utilizaremos **Quantums** y **Context Switch** 
+de costo 2 y 4 respectivamente, además de probar con 1 y 2 cores.
 
+#### Escenario A:
 
-\newpage 
+En este escenario, nos plantemos utilizar varias tasks de tamaño chico en relación al 
+**Quantum**, para lo cual utilizamos el siguiente lote:
 
-![](informe/imagenes/caso_cpu_1_2.png)
+| Task | Tipo        | Release time | n  |
+|------|-------------|--------------|----|
+| 0    | TaskCPU     | 0            | 4  |
+| 1    | TaskCPU     | 0            | 4  |
+| 2    | TaskCPU     | 4            | 4  |
+| 3    | TaskCPU     | 4            | 4  |
+| 4    | TaskCPU     | 8            | 4  |
+| 5    | TaskCPU     | 8            | 4  |
 
-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__.
+**latencia**
+**waiting time**
+**turnaround**
 
+#### Escenario B:
 
-#### Multi core
+En este escenario, nos plantemos utilizar varias tasks de tamaño grande en relación al 
+**Quantum**, para lo cual utilizamos el siguiente lote:
 
-![](informe/imagenes/caso_cpu_4_1.png)
+| Task | Tipo        | Release time | n  |
+|------|-------------|--------------|----|
+| 0    | TaskCPU     | 0            | 10 |
+| 1    | TaskCPU     | 0            | 10 |
+| 2    | TaskCPU     | 4            | 10 |
+| 3    | TaskCPU     | 4            | 10 |
+| 4    | TaskCPU     | 8            | 10 |
+| 5    | TaskCPU     | 8            | 10 |
 
-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.
+**latencia**
+**waiting time**
+**turnaround**
 
-RSJF: Incrementa ligeramente la latencia y el turnaround comparado a SJF.
+#### Escenario C:
 
-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.
+En este escenario, nos plantemos utilizar varias tasks de tamaño mezclado en relación al 
+**Quantum**, para lo cual utilizamos el siguiente lote:
 
+| Task | Tipo        | Release time | n  |
+|------|-------------|--------------|----|
+| 0    | TaskCPU     | 0            | 4  |
+| 1    | TaskCPU     | 0            | 10 |
+| 2    | TaskCPU     | 4            | 4  |
+| 3    | TaskCPU     | 4            | 10 |
+| 4    | TaskCPU     | 8            | 4  |
+| 5    | TaskCPU     | 8            | 10 |
 
-![](informe/imagenes/caso_cpu_4_2.png)
-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__.
 
+**latencia**
+**waiting time**
+**turnaround**
 
-### Uso intensivo IO
 
-#### Single core
-![](informe/imagenes/caso_ioh_1_1.png)
-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).
+### Conclusión
 
+**Conclusión**
 
-![](informe/imagenes/caso_ioh_1_2.png)
-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).
+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*.
 
-\newpage 
-
-#### Multi core
-![](informe/imagenes/caso_ioh_4_1.png)
-
-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_.
-
-\newpage 
-
-![](informe/imagenes/caso_ioh_4_2.png)
-
-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_.
-
-
-### Picos esporádicos CPU con IO
-
-
-\newpage 
-#### Single core
-![](informe/imagenes/caso_cpuh_1_1.png)
-
-Al igual que los otros casos en 1 core, FCFS, RSJF y SJF se comportan de manera similar.
-
-RR: La latencia se reduce como es esperado, pero incrementan READY y turnaround.
-
-![](informe/imagenes/caso_cpuh_1_2.png)
-Al igual que los otros casos en 1 core, FCFS, RSJF y SJF se comportan de manera similar.
-
-RR:  La cantidad de tareas(15), llamadas a IO y costo alto de context switch hace que este sea un caso muy malo para RR.
-
-#### Multi core
-
-![](informe/imagenes/caso_cpuh_4_1.png)
-
-Los scheduler FCFS, RSJF y SJF se comportan de manera similar (Con un quantum grande se comportan como el FCFS).
-
-RR:  La cantidad de tareas, llamadas a IO y costo alto de context switch hace que este sea un caso muy malo para RR.
-
-\newpage 
-
-![](informe/imagenes/caso_cpuh_4_2.png)
-Los scheduler FCFS, RSJF y SJF se comportan de manera similar (Con un quantum grande se comportan como el FCFS).
-
-RR:  La cantidad de tareas, llamadas a IO y costo alto de context switch hace que este sea un caso muy malo para RR.
+[^tag]
+[^tag]:
+\newpage