Sfoglia il codice sorgente

Añadidos ejercicios 2 y 3

Fabian 10 anni fa
parent
commit
3390e9cec7
2 ha cambiato i file con 83 aggiunte e 0 eliminazioni
  1. 61 0
      informe/2-informe.md
  2. 22 0
      informe/3-informe.md

+ 61 - 0
informe/2-informe.md

@@ -0,0 +1,61 @@
+\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:
+
+![Ejercicio 2 - 1 Core](informe/imagenes/ejercicio2_1core.png)
+
+2. Simulación con 2 cores:
+
+![Ejercicio 2 - 2 Cores](informe/imagenes/ejercicio2_2core.png)
+
+\newpage
+3. Simulación con 4 cores:
+
+![Ejercicio 2 - 4 Cores](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 cuadros:
+
+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:
+
+| 1 Core | 2 Core  | 4 Cores |
+|--------|---------|---------|
+| 0.06   | 0.08    | 0.13    |
+
+
+[^footnote]: Latencia, Cantidad de ticks en ready hasta que se ejecuta la task.
+[^footnote2]: Throughtput, Cantidad de procesos que terminan su ejecución por unidad de tiempo.
+

+ 22 - 0
informe/3-informe.md

@@ -0,0 +1,22 @@
+\newpage
+Ejercicio 3
+====
+
+Para este ejercicio se pide implementar la tarea `TaskBatch`, la cual simula una tarea que corre sin interacción humana, con una cantidad elevada de tiempo de CPU y con una serie de llamadas bloqueantes definidas.
+Estos tipos de procesamiento se conocen como _por lotes_ o _batch_, y suelen ser utilizados comunmente en ambientes corporativos donde suelen procesarse gran cantidad de datos.
+
+La implementación de `TaskBatch` consiste en crear un vector que posee las los tipos de usos que se van a realizar. Al vector se le inserta un `0` si es una operación de CPU o un `1` si es una operación de IO.
+Luego se utiliza la operación `random_shuffle` para distribuir las llamadas. Se recorre el vector y se realiza la operación que se encuentre almacenada en el mismo.
+
+
+Para probar y generar el gráfico de Gantt de la implementación realizada utilizamos el siguiente lote
+   de tareas del tipo `TaskBatch`:
+
+   | Task  | Release Time  | Total CPU     | Cant. Bloqueos
+   |------ |-------------- |-------------- |---------------- 
+   | 0     | 0             | 15            | 4     
+   | 1     | 5             | 10            | 2     
+   | 2     | 5             | 10            | 2     
+
+![Ejercicio 3](informe/imagenes/ejercicio3_1core.png)
+