Universidad Politécnica de Madrid Escuela Universitaria de Informática Departamento de Informática Aplicada

Transcripción

1 Universidad Politécnica de Madrid Escuela Universitaria de Informática Departamento de Informática Aplicada SISTEMAS OPERATIVOS I (Ingeniero Técnico en Informática de Sistemas) Práctica nº 2 Curso académico

2 Este documento ha sido elaborado por Jorge Enrique Pérez Martínez, Isabel Muñoz Fernández y Javier García Martín todos ellos integrantes del Grupo de Innovación Educativa DMAE-DIA de la Universidad Politécnica de Madrid.

3 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico ÍNDICE 1. SIMULADOR PARA LA PLANIFICACIÓN DE PROCESOS MOTIVACIÓN OBJETIVOS DESCARGA DEL SOFTWARE REQUISITOS DEL SISTEMA PROCEDIMIENTO PARA REALIZAR UNA SIMULACIÓN Fichero de configuración El experimento y la prueba experimental La prueba experimental El experimento Registrar los resultados TIEMPO NÚMEROS ALEATORIOS PROCESOS DISTRIBUCIONES DE PROBABILIDAD Distribución constante Distribución exponencial Distribución uniforme ALGORITMOS DE PLANIFICACIÓN Características adicionales PLANIFICACIÓN POR PRIORIDADES EL SIMULADOR Arrancar el simulador La interfaz del simulador Información sobre procesos y eventos Controles sobre el experimento y el algoritmo de planificación Controles para la ejecución de experimentos Controles para el fichero log Controles para la creación de gráficos Control de bajo nivel del simulador Barras de progreso de la ejecución del simulador Ayuda, Reset y Quit ENUNCIADO DE LA PRÁCTICA CONFIGURACIÓN DEL SIMULADOR CREACIÓN DE EXPERIMENTOS EJERCICIO PRÁCTICO Parte Parte Parte a b c d ENTREGA DE LA PRÁCTICA...22 Departamento de Informática Aplicada E.U. de Informática (U.P.M.) i

4

5 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Simulador para la planificación de procesos 1 Este simulador permite experimentar con varios algoritmos de planificación de procesos y comparar resultados tales como el rendimiento o el tiempo medio de espera en cada uno de dichos algoritmos. Entre los algoritmos soportados se incluyen: First Come/First Server (FCFS), Shortest Job First (SJF) y Round Robin (RR). Tanto las ráfagas de uso de CPU como de uso de I/O se describen mediante distribuciones de probabilidad Motivación La mayor parte de los ejercicios que vienen en los libros de texto sobre planificación de procesos son problemas con 5 ó 6 procesos y esto no es suficiente para evaluar los algoritmos de planificación. Por otro lado, al tener que realizar los cálculos a mano se dificulta poder variar los parámetros del problema y verificar su incidencia en las propiedades del sistema resultante tales como el rendimiento o el throughput Objetivos Con el uso de este simulador se pretenden alcanzar los siguientes dos objetivos: Ayudar al estudiante a comprender mejor la planificación de procesos incluyendo cómo trabajan los diferentes algoritmos y cómo los parámetros del sistema influyen en su rendimiento. Mostrar al estudiante métodos empíricos en un entorno informático real Descarga del software El software del simulador, fichero ps.zip (630K), puede descargarlo desde la página web de la asignatura. Además, estará instalado en la máquina cajal del Centro de Cálculo de la EUI Requisitos del sistema Un ordenador con entorno de ejecución java versión 1.1 o posterior. Se recomienda Java o superior. Este manual supone que ya están instalados los siguientes ficheros: o PS.jar o Jeli.jar o psconfig o myrun.run o myexp.exp o runps.bat (Windows) o runps (Unix) 1 Este documento es un extracto del documento Using the process scheduling simulator. Tanto ese documento como el software del simulador es obra de: Steven Robbins Department of Computer Science University of Texas at San Antonio 6900 North Loop 1604 West San Antonio, TX Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 1

6 Si ha instalado el simulador en un entorno diferente de Windows, puede ocurrir que los scripts no tengan los permisos adecuados. Tanto el fichero convert como el fichero runps deberían ser ejecutables. Los ficheros ASCII que vienen con la distribución están en formato Windows tal que cada línea termina en <CR><LF>. Para entornos Unix/Linux/Mac OSX, es mejor eliminar el <CR> al final de la línea. Se pueden eliminar todos estos <CR> de los ficheros ejecutando el script convert Procedimiento para realizar una simulación Los pasos básicos para realizar una simulación son: 1. Crear un fichero de configuración que describe las propiedades básicas del simulador. 2. Crear un experimento que contenga varias pruebas experimentales. 3. Ejecutar en el simulador el experimento creado. 4. Registrar los resultados Fichero de configuración Este fichero, de nombre psconfig, contiene información acerca de la ubicación de los experimentos y de dónde poner los ficheros de salida generados por la ejecución de dichos experimentos. Actualmente se pueden especificar las siguientes directivas: logdir, que indica el directorio que contendrá el fichero log. logfn, es el nombre del fichero log. imagename, es el nombre base del fichero GIF que contiene los gráficos que se insertarán en el fichero log. user, el nombre completo del usuario insertado en el fichero log. quiet, deshabilita el sonido cada vez que se pulsa sobre un botón; noquiet lo habilita. portable, un valor boolean. Si es true se utiliza un generador portable de números aleatorios que permite repetir los experimentos dando los mismos resultados (ver sección 1.7) run, que especifica el nombre del fichero que contiene una prueba experimental. exp, que especifica el nombre del fichero que contiene el experimento. A continuación se presenta un posible fichero psconfig: logdir /home/jorge/public/pslogs logfn logfile.html imagename gifim user Jorge Pérez quiet portable true run myrun exp myexp El experimento y la prueba experimental Un experimento se describe en un fichero ASCII con extensión.exp. Un experimento consiste de varias pruebas experimentales que serán comparadas y analizadas. Una prueba experimental indica un algoritmo de planificación y un conjunto de procesos. Se describe en un fichero ASCII con extensión.run. 2 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

