Actualizado informe

Makefile

@@ -53,9 +53,9 @@ ejercicio3: all makedir
 	./simusched ejer3.tsk 1 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedFCFS | ./graphsched.py > informe/imagenes/ejercicio3_1core.png
 
 ejercicio4: all makedir
-	./simusched ejer2.tsk 1 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 1 $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_1core.png
-	./simusched ejer2.tsk 2 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 2 $(QUANTUM) $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_2core.png
-	./simusched ejer2.tsk 4 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 4 $(QUANTUM) $(QUANTUM) $(QUANTUM) $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_4core.png
+	./simusched ejer3.tsk 1 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 1 $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_1core.png
+	./simusched ejer3.tsk 2 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 2 $(QUANTUM) $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_2core.png
+	./simusched ejer3.tsk 4 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 4 $(QUANTUM) $(QUANTUM) $(QUANTUM) $(QUANTUM) | ./graphsched.py > informe/imagenes/ejercicio4_4core.png
 
 ejercicio5: all makedir
 	./simusched ejer2.tsk 1 $(CONTEXT_SWITCH) $(CORE_SWITCH) SchedRR 1 02 | ./graphsched.py > informe/imagenes/ejercicio5_1core_02q.png

ejer3.tsk

@@ -1 +1,3 @@
+TaskBatch 15 4
+@5:
 *2 TaskBatch 10 2

informe/1-informe.md

@@ -23,23 +23,23 @@ geometry: margin=2cm
 Ejercicio 1
 ====
 
-Para el primer ejercicio de este trabajo práctico se nos pide implementar TaskConsola, una simulación
+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 
+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:
 
-```python
+```c
   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: 
+ de tareas del tipo `TaskConsola`: 
 
 | Task 	| Release Time 	| n 	| bmin 	| bmax 	|
 |------	|--------------	|---	|------	|------	|
@@ -47,81 +47,8 @@ Para probar y generar el gráfico de Gantt de la implementación realizada utili
 | 1    	| 5            	| 2 	| 4    	| 8    	|
 | 2    	| 5            	| 2 	| 4    	| 8    	|
 
-![Ej1](informe/imagenes/ejercicio1.png)
+![Ejercicio 1](informe/imagenes/ejercicio1.png)
 
 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:
-
-![Ej2-1](informe/imagenes/ejercicio2_1core.png)
-
-2. Simulación con 2 core:
-
-![Ej2-2](informe/imagenes/ejercicio2_2core.png)
-
-3. Simulación con 4  core:
-
-![Ej2-4](informe/imagenes/ejercicio2_4core.png)
-
-
-Finalmente se nos pide calcular *latencia*[^footnote] y *throughtput*[^footnote2] 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.
-[^footnote2]: Throughtput, Insert definition
-
-
-\newpage
-Ejercicio 3
-====
-![Ej3](informe/imagenes/ejercicio3_1core.png)
-
-
-\newpage

informe/4-informe.md

@@ -1,28 +1,46 @@
+\newpage
+<<<<<<< fc59b18653865f4d3df0f845b7586270447a54ff:informe/1-informe.md
+=======
 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:
+El ejercicio 4 se implementó utilizando un `Map` de __C++__, esto permite poder acceder rápidamente a las tareas y debido a que mantiene el *orden*[^footnote3], se puede utilizar como reemplazo a una cola.
+En dicho `Map` se almacena un `struct` con datos del proceso actual como: _pid_, _state_ y *quantum_count*, a los que se accede utilizando el _pid_ como clave.
 
-* __Quantum:__ ?????
-* __Context Switch:__ ???
-* __Core Switch:__ ???
+En el constructor se leen los parámetros que recibe la cola y se inicializa un `array` con los quantums correspondiente a cada core (de _0_ a _N_).
 
-# 1 Core
-![Ej4-1](informe/imagenes/ejercicio4_1core.png)
-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.
+Cada vez que se carga un nuevo proceso, el mismo se almacena en en `Map`. Al haber un _tick_ se controla que no se haya cumplido el _quantum_ establecido para dicho nucleo, si se cumplió o si la tarea realiza una llamada bloqueante se libera y se carga la siguiente tarea.
 
-## 2 Cores
-![Ej4-2](informe/imagenes/ejercicio4_2core.png)
 
-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)
+Para probar el funcionamiento del scheduler se ejecutaron el lote de `TaskBatch` utilizados en el ejercicio 3 con 1, 2 y 4 cores para evaluar como escala el mismo en dichos casos. Para todos los casos se graficó el diagrama de gantt.
+En las pruebas realizadas se utilizaron los siguientes valores:
 
+* __Quantum:__ 10
+* __Context Switch:__ 2
+* __Core Switch:__ 5
 
-## 4 Cores
-![Ej4-4](informe/imagenes/ejercicio4_4core.png)
-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.
+### 1 Core
+![Ejercicio 4 - 1 Core](informe/imagenes/ejercicio4_1core.png)
+En este caso se observa que quantums mas grándes ayudan a mejorar los tiempos totales de ejecución, pero aumentan la latencia y waiting time por proceso debido a los cambios de contexto.
 
+### 2 Cores
+![Ejercicio 4 - 2 Cores](informe/imagenes/ejercicio4_2core.png)
+El tener más de un core, en principio, disminuye en gran parte la latencia del proceso, pero la "ingenuidad" de la implementacion termina *dañando* el rendimiento general. Ya que el scheduler no considera el costo de cambio de CPU, utilizando el primero que se encuentra libre.
 
-\newpage
+### 4 Cores
+![Ejercicio 4 - 4 Cores](informe/imagenes/ejercicio4_4core.png)
+Por la misma razón que en el ejemplo de 2 cores, se ve que aumentar la cantidad de cores no mejora los tiempos de ejecución  de los procesos. Es más, debido a que se busca el primer core disponible, hay un core que prácticamente no se utiliza, estando idle.
+
+A continuación se muestra una tabla con los valores promedio calculados para cada prueba:
+
+| Ejecucion   | Latencia | Waiting Time | Turnaround | Throughtput |
+|-------------|----------|--------------|------------|-------------|
+| 1 Core      | 10       | 36           | 44.67      | 0.05        | 
+| 2 Cores     | 3.3      | 27.67        | 38         | 0.06        |
+| 4 Cores     | 2        | 17           | 27.3       | 0.07        |
+
+Como se mencionaba en los ejemplos anteriores, se puede ver que el aumento de cores mejora el rendimiento general del scheduler, pero no de manera lineal. Posiblemente pueda mejorarse mucho más el rendimiento evitando hacer tantos core switch e intentando ocupar todos los cores libres.
+
+
+[^footnote3]: *Container Properties:* http://www.cplusplus.com/reference/map/map/