Merge branch 'master' of ssh://gogs.davidventura.com.ar:443/david/so-tp1

graphsched.py

@@ -6,8 +6,10 @@ import re, sys, os
 from PIL import Image, ImageDraw, ImageFont
 
 # Font search paths and acceptable names. Order matters.
-FONT_DIRS = "/usr/share/fonts/truetype/freefont","/usr/share/fonts/truetype", "/usr/lib/fonts/", "/Library/Fonts"
-FONT_NAMES = "FreeMono.ttf", "Andale Mono.ttf", "Arial Black.ttf", "Hei.ttf.ttf", "Courier New.ttf", "DejaVuSans.ttf"
+
+FONT_DIRS = "/usr/share/fonts/truetype/dejavu","/usr/share/fonts/truetype", "/usr/lib/fonts/", "/Library/Fonts"
+
+FONT_NAMES = "DejaVuSansMono.ttf" "FreeMono.ttf", "Andale Mono.ttf", "Arial Black.ttf", "Hei.ttf.ttf", "Courier New.ttf", "DejaVuSans.ttf"
 
 def findfont(names=FONT_NAMES, dirs=FONT_DIRS):
 	"""Return first existing path or None."""

informe/7-informe.md

@@ -56,3 +56,4 @@ B. Scheduler RSJF(reentrante) con 1 y 2 cores, lote y resultados:
 A la vista de estos resultados, todo parece indicar que el comportamiento 
 de las dos implementaciones es acorde a lo esperado y en el siguiente ejercicio
 se hara un análisis comparativo de los mismo.
+\newpage

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

informe/9-informe.md

@@ -1,13 +1,15 @@
 \newpage
-# Ejercicio 9
 
-### Descripción del algoritmo 
+Ejercicio 9
+====
+
+## Descripción del algoritmo 
 
 Este scheduler intenta alcanzar un balance entre throughput (para tareas con uso alto de recursos) y bajo waiting time (para tareas con poco uso de recursos y mucho IO).
 Las tareas priorizadas usan el CPU poco tiempo, por lo que es bueno reducir el waiting time para dar respuesta rápida.
 Las otras tareas requieren más recursos, por lo que no les afecta un waiting time mayor si eso significa obtener mas quantum.
 
-### Implementacion
+## Implementacion
 Para la implementación de este ejercicio utilizando:
 
 `Map<pid, process>`
@@ -33,18 +35,35 @@ Para probar el funcionamiento del scheduler, se procedió a correr 3 lotes de ta
 
 Las tareas consisten en los siguientes 3 casos:
 
-* __CPU Heavy:__ Alto uso de CPU casi sin uso de IO, se simulan tareas con mucho consumo de CPU (que superen el quantum estimado) con pequeñas operaciones de IO.
-* __IO Heavy:__ Tareas con poco consumo de CPU (comparadas a _CPU Heavy_) pero con un alto uso de IO.
-* __Interacción de usuario:__ Consiste en varios procesos con uso de IO seguidos de procesos con alto uso de CPU. Para simular la entrada de un usuario y el procesamiento de programas o scripts del mismo.
+* __Uso elevado de CPU__ Alto uso de CPU casi sin uso de IO, se simulan tareas con mucho consumo de CPU (que superen el quantum estimado) con pequeñas operaciones de IO.
+* __Uso elevado de I/O:__ Tareas con poco consumo de CPU (comparadas al uso elevado de CPU) pero con un alto uso de I/O.
+* __Interacción de usuario:__ Consiste en varios procesos con uso de I/O seguidos de procesos con alto uso de CPU. Para simular la entrada de un usuario y el procesamiento de programas o scripts del mismo.
 
 
 ### Uso elevado de CPU
+Se utilizó el siguiente lote de tareas para simular uso intensivo de CPU.
+
+| Release time | Cantidad | Tipo        | Ticks | Cant. Bloq. | Tiempo Bloq. |
+|--------------|----------|-------------|-------|-------------|--------------|
+| 0            | 3        | TaskCPU     | 50    | -           | -            |
+| 10           | 3        | TaskConsola | 3     | 3           | 8 - 10       |
+| 15           | 5        | TaskCPU     | 4     | -           | -            |
+| 20           | 1        | TaskCPU     | 10    | -           | -            |
 
 ![Ejercicio 9 - CPU Heavy](informe/imagenes/ejercicio9_gantt_casos_1.png)
 En este caso se puede ver claramente la priorización de tareas con IO (3,4,5) sobre las tareas que consumen todo su quantum y son asignadas a una cola de menor prioridad.
 