7 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico La prueba experimental En su forma más simple, el formato del fichero que describe una prueba experimental es el siguiente: name nombre_de_la_prueba_experimental comment descripción_de_la_prueba_experimental algorithm descripción_del_algoritmo numprocs número_de_procesos firstarrival tiempo_de_la_primera_llegada interarrival distribución_entre_llegadas duration distribución_para_la_duración cpuburst distribución_de_las_ráfagas_de_cpu ioburst distribución_de_las_ráfagas_de_io basepriority prioridad A continuación se muestra el contenido de un fichero ejemplo que contiene la especificación para una prueba experimental: name myrun comment Esto es un ejemplo de especificación de una prueba experimental algorithm SJF numprocs 20 firstarrival 0.0 interarrival constant 0.0 duration uniform cpuburst constant 50.0 ioburst constant 1.0 basepriority 1.0 El fichero especifica que se ejecutarán un total de 20 procesos planificados según el algoritmo SJF. El primer proceso llega en el instante 0,0. Los tiempos entre llegadas son todos 0,0 lo que indica que todos llegan al mismo tiempo. Cada proceso tiene una duración (tiempo total de uso de CPU) elegida desde una distribución uniforme en el intervalo de 500 a Todos los procesos tienen un tiempo de ráfaga de CPU constante e igual a 50 y un pequeño tiempo de ráfaga de I/O constante e igual a 1. La prioridad especificada en el fichero solo se utiliza cuando se configura el simulador para que utilice prioridades El experimento El formato del fichero que describe un experimento contiene, además del nombre y una línea para comentarios, otro conjunto de líneas especificando las pruebas experimentales a realizar. Dichas pruebas se indican con el nombre del fichero que la contiene y, posiblemente, algunos parámetros. Por ejemplo, quizás esté interesado en ejecutar el mismo conjunto de procesos con el algoritmo Roun Robin pero variando el quantum. El formato de un fichero que especifica un experimento es el siguiente: name nombre_del_experimento comment descripción_del_experimento run nombre_de_la_prueba_experimental lista_opcional_de_parámetros run nombre_de_la_prueba_experimental lista_opcional_de_parámetros A continuación se muestra el contenido de un fichero ejemplo que contiene la especificación para un experimento: name myexp comment este experimento especifica 3 pruebas experimentales run myrun Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 3

8 run myrun cpuburst uniform run myrun cpuburst exponential 50 Este experimento describe tres pruebas experimentales. Todas las pruebas están basadas en la descripción contenida en el fichero myrun.run. En la segunda prueba se modifica la distribución de las ráfagas de CPU a una distribución uniforme en el intervalo En la tercera prueba se modifica a una distribución exponencial con valor medio de 50. Las posibles modificaciones que se pueden indicar sobre una prueba experimental y que pueden estar descritas en un fichero experimento son las siguientes: numprocs: el parámetro es el número de procesos a crear. firstarrival: el parámetro, un número en coma flotante, indica el tiempo de llegada del primer proceso. basepriority: el parámetro es la prioridad base del proceso creado. La prioridad base no es útil a menos que el simulador esté utilizando prioridades. interarrival: el parámetro es un string que representa la distribución entre los tiempos de llegada de los procesos. duration: el parámetro es un string que representa la distribución del tiempo total de CPU utilizado por los procesos. cpuburst: el parámetro es un string que representa la distribución de los tiempos de las ráfagas de CPU de los procesos. ioburst: el parámetro es un string que representa la distribución de los tiempos de las ráfagas de I/O de los procesos. algorithm: el parámetro es un string que representa el algoritmo de planificación. seed: el parámetro es un entero que representa la semilla a utilizar para inicializar el generador de números aleatorios. priorityoff: indica al simulador que no utilice prioridades. priorityon: indica al simulador que utilice una política de prioridades no expulsora. prioritypreempt: indica al simulador que utilice una política de prioridades expulsora. key: el parámetro indica la clave a utilizar en un gráfico de tiempos de espera. Si el parámetro contiene más de una palabra, éstas deben estar encerradas entre dobles comillas Registrar los resultados La ejecución del experimento en el simulador puede generar tablas o gráficos sobre varios estadísticos tales como el tiempo medio de espera o el throughput. La información sobre el experimento incluyendo la especificación de los procesos, las estadísticas y los gráficos resultantes se almacena en un fichero en formato HTML Tiempo El simulador utiliza un tiempo virtual representado por un número en coma flotante sin unidades. Cuando arranca el simulador, el tiempo se pone a 0,0. El simulador está dirigido por eventos y los eventos que ocurren al mismo tiempo pueden ocurrir en cualquier orden. 4 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

