informe 8

informe/8-informe.md

@@ -1,4 +1,6 @@
-# Ejercicio 8
+\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:
@@ -7,7 +9,7 @@ Se eligieron los siguientes casos de prueba ya que creemos que son los casos que
 * __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
@@ -15,26 +17,21 @@ Se eligieron los siguientes casos de prueba ya que creemos que son los casos que
 #### Single core
 ![](informe/imagenes/caso_cpu_1_1.png)
 
-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 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).
+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).
 
 
 ![](informe/imagenes/caso_cpu_1_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 todos los schedulers se comportan de manera similar.
-
+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__.
 
-\newpage 
 
 #### Multi core
 
-
 ![](informe/imagenes/caso_cpu_4_1.png)
 
-\newpage
-
 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: Reduce ligeramente la latencia comparado a SJF, pero el turnaroud es un *50% mayor*.
@@ -46,8 +43,7 @@ RR: tiene una latencia *mucho* menor (~la mitad), pero por la naturaleza de este
 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.
-
-RSJF: ????????? 
+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
@@ -63,10 +59,12 @@ Idem a todo lo anterior, FCFS parece comportarse mejor que el resto
 #### Multi core
 ![](informe/imagenes/caso_ioh_4_1.png)
 
-RR es DESTRUIDO por este caso.
+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_.
 
 ![](informe/imagenes/caso_ioh_4_2.png)
-RR es COMPLETAMENTE DESTRUIDO por este caso.
+
+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