+### Uso elevado de I/O
+Para este caso se crearon tareas consitentes casi en su totalidad de llamadas bloqueanes con algún uso esporádico de CPU.
+
+| Release time | Cantidad | Tipo        | Ticks | Cant. Bloq. | Tiempo Bloq. |
+|--------------|----------|-------------|-------|-------------|--------------|
+| 0            | 1        | TaskCPU     | 50    | -           | -            |
+| 0            | 5        | TaskBatch   | 10    | 8           | 2            |
+| 5            | 2        | TaskConsola | 4     | 4           | 5 - 10       |
+| 10           | 2        | TaskCPU     | 10    | -           | -            |
+| 10           | 3        | TaskBatch   | 9     | 4           | 2            |
 
-### Uso elevado de IO
 ![Ejercicio 9 - IO Heavy](informe/imagenes/ejercicio9_gantt_casos_2.png)
 En este caso se puede ver que la priorización de procesos "interactivos" consume completamente el CPU (hasta ~160), donde finalmente pueden ejecutar los procesos que estaban en la segunda cola.
 
@@ -52,10 +71,25 @@ En este caso se puede ver que la priorización de procesos "interactivos" consum
 \newpage
 
 ### Interacción de usuario
+Para este caso se creo una mezcla de tareas bloqueantes de consola, seguidas por tareas de CPU que corren "en background".
+
+| Release time | Cantidad | Tipo        | Ticks | Cant. Bloq. | Tiempo Bloq. |
+|--------------|----------|-------------|-------|-------------|--------------|
+| 0            | 1        | TaskCPU     | 50    | -           | -            |
+| 0            | 3        | TaskBatch   | 6     | 3           | 2            |
+| 5            | 2        | TaskConsola | 5     | 5           | 10 - 15      |
+| 15           | 1        | TaskCPU     | 25    | -           | -            |
+| 30           | 2        | TaskConsola | 4     | 4           | 7 - 10       |
+| 30           | 1        | TaskCPU     | 40    | -           | -            |
+| 40           | 1        | TaskConsola | 4     | 4           | 6 - 10       |
+
 ![Ejercicio 9 - Interacción usuario](informe/imagenes/ejercicio9_gantt_casos_3.png)
 
 En este caso podemos ver un buen lote de tareas para el scheduler; las tareas "interactivas" tienen bajo waiting time mientras que las tareas con uso intensivo de CPU tienen mayor waiting time pero también reciben mas quantum.
 
+### Conclusiones
+A continuación se preparó una tabla comparativa con la latencia, waiting time y turnaround promedio para cada lote de pruebas ejecutado anteriormente.
+
 |              | CPU  | IO  | USER |
 |--------------|------|-----|------|
 |M. Latency    | 4.92 | 9.3 | 4.0  |
@@ -66,7 +100,8 @@ En este caso podemos ver un buen lote de tareas para el scheduler; las tareas "i
 En esta tabla se ve que para un lote de tareas "interactivo" los resultados mejoran, como es de esperarse, por el comportamiento del scheduler.
 Para los otros lotes de tareas:
 * CPU: Si las tareas del lote usan principalmente CPU eventualmente todos los procesos terminan en la cola de menor prioridad y con mas quantum, esencialmente se vuelve un round robin.
-* IO: Si las tareas del lote usan principalmente IO, toda estas tareas quedan en la lista de prioridad más alta, donde se pierde gran parte del tiempo haciendo context/cpu switch.
+* IO: Si las tareas del lote usan principalmente IO, toda estas tareas quedan en la lista de prioridad más alta, donde se pierde gran parte del tiempo haciendo context/cpu switch, nuevamente actuando como un Round Robin sin mucha prioridad en particular.
+
 
 # Definiciones