9 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Números aleatorios Java tiene un generador de número pseudoaleatorios que se utiliza cuando hay que seleccionar valores desde una distribución de probabilidad. Uno de los problemas de utilizar este generador es que a menos que todas las distribuciones sean constantes, diferentes ejecuciones sobre los mismos datos producirán resultados ligeramente distintos. Pero a veces es interesante repetir el mismo experimento para analizarlo en más profundidad. Poniendo la opción portable (sección 1.5.1) a true permite hacer esto. El simulador utiliza un generador portable de números pseudoaleatorios con una semilla fija tal que si se repite el mismo experimento con los mismos datos, producirá los mismos resultados. La semilla se inicializa al comienzo de cada prueba experimental, tal que una prueba no se vea afectada por otras anteriores. El simulador utiliza un generador de números aleatorios para calcular todas las distribuciones. Las ráfagas de CPU y de I/O de los procesos se calculan sobre la marcha para cada proceso. Los tiempos de ráfagas de CPU se calculan cuando el proceso entra en la cola de preparados. Puesto que el algoritmo de planificación puede afectar al orden en el que los procesos entran en la cola de preparados, el mismo conjunto de procesos ejecutándose bajo diferentes algoritmos de planificación tendrán ráfagas de duración diferente Procesos Un proceso se especifica describiendo la siguiente información: Tiempo de llegada. Tiempo total de CPU. Distribución del tiempo de ráfagas de CPU. Distribución del tiempo de ráfagas de I/O Distribuciones de probabilidad El simulador soporta actualmente tres tipos de distribuciones de probabilidad. Cuando se especifica una distribución de probabilidad en un fichero ASCII se representa en una única línea de texto. La línea comienza con una palabra indicando el tipo de distribución y va seguida por o bien un número en coma flotante representando la media de la distribución o, en el caso de la distribución uniforme, dos números en coma flotante representando las cotas inferior y superior del intervalo. A continuación se indica cómo especificar estas distribuciones: La distribución constante. Ejemplo: constant La distribución exponencial. Ejemplo: exponential La distribución uniforme. Ejemplo: uniform Distribución constante En una distribución constante el valor de la variable aleatoria siempre es el mismo Distribución exponencial La función de densidad tiene la forma: Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 5

10 λx λe, para x 0; f x ( x) = (1) 0, en otro caso donde λ ( λ > 0 ) es el parámetro de la distribución. La función de distribución tiene la forma siguiente: λx 1 e, para x 0; Fx ( x) = (2) 0, en otro caso 2 La media,, y la varianza,, son: m x =, σ x = 2 σ x m x (3) λ λ Distribución uniforme Una variable aleatoria continua X tiene una distribución uniforme sobre un intervalo de a..b (b > a) si la probabilidad de que tome cualquier valor de dicho intervalo es la misma. La función de densidad tiene la forma: 1, para a x b; f x ( x) = b a (4) 0, en otro caso. La función de distribución se obtiene integrando la fórmula (4) anterior, obteniéndose la expresión siguiente (5): 0, para x < a; x a F x ( x) =, para a x b; (5) b a 1, para x > b; La representación gráfica de ambas funciones se indica en la Figura 1. Figura 1. (a) Función de densidad y (b) función de distribución 2 La media,, y la varianza,, de X se hallan como: m x m x = b a σ x 1 xf x ( x) dx = b a a + b x dx = 2 a + b xdx = ; 2 ( b ) 2 2 b 2 a x a 1 σ = b a b a 12 (6) 6 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

11 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Algoritmos de planificación La siguiente discusión asume que las prioridades están off, que es el valor por omisión. Actualmente el simulador soporta los siguientes algoritmos de planificación: Roun Robin (RR): el usuario puede poner el quantum. Los procesos salen de la cola de preparados en el orden en el que llegaron. First-Come/First-Server (FCFS): los procesos se cogen de la cola de preparados según el orden en el que llegaron. Una vez que un proceso coge la CPU, la retiene hasta que expira el tiempo de la ráfaga actual de CPU. Entonces pasa a la cola de esperando por I/O hasta que expira el tiempo de la ráfaga actual de I/O. Shortest Job First (SJF): el siguiente proceso a seleccionar de la cola de preparados es el que tenga la ráfaga de CPU más corta. Si hay más de uno con la misma ráfaga más pequeña, se selecciona según el orden de llegada. Preemptive Shortest Job First (PSJF): el siguiente proceso a seleccionar de la cola de preparados es el que tenga la ráfaga de CPU más corta. Si hay más de uno con la misma ráfaga más pequeña, se selecciona según el orden de llegada. Si un proceso pasa a la cola de preparados y su ráfaga es más corta que lo que le queda de tiempo al proceso que se está ejecutando, se expulsa de la CPU al proceso actual. Shortest Job First Approximation (SJFA): Se hace una estimación del tamaño de la siguiente ráfaga de CPU del proceso (basada en el comportamiento pasado) y se selecciona aquel que tiene una estimación menor. La estimación inicial es 0. Un parámetro α, especificado por el usuario, tiene un valor entre 0 y 1. Si la última estimación fue b, y la última ráfaga fue de B, la siguiente estimación se calcula como αb + (1- α)b. El algoritmo de planificación se especifica con un string y opcionalmente un parámetro en coma flotante dependiendo del algoritmo. Los algoritmos es especifican de la siguiente forma: RR q: representa el algoritmo round robin con un tamaño de quantum de q. FCFS: representa el algoritmo primero en llegar, primero en ser servido. SJF: representa el algoritmo trabajo más corto el siguiente. PSJF: representa el algoritmo SJF expulsor. SJFA α: representa el algoritmo SJF con estimaciones usando el valor α Características adicionales Cuando comienza a ejecutarse el simulador, al primer proceso que llegue se le asigna la CPU. Esto ocurre incluso si llegan otros al mismo tiempo. Por eso, el primer proceso que se crea es el primero que llega independientemente del algoritmo de planificación utilizado. Las ráfagas de I/O de 0 unidades de tiempo se tratan como ráfagas de I/O muy pequeñas. Esto significa que cuando un proceso agota su actual ráfaga de CPU, el planificador selecciona otro proceso de la cola de preparados y deja al proceso que acaba de salir de nuevo en la cola de preparados. Solo se selecciona al mismo proceso si la cola de preparados estaba vacía Planificación por prioridades El simulador soporta la planificación de procesos con prioridades fijas. Una prioridad es un número en coma flotante siendo los mayores los que expresan una prioridad más alta. Por omisión, se ignoran las prioridades (priorityoff). El planificador Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 7

