--- title: Trabajo Práctico 1 - Scheduling author: - Agusín Cangiani (344/09) - David Ventura (673/13) - Fabian Álvarez (674/13) geometry: margin=2cm --- \newpage \hypersetup{ colorlinks, linkcolor=black } \tableofcontents \newpage Ejercicio 1 ==== 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 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 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: | Task | Release Time | n | bmin | bmax | |------ |-------------- |--- |------ |------ | | 0 | 3 | 5 | 1 | 3 | | 1 | 5 | 2 | 4 | 8 | | 2 | 5 | 2 | 4 | 8 | ![Ej1](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 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 #### Multi core ### Uso intensivo IO #### Single core #### Multi core ### Picos esporádicos CPU con IO #### Single core #### Multi core ## 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