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

informe/8-bis-informe.md

@@ -0,0 +1,94 @@
+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/9-informe.md

@@ -1,6 +1,13 @@
 \newpage
 # 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
 Para la implementación de este ejercicio utilizando:
 
 `Map<pid, process>`
@@ -22,7 +29,7 @@ Al haber un _unblock_ se intenta 'premiar' a la tarea (que no utilizó completam
 
 
 ## Casos de prueba
-Para probar el funcionamiento del scheduler, se procedió a mandar fruta en las tareas que encontramos más comunes en la vida real.
+Para probar el funcionamiento del scheduler, se procedió a correr 3 lotes de tareas en las que se intenta simular distintos casos de usos para ver como se comporta el mismo.
 
 Las tareas consisten en los siguientes 3 casos:
 
@@ -30,11 +37,6 @@ Las tareas consisten en los siguientes 3 casos:
 * __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.
 
-### 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.
 
 ### Uso elevado de CPU