12 soporta dos modos de planificación por prioridades, expulsora (prioritypreempt) y no expulsora (priorityon) El simulador Arrancar el simulador Si va a utilizar el simulador instalado en cajal puede obviar el resto de este epígrafe. Si va a arrancar el simulador desde un pc con windows, sitúese en el directorio en el que está el software del simulador y ejecute el fichero runps. Si los ficheros jar los ubicó en un directorio diferente, es necesario modificar el fichero runps tal que las variables JARDIR1 o JARDIR2 indiquen la ubicación de los ficheros jar. Si el simulador no arranca, asegúrese que el runtime de Java está incluido en el path. Ejecute java version y verifique que se imprime una versión superior a la La interfaz del simulador La ventana principal del simulador se muestra en la Figura 2. En la parte superior hay dos áreas de texto etiquetadas con History y con Event List. Cada una de estas dos áreas tiene asociados 5 botones. El del medio (el más grande) visualiza (on) o no (off) el contenido del área de texto. El botón a su izquierda (Clr) borra el contenido del área de texto mientras que el botón de la derecha (Log) almacenada en el fichero log la información visualizada. Los dos botones pequeños en los extremos (etiquetados con < y >) disminuyen y aumentan respectivamente el tamaño del font del texto visualizado en la ventana. Figura 2. Ventana principal del simulador 8 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

13 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico El área de texto del ángulo superior izquierdo etiquetada History muestra la configuración inicial leída del fichero de configuración así como información variada acerca del progreso de la simulación. El área de texto de más a la derecha etiquetada Event List muestra los eventos según van ocurriendo Información sobre procesos y eventos Debajo de la ventana Event List hay 12 botones para visualizar información sobre procesos y eventos relativos a la última ejecución. Algunos botones tienen un número entre paréntesis después de la etiqueta. Este número indica el número aproximado de líneas que se visualizarán en la ventana History cuando se pulse sobre dicho botón. La función de cada botón es la siguiente: Events (n): visualiza todos los eventos en la cola de eventos. New (n): visualiza los procesos que se han creado y que todavía no han terminado. Waiting (n): visualiza todos los procesos que están esperando por I/O. All (n): visualiza información sobre todos los procesos. En la Figura 3 se ilustra un ejemplo de dicha información. Figura 3. Información sobre todos los procesos obtenida pulsando sobre el botón All Ready (n): visualiza información sobre los procesos que están en la cola de preparados. Finished (n): visualiza información sobre los procesos que ya han terminado. En la Figura 4 se muestra un ejemplo de esta información. Figura 4. Información visualizada cuando se pulsa el botón Finished Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 9

14 CPU History (n): visualiza una instantánea de los procesos entrando y saliendo de la CPU (ver Figura 5). Figura 5. Información visualizada cuando se pulsa el botón CPU History All Data 2 : recopila información sobre las pruebas experimentales realizadas desde que se arrancó el simulador por última vez (ver Figura 6 ). Figura 6. Información visualizada cuando se pulsa sobre el botón All Data. One History: visualiza una instantánea de los cambios de estado del proceso seleccionado después de pulsar sobre el botón (ver Figura 7). Figura 7. Información visualizada cuando se pulsa sobre el botón One History 2 Según Robbins: An obsolete button that shows (in the yellow window) some info about each of the runs. This information is now contained in the data table (Show Data or Log All Table Data). The info relates to the number of times the CPU is entered and the number of times an item is put in the ready queue. 10 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

