parto el informe en cachos

Makefile

@@ -32,8 +32,8 @@ clean:
 preinforme: ejercicio1 ejercicio2 ejercicio3 ejercicio4 ejercicio5
 
 informe: informe/informe.pdf
-informe/informe.pdf: informe/informe.md preinforme
-	pandoc informe/informe.md -o informe/informe.pdf
+informe/informe.pdf: informe/1-informe.md informe/4-informe.md informe/5-informe.md informe/6-informe.md informe/7-informe.md informe/8-informe.md informe/9-informe.md preinforme
+	pandoc informe/*informe.md -o informe/informe.pdf
 
 
 new: clean all

informe/informe.md

@@ -125,117 +125,3 @@ Ejercicio 3
 
 
 \newpage
-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:
-
-* __Quantum:__ ?????
-* __Context Switch:__ ???
-* __Core Switch:__ ???
-
-# 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.
-
-## 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)
-
-
-## 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.
-
-
-\newpage
-Ejercicio 5
-====
-
-## Quantum 2
-![Ej5-1](informe/imagenes/ejercicio5_1core_02q.png)
-
-## Quantum 5
-![Ej5-2](informe/imagenes/ejercicio5_1core_05q.png)
-
-## Quantum 10
-![Ej5-3](informe/imagenes/ejercicio5_1core_10q.png)
-
-
-
-
-
-
-
-
- 
-
-
-
-\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:
-
-* __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.
-
-
-
-
-### Uso intensivo CPU
-
-#### Single core
-![](informe/imagenes/caso_cpu_1_1.png)
-![](informe/imagenes/caso_cpu_1_2.png)
-
-#### Multi core
-![](informe/imagenes/caso_cpu_4_1.png)
-![](informe/imagenes/caso_cpu_4_2.png)
-![](informe/imagenes/caso_cpu_4.png)
-
-### Uso intensivo IO
-
-#### Single core
-![](informe/imagenes/caso_cpuh_1_1.png)
-![](informe/imagenes/caso_cpuh_1_2.png)
-
-#### Multi core
-![](informe/imagenes/caso_cpuh_4_1.png)
-![](informe/imagenes/caso_cpuh_4_2.png)
-
-### Picos esporádicos CPU con IO
-
-#### Single core
-![](informe/imagenes/caso_ioh_1_1.png)
-![](informe/imagenes/caso_ioh_1_2.png)
-
-#### Multi core
-![](informe/imagenes/caso_ioh_4_1.png)
-![](informe/imagenes/caso_ioh_4_2.png)
-
-
-## Cuadro mágico
-Voy a ver como armar gráficos en python, pero en caso se emergencia "sudo apt install libreoffice-calc"
-
-\newpage
-# Ejercicio 9
-
-\newpage
-Definiciones
-====
-
-Latencia: Cantidad de ticks en ready hasta que se ejecuta la primera task. Esta métrica se puede extender
-para ver la latencia promedio de todos los procesos que corrió el scheduler.
-
-Waiting time: Cantidad de ticks en ready durante toda la ejecución de un proceso.
-
-Tiempo total de ejecución: Intervalo de ticks desde que se ejecuta un proceso hasta su terminación.
---> buscar en las teóricas, la latencia del proceso puede o no ser incluida
-
-![](informe/imagenes/caso_mfq_4_gral.png)

informe/4-informe.md

@@ -0,0 +1,28 @@
+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:
+
+* __Quantum:__ ?????
+* __Context Switch:__ ???
+* __Core Switch:__ ???
+
+# 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.
+
+## 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)
+
+
+## 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.
+
+
+\newpage
+

informe/5-informe.md

@@ -0,0 +1,15 @@
+Ejercicio 5
+====
+
+## Quantum 2
+![Ej5-1](informe/imagenes/ejercicio5_1core_02q.png)
+
+## Quantum 5
+![Ej5-2](informe/imagenes/ejercicio5_1core_05q.png)
+
+## Quantum 10
+![Ej5-3](informe/imagenes/ejercicio5_1core_10q.png)
+
+
+\newpage
+

informe/8-informe.md

@@ -0,0 +1,49 @@
+# 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:
+
+* __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.
+
+
+
+
+### Uso intensivo CPU
+
+#### Single core
+![](informe/imagenes/caso_cpu_1_1.png)
+![](informe/imagenes/caso_cpu_1_2.png)
+
+#### Multi core
+![](informe/imagenes/caso_cpu_4_1.png)
+![](informe/imagenes/caso_cpu_4_2.png)
+![](informe/imagenes/caso_cpu_4.png)
+
+### Uso intensivo IO
+
+#### Single core
+![](informe/imagenes/caso_cpuh_1_1.png)
+![](informe/imagenes/caso_cpuh_1_2.png)
+
+#### Multi core
+![](informe/imagenes/caso_cpuh_4_1.png)
+![](informe/imagenes/caso_cpuh_4_2.png)
+
+### Picos esporádicos CPU con IO
+
+#### Single core
+![](informe/imagenes/caso_ioh_1_1.png)
+![](informe/imagenes/caso_ioh_1_2.png)
+
+#### Multi core
+![](informe/imagenes/caso_ioh_4_1.png)
+![](informe/imagenes/caso_ioh_4_2.png)
+
+
+## Cuadro mágico
+Voy a ver como armar gráficos en python, pero en caso se emergencia "sudo apt install libreoffice-calc"
+
+\newpage
+

informe/9-informe.md

@@ -0,0 +1,16 @@
+# Ejercicio 9
+
+\newpage
+Definiciones
+====
+
+Latencia: Cantidad de ticks en ready hasta que se ejecuta la primera task. Esta métrica se puede extender
+para ver la latencia promedio de todos los procesos que corrió el scheduler.
+
+Waiting time: Cantidad de ticks en ready durante toda la ejecución de un proceso.
+
+Tiempo total de ejecución: Intervalo de ticks desde que se ejecuta un proceso hasta su terminación.
+--> buscar en las teóricas, la latencia del proceso puede o no ser incluida
+
+![](informe/imagenes/caso_mfq_4_gral.png)
+