15 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico One Statistics: visualiza información acerca del proceso seleccionado después de pulsar sobre el botón (ver Figura 8). Figura 8. Información visualizada cuando se pulsa sobre el botón One Statistics One Burst: visualiza información sobre las ráfagas de CPU y de I/O del proceso seleccionado después de pulsar sobre el botón (ver Figura 9). Figura 9. Información visualizada cuando se pulsa sobre el botón One Burst Saving Process History 3 : No tiene interés para la práctica actual Controles sobre el experimento y el algoritmo de planificación Debajo de esos botones se especifica el algoritmo de planificación actual así como el experimento que se está llevando a cabo (ver Figura 10). El conjunto de botones que aparecen en la Figura 10 están inhibidos. Solo están habilitados cuando el experimento se ejecuta de manera interactiva (Interactive Run) como se indicará más adelante. Figura 10. Botones para especificar el algoritmo y el experimento a ejecutar En la Figura 10 se indica que las prioridades están inhibidas (botón con la etiqueta Priority Off. Pulsando sucesivamente sobre ese botón obtendremos las etiquetas 3 Según Robbins: Show the current state of saving the history of what the simulator has done. By default, it saves a complete history of each process including when it enteres the CPU and starts I/O. This takes a lot of memory for long runs and can cause the simulator to run out of memory. Pushing this button turns off this feature and only averages are saved. Once you turn it off, you cannot turn it on again without restarting the simulator. Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 11

16 Priority On y Preemptive correspondientes a algoritmos con prioridades no expulsor y con prioridades expulsor, respectivamente (ver epígrafe 1.11). A la derecha de ese botón, existe uno que nos permite establecer el algoritmo de planificación. Si el algoritmo seleccionado es Round Robin, en el mismo botón se indica el valor actual del quantum y a la derecha aparecen un conjunto de botones que permiten variar este quantum. Si el algoritmo seleccionado es FCFS o SJF o PSJF ésta barra ocupa todo el espacio. Si el algoritmo seleccionado es SJFA en el mismo botón se indica el valor de α y a la derecha aparecen un conjunto de botones que permiten variar esta α. Inmediatamente debajo hay un botón etiquetado con Experiment y el nombre del experimento que se está ejecutando (myexp). A la derecha de este botón se indica la prueba experimental que se está ejecutando (por ejemplo: Run myrun 1) o bien figura la etiqueta Run All si se van a ejecutar todos los experimentos juntos (botón Run All) como se indicará más adelante. El botón etiquetado con Creator permite gestionar los parámetros del simulador a más bajo nivel y no es interés para la práctica actual Controles para la ejecución de experimentos Más abajo existen 5 columnas de botones. La primera columna (la de más a la izquierda) contiene botones relacionados con la ejecución de experimentos y creación/visualización de ficheros de configuración. La funcionalidad de esos botones es la siguiente: Change Experiment 4. Cambia de experimento avanzando a través de los experimentos según se leyeron cuando arrancó el simulador. El experimento por omisión se visualiza en la línea que está encima de este botón. Ese es el experimento que se ejecuta cuando se pulsa sobre el botón Run Experiment. Run All o Automatic Run o Interactive Run. Si el experimento tiene una sola prueba experimental, entonces las opciones son Automatic Run o Interactive Run. Si existe más de una prueba experimental las opciones son o bien ejecutar todos los experimentos automáticamente (Run All), o ejecutar unas de las pruebas experimentales automáticamente (Automatic Run) o ejecutar una de las pruebas experimentales interactivamente (Interactive Run). Run Experiment o Setup Experiment Run. La primera de estas dos etiquetas aparece si el botón de arriba está en Run All o Automatic Run. En ese caso este botón arranca la ejecución del experimento. La segunda de estas etiquetas aparece si el botón de arriba está en Interactive Run. En este caso, este botón crea los procesos necesarios para ejecutar la prueba experimental y además habilita los botones (sobre eventos) de la cuarta columna. Create File 5. Visualiza el menú pop-up indicado en la Figura 11. Figura 11. Menú pop-up asociado al botón Create File 4 Según Robbins: Change Experiment will only do something when the psconfig file contains more than one exp line. 5 Según Robbins: is an obsolete feature that could be used for creating runs on the fly, but is no longer supported. It will be removed in a future version 12 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

17 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico La funcionalidad asociada con las opciones del menú anterior son las siguientes: Create New Run. Visualiza el menú pop-up indicado en la Figura 12. Seleccionando Cancel se cierra el menú. Las otras dos opciones (Specify Values y Specify Creator) no hacen nada. Figura 12. Menú pop-up asociado al botón Create New Run Create New Experiment. No hace nada. Create New Group y Create New Creator. Permiten gestionar los parámetros del simulador a más bajo nivel y no son de interés para la práctica actual. Cancel. Cierra el menú. Show Files. Visualiza el menú pop-up indicado en la Figura 13. Figura 13. Menú pop-up asociado al botón Show Files La funcionalidad asociada con las opciones del menú anterior son las siguientes: Show Configuration File. Visualiza en el área de texto History el contenido del fichero de configuración. Show Run Files. Visualiza en el área de texto History el contenido de los ficheros que describen las pruebas experimentales. Show Exp Files. Visualiza en el área de texto History el contenido de los ficheros que describen los experimentos. Show Runs. Visualiza en el área de texto History el número de pruebas experimentales y algunas propiedades de éstas. Show Experiments. Visualiza en el área de texto History el número de experimentos y algunas propiedades de éstos. Show Groups y Show Creators. Permiten gestionar los parámetros del simulador a más bajo nivel y no son de interés para la práctica actual. Cancel. Cierra el menú Controles para el fichero log La segunda columna de botones de la Figura 2 controla el fichero log sobre el que se registran los resultados del experimento y los eventos del propio experimento. La funcionalidad de esos botones es la siguiente: Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 13

18 Open Log. Abre el fichero log y habilita el resto de botones. Después de pulsarlo su etiqueta cambia a Close Log. Si cierra el fichero log y se vuelve a abrir, se elimina el contenido anterior del fichero. La funcionalidad del segundo botón depende de si el fichero log está abierto o cerrado. Cuando el fichero log está cerrado, el botón tiene la etiqueta Change Log Filename y se puede utilizar para cambiar el directorio y el nombre del fichero log. Si se pulsa sobre este botón se visualiza la ventana indicada en la Figura 14. Figura 14. Ventana para cambiar el nombre del fichero log En la ventana de la Figura 14 cuando se pulsa sobre el botón etiquetado con Filename, este botón se convierte en un área de texto editable donde se puede introducir un nuevo nombre de fichero seguido de <CR>. Si mientras se está editando se quiere eliminar lo escrito se puede pulsar el botón Reset Filename. Los botones etiquetados con Directory y Reset Directory realizan la función análoga a los dos botones anteriormente descritos pero actuando sobre el directorio en el que se ubica el fichero log. Los botones etiquetados con Image Name y Reset Image Name establecen el nombre del fichero sobre el que salvarán los gráficos generados por el simulador. Los botones Abort y Done cierran la ventana eliminando/guardando los cambios introducidos respectivamente. Cuando el fichero log está abierto, el botón tiene la etiqueta Stop Log o Start Log. Inicialmente, cuando el fichero está abierto, comienza a registrarse información en el fichero log y la etiqueta es Stop Log. Si ahora se pulsa este botón se detiene el registro de datos y la etiqueta pasa a Start Log. El fichero log sigue abierto. La funcionalidad del tercer botón depende de si el fichero log está abierto o cerrado. Cuando el fichero log está cerrado, el botón tiene la etiqueta Replace Old Log o Append To Old Log. Cuando la etiqueta de este botón es la primera, si se abre el fichero log se pierde el contenido de ese fichero. Cuando la etiqueta de ese botón es la segunda, si se abre el fichero log el registro de datos se añade al contenido que ya tuviera el fichero. Cuando está abierto el fichero log, la etiqueta de este botón es Log Comment. Cuando se pulsa sobre el botón se visualiza una ventana que permite al usuario introducir un comentario en el fichero log. Log All Table Data. Si el fichero log está cerrado, este botón está deshabilitado. Crea dos tablas en el fichero log que contienen estadísticas sobre los datos salvados. Los datos se salvan de manera automática cuando acaba un experimento o cuando se pulsa sobre el botón Save Data, pero no aparecen en el fichero log hasta que se pulsa Log All Table Data. Las tablas contienen una entrada para cada prueba experimental ejecutada. Un ejemplo de tales tablas se ilustra en la Figura Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

19 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Description Algorithm Time Processes Finished CPU Utilization Entries Throughput CPU I/O CPU I/O Average Time myrun_1 FCFS myrun_2 SJF Turnaround Time Description Algorithm Average Minimum Maximum Waiting Time SD Average Minimum Maximum SD myrun_1 FCFS myrun_2 SJF Figura 15. Dos tablas creadas por el simulador con el botón Log All Table Data La primera tabla contiene información sobre la utilización de la CPU y el throughput para cada prueba experimental (myrun_1 y myrun_2). La columna etiquetada Entries especifica dos valores: el número de veces que los procesos entraron a la CPU y el número de veces que pidieron una I/O. La columna Average Time especifica dos valores: el tiempo medio gastado en la CPU y el tiempo medio por ráfaga de I/O. La segunda tabla contiene información más detallada sobre los tiempos de turnaround y de espera. El botón Edit Data de la siguiente columna se puede utilizar para limitar qué datos se registran en el fichero log. Show Remote Log 6. Este botón no tiene interés para la práctica actual. Draw Gantt Chart. Permite visualizar un diagrama de Gantt sobre el experimento ejecutado. Antes de eso, el usuario puede elegir sobre cuál de los algoritmos ejecutados quiere el diagrama (ver Figura 16). Figura 16. Selección del tipo de diagrama de Gantt Una vez seleccionado se visualiza en una ventana el citado diagrama (Figura 17). En el eje de abscisas se representa el tiempo mientras que en el de ordenadas se utiliza una fila para representar a cada uno de los procesos que han tomado parte en la simulación. Justo debajo del gráfico existen una serie de botones que tienen asignada la siguiente funcionalidad: Hide. Cierra la ventana. Update. Si el simulador está ejecutando una prueba experimental mientras se está dibujando el diagrama de Gantt, este botón permite actualizar dicho diagrama. Este botón solo es útil cuando la prueba experimental dura muchísimo tiempo. 6 Según Robbins: The Button "Show Remote Log" should be deactivated. If you are running remotely (from a browser) the simulator can be set up to save the log file on my server. You will not be using this feature. Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 15

20 Figura 17. Un ejemplo de diagrama de Gantt Relative/Absolute. Normalmente el diagrama de Gantt comienza cuando arranca el primer proceso independientemente de si éste arrancó en el instante 0. Con este botón se puede forzar a que el diagrama arranque en el instante 0. Home. El diagrama de Gantt se puede mover dentro de su propia ventana. Esto es útil cuando el diagrama no cabe completamente en la ventana. Si se pulsa este botón el diagrama vuelve a su posición original. Color. No tiene interés para la práctica actual. Scale. Si el diagrama no cabe en la ventana, al pulsar este botón el simulador intenta escalar el diagrama en el eje X (horizontalmente) tal que quepa en la ventana. Height. Cambia la altura de la ventana para que quepa el diagrama. Controls. Cuando se pulsa sobre este botón se abre un cuadro de controles para actuar sobre propiedades geométricas del diagrama (Figura 18). 16 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

21 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Figura 18. Cuadro de controles para actuar sobre la geometría de un diagrama de Gantt Save. Visualiza una ventana para que introduzca el nombre del fichero en el que quiere guardar el gráfico (Figura 19). Log. Permite insertar una copia del diagrama en el fichero log. Figura 19. Ventana para salvar a un fichero un diagrama de Gantt Controles para la creación de gráficos La tercera columna de botones de la Figura 2 controla la creación de gráficos. La funcionalidad de esos botones es la siguiente: Graph: Waiting, Graph: Waiting Box, Graph: Waiting Ratio, Graph: Waiting Ratio Box, Graph: Turnaround, Graph: Turnaround Box, Graph: CPU Burst, Graph: CPU Burst Box, Graph: Completed, Graph: Completed Box. Waiting significa que el gráfico contiene información sobre el tiempo de espera de los procesos de cada prueba experimental. Cada una de dichas pruebas aparece en un color distinto y la distribución de los tiempos de espera se muestra como un histograma. El tamaño de cada barra representa el tiempo de espera definido éste como el tiempo empleado en la cola de preparados. Pulsando sobre el botón Draw Graph se abre una ventana que contiene el gráfico (Figura 20). La ventana contiene un botón Log que al pulsarlo inserta el gráfico en el fichero log. Wating Ratio es la razón entre el tiempo de CPU y la suma del tiempo de CPU más el tiempo que pasó en la cola de preparados. Este ratio es útil para comparar procesos con un amplio rango de tiempos de CPU. Cuanto mayor es el valor, menor ha sido el tiempo de espera. Completed da la distribución de las fracciones que han completado los procesos. Eso solo es útil cuando se utiliza la interfaz de bajo nivel ya que al final del experimento todos los procesos han acabado (se han completado). Draw Graph. Dibuja en una ventana el gráfico del tipo indicado por el botón anterior. Show All Graphs. Visualiza todos los gráficos que previamente se hayan escondido. Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 17

22 Figura 20. Gráfico creado con Graph:Waiting seleccionado Edit Data. Permite seleccionar los datos que serán salvados o visualizados en un gráfico. Cuando se pulsa este botón aparece la ventana ilustrada en la Figura 21. Figura 21. Menú de edición del botón Edit Data Existe una fila por cada prueba experimental finalizada y una última línea con dos botones. Cada línea referida a una prueba experimental contiene dos botones. Pulsando sobre el botón Log lo cambia a NoLog e indica que la correspondiente prueba experimental no será registrada en el fichero log. Pulsando de nuevo sobre el mismo botón se vuelve a la situación original. El otro botón tiene la etiqueta Show. Cuando se pulsa la línea desaparece de la ventana del editor de datos. Se pueden visualizar las líneas ocultas pulsando sobre el botón Show Some que entonces cambia a Show All. El botón Done, cuando se pulsa, cierra la ventana del editor. Save Data. Salva las estadísticas actuales tal que se puedan registrar en el fichero log cuando se pulse el botón Log All Table Data. Show Data. Visualiza los datos que se registrarían en el fichero log cuando se pulse el botón Log All Table Data Control de bajo nivel del simulador La cuarta y la quinta columna de botones de la Figura 2 permiten un control más fino sobre la ejecución del simulador pero no son de interés para la práctica actual. El botón About 7 no hace nada. 7 Según Robbins: The About button used to do something, but no longer does 18 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

23 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Barras de progreso de la ejecución del simulador Por debajo de estas cinco columnas de botones hay dos barras que muestran el progreso de la simulación. La primera es roja y muestra la fracción del tiempo total de CPU utilizado hasta ese momento. Cuando la barra roja llegue al final, todos los procesos habrán terminado. La segunda barra es azul y muestra la fracción de procesos que se han completado Ayuda, Reset y Quit Por último, debajo del todo hay tres botones: Help. Visualiza una ventana de ayuda con información detallada sobre varios botones utilizados por el simulador. Cuando el puntero se pone sobre uno de esos botones, en la ventana se indica la funcionalidad de dicho botón. En la actual implementación del simulador no se da información sobre todos los botones. Reset. Elimina todos los procesos e inicializa todas las variables. Los datos salvados previamente no se eliminan. Quit. Se termina el simulador. El fichero log se cierra si estaba abierto. 2. Enunciado de la práctica Esta práctica está compuesta de varias partes. En las dos primeras realizará experimentos sencillos con el simulador. La tercera parte constituye el ejercicio práctico en si mismo Configuración del simulador Las instrucciones que se detallan a continuación se refieren a la instalación del simulador que hay en el Centro de Cálculo de la EUI sobre el ordenador cajal. En esta parte de la práctica personalizará la instalación del simulador. Siga los pasos que se indican a continuación: 1. Entre en su cuenta windows. Ejecute Xserver. Conéctese a cajal mediante putty. Entre en su cuenta en el ordenador cajal. 2. Cree un directorio llamado practica2 bajo el directorio so1s. Situese en ese directorio. 3. Copie los ficheros psconfig, myrun.run y myexp.exp al directorio actual desde el directorio /eui/practs/so1s/pss. 4. Ejecute el fichero runps. 5. Si todo es correcto, aparecerá la ventana principal del simulador como se indica en la Figura Pulse sobre el botón Quit que se haya en el ángulo inferior derecho. 7. Edite el fichero psconfig. Una de las líneas comienza por user. Quite el nombre que figura actualmente y ponga los nombres de los componentes del grupo así como sus números de matrícula. 8. Ejecute de nuevo runps. 9. Pulse sobre el botón etiquetado con Open Log. Ahora el botón debería decir Close Log. Con esta acción ha creado un fichero log llamado logfile.html en su directorio practica Pulse el botón Run Experiment. Esto arranca el simulador que terminará en un segundo. Se deberían haber ejecutado dos pruebas experimentales con 30 procesos. Una de ellas con el algoritmo FCFS y la otra con SJF. Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 19

24 11. Pulse en el botón Show Data. Se deberían visualizar tablas de estadísticas sobre los resultados de ejecutar las pruebas experimentales. Compare los tiempos medios de espera para los dos algoritmos. Cierre la ventana que contiene las tablas. 12. Abra el fichero logfile.html. En la primera línea del fichero debería estar su nombre, seguida por algunos datos que, por ahora, no tienen interés. 13. Pulse sobre el botón Log All Table Data. Refresque su navegador. Al final del fichero deberían aparecer unas tablas similares a las mostradas con Show Data. 14. Pulse sobre el botón Draw Gantt Chart. Se debería abrir una ventana pop-up para permitirle elegir entre FCFS y SJF. Seleccione FCFS y verá un diagrama de Gantt que muestra los estados de 30 procesos. Pulse sobre el botón Log en el ángulo inferior derecho. Ahora pulse sobre Hide que está en el ángulo inferior izquierdo. Pulse de nuevo sobre el botón Draw Gantt Chart y repita el proceso para SJF. 15. Refresque su navegador Ahora debería ver los dos diagramas de Gantt. Cierre el navegador. 16. Pulse sobre el botón Close Log y después sobre Quit. 17. Con el fichero logfile.html haga lo que se indica en el apartado 1 de la sección 3 de este manual Creación de experimentos En esta parte creará y ejecutará un experimento sencillo para poder comparar diferentes algoritmos de planificación. Siga los pasos que se indican a continuación: 1. Entre en su cuenta en cajal y sitúese dentro del directorio so1s/practica2. 2. Elimine cualquier fichero con extensión gif. 3. Ejecute runps. 4. Salga del simulador. 5. Modifique el fichero myexp.exp para que especifique 5 pruebas experimentales que usarán los siguientes algoritmos: FCFS, SJF, RR 1, RR 5 y RR Ahora modifique el fichero myrun.run tal que haya un total de 20 procesos con las siguientes propiedades: Todos los procesos llegan en el instante 0,0. Todos los procesos tienen una duración constante de 100. Todos los procesos tienen unas ráfagas de I/O constantes de 10. La prioridad de todos los procesos es 1,0. Los primeros 10 procesos tienen ráfagas de CPU uniformemente distribuidas entre 2 y 8. Los últimos 10 procesos tienen ráfagas de CPU uniformemente distribuidas entre 30 y 40. No cambie la línea seed del fichero de la prueba experimental. 7. Ejecute el simulador y cree un fichero log que contenga los datos para cada prueba experimental: en forma tabular y en forma de diagrama de Gantt. 8. Con el fichero logfile.html haga lo que se indica en el apartado 2 de la sección 3 de este manual 9. Describa cuál de los experimentos tiene el mejor tiempo medio de espera. También, compare la tendencia en los experimentos con RR según se incrementa el quantum. Para valores grandes de quantum RR se comportará como uno de los algoritmos de las otras pruebas experimentales Cuál? Cómo de grande debería ser el quantum? 20 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)

25 Sistemas Operativos I (I.T.I.S.) Práctica nº. 2 curso académico Ejercicio práctico Frecuentemente se confunde la duración de un proceso con las ráfagas de CPU del mismo. La duración representa la cantidad total de CPU que usará el proceso y se calcula cuando se crea el proceso. El simulador mantiene en todo momento la cantidad de tiempo de CPU que ya ha consumido cada proceso. Cuando un proceso consume su ráfaga actual de CPU, se actualiza el tiempo total de CPU consumido por ese proceso. Si esta cantidad es igual a la duración, el proceso termina sin hacer ninguna ráfaga de I/O adicional. En caso contrario, se calcula una nueva ráfaga de I/O. Cuando un proceso entra en la cola de preparados, el simulador usa la distribución de probabilidades para calcular la duración de la siguiente ráfaga de CPU. Este valor se compara con el tiempo resultante de la diferencia entre la duración del proceso y el tiempo que ya ha consumido. Si es necesario se reajusta el valor de la próxima ráfaga para que no supere la duración del proceso. Ahora, suponga que se ha creado un proceso con las siguientes características: duration constant 10 cpuburst uniform Cuántas ráfagas de CPU consumirá este proceso y cómo serán de largas? Parte 1 Tradicionalmente, el algoritmo de planificación de CPU en UNIX usa la carga media (load average) para realizar sus cálculos. La carga media se define como el número medio de procesos en la cola de preparados. Esta información no puede obtenerse directamente con el simulador pero se puede utilizar la ley de Little 8 que implica que la carga media es el tiempo total de espera dividido por el tiempo para el experimento. El tiempo total de espera es el total para todos los procesos. Se puede calcular utilizando el tiempo medio de espera dado en las tablas del simulador y multiplicándolo por el número de procesos. El tiempo para el experimento es el momento en el que acaba el último proceso y viene dado en las tablas del simulador. Ejecute el simulador con la configuración inicial. Calcule la carga media para cada una de las dos pruebas experimentales indicando cómo se ha llegado a ese resultado. Debería obtener los valores 20,59 y 10,07. Con el fichero logfile.html haga lo que se indica en el apartado 3.1 de la sección 3 de este manual Parte 2 El simulador no tiene en cuenta los tiempos de cambio de contexto o el tiempo de ejecución utilizado por el propio planificador para seleccionar el siguiente proceso a ejecutar. Se puede tener en cuenta los tiempos utilizados para cambios de contexto de la siguiente manera. Cada vez que ocurre un cambio de contexto, el tiempo para realizar dicho cambio debe sumarse al tiempo de espera de cada proceso en la cola de preparados. En la parte 1, ya calculó el número medio de procesos en la cola de preparados. Descubra el número de cambios de contexto para cada una de las dos pruebas experimentales de la parte 1. Esta información viene en la primera tabla de datos bajo la columna etiquetada Entries. El número de veces que un proceso entra a la CPU es el número de cambios de contexto. Ahora, para cada una de las dos pruebas 8 "The average number of customers in a system (over some interval) is equal to their average arrival rate, multiplied by their average time in the system." A corollary has been added: "The average time in the system is equal to the average time in queue plus the average time it takes to receive service." Departamento de Informática Aplicada E.U. de Informática (U.P.M.) 21

26 experimentales de la parte 1, calcule el tiempo para cambios de contexto que en total debería ser el 10% del tiempo total de espera. Para hacer esto: Sea x el tiempo invertido en un cambio de contexto. Si existen n cambios de contexto y la carga media es L, el tiempo de espera total debido a cambios de contexto es nxl. nxl = 0,1W, siendo W el tiempo total de espera. Calcule x. Muestre el cálculo para cada una de las dos pruebas experimentales de la parte 1. Debería obtener los valores 0,286 y 0, Parte a Reflexione acerca de las condiciones bajo las que PSJF se ejecuta mucho mejor (con respecto al tiempo medio de espera) que su versión no expulsora. Escriba un párrafo describiendo esas condiciones (hipótesis) b Diseñe un experimento en el que PSJF se ejecute mucho mejor que SJF. El experimento debe tener 2 pruebas experimentales que difieran solamente en el algoritmo de planificación. Intente diseñar un experimento con las siguientes características: Al menos deben existir 10 procesos. El tiempo medio de espera para SJF es al menos dos veces que el de PSJF. La utilización de la CPU está entre el 50% y el 90%. La carga media es mayor que 1. Ejecute el experimento utilizando el simulador. Cree un fichero log que contenga los datos en forma tabular y diagramas de Gantt para las dos pruebas experimentales. Con el fichero logfile.html haga lo que se indica en el apartado 3.3 de la sección 3 de este manual Calcule la carga media para cada una de las dos pruebas experimentales c Si realizó el experimento de acuerdo con las especificaciones, el simulador habrá mostrado que PSJF tiene un tiempo de espera menor que SJF. Sin embargo, el simulador no tiene en cuenta el tiempo para los cambios de contexto y PSJF genera más cambios de contexto que SJF. Para cambios de contexto que consumen mucho tiempo, es posible que SJF tenga un tiempo medio de espera menor que PSJF. Calcule, para sus dos pruebas experimentales, cómo de grande debe ser el tiempo de cambio de contexto para que las dos pruebas experimentales tengan el mismo tiempo medio de espera. Use el método de la parte d Suponga que a alguien (a un compañero o a usted mismo) el cálculo de la parte 3c arroja un resultado negativo. Es posible? Qué significa? 3. Entrega de la práctica Debe entregar un documento word con los apartados que se indican a continuación. 22 Departamento de Informática Aplicada E.U. de Informática (U.P.M.)