1. Objetivo del proyecto
El objetivo es validar el modelo del simulador contrastándolo con mediciones reales en Linux. Los pasos son:
- Generar una carga de trabajo. Usar el generador del simulador para crear una carga reproducible con una semilla fija. generar
- Medir en Linux. Ejecutar los procesos reales y medir sus tiempos (turnaround, espera, respuesta) con las herramientas del sistema. medir
- Simular. Ejecutar el mismo algoritmo en el simulador con la misma carga. simular
- Comparar. Contrastar las métricas del sistema real con las del simulador. comparar
- Analizar. Explicar las diferencias y validar el modelo. analizar
Este proyecto es la culminación del curso: valida todo lo aprendido y da confianza en el modelo.
2. Metodología
La metodología del proyecto es:
- Carga de trabajo: usar el generador con una semilla fija para reproducibilidad. El mismo conjunto de procesos se usa en el sistema real y en el simulador.
- Algoritmo: FCFS (el más simple de comparar, porque no depende de parámetros externos).
- Medición: usar
/proc/PID/schedstatpara medir tiempo en CPU y tiempo en cola. El programatrabajo.cdel tema 1 es la herramienta de medición. - Comparación: tabla con las métricas del sistema real y del simulador, y análisis de las diferencias.
El experimento se repite varias veces para obtener resultados estadísticamente significativos.
3. Medir en Linux
Para medir en Linux, se siguen estos pasos:
- Compilar trabajo.c:
gcc -std=c17 -Wall -Wextra -o trabajo trabajo.c. compilar - Fijar a un CPU:
taskset -c 0para que todos los procesos compitan por el mismo CPU. fijar - Ejecutar los procesos: lanzar todos a la vez con
&. UsarT0para sincronizar el origen de tiempo. ejecutar - Medir: leer la salida de cada proceso (tiempo en CPU, espera en cola, turnos). medir
- Repetir: ejecutar varias veces y promediar. repetir
Los datos medidos se comparan con las predicciones del simulador. El programa trabajo.c reporta el tiempo de CPU (sum_exec_runtime) y la espera en la cola (schedstat segundo número), que son exactamente las métricas que calcula el simulador.
4. Simular la misma carga
Para simular la misma carga en el simulador:
- Generar la carga: usar el mismo generador con la misma semilla que en el experimento. generar
- Ejecutar FCFS: correr el algoritmo FCFS sobre la carga. ejecutar
- Calcular métricas: tiempo de respuesta, espera y retorno promedio. métricas
- Comparar: contrastar con las mediciones del sistema real. comparar
La carga debe ser la misma (mismos procesos, mismas ráfagas, mismas llegadas) para que la comparación sea válida.
5. Comparar resultados
La comparación se hace en una tabla:
| Métrica | Sistema real | Simulador | Diferencia | Diferencia % |
|---|---|---|---|---|
| Tiempo de espera promedio | X ms | Y ms | X - Y | (X-Y)/Y × 100 |
| Tiempo de retorno promedio | X ms | Y ms | X - Y | (X-Y)/Y × 100 |
| Tiempo de respuesta promedio | X ms | Y ms | X - Y | (X-Y)/Y × 100 |
| Throughput | X proc/s | Y proc/s | X - Y | (X-Y)/Y × 100 |
La diferencia porcentual indica qué tan bien el simulador predice el sistema real. Una diferencia del 10-20 % es aceptable; más del 50 % indica que el modelo necesita mejoras.
6. Por qué difieren
Las mediciones reales difieren del simulador por varios factores:
- Overhead del sistema: el núcleo ejecuta otras tareas (interrupciones, daemons, kthreads) que no se modelan en el simulador. Estas tareas consumen CPU y retrasan los procesos.
- Latencia de despacho: el cambio de contexto consume tiempo que el simulador no incluye (a menos que se añada explícitamente). El overhead del despacho puede ser de 1-10 μs por cambio.
- Cache effects: los procesos reales tienen cache misses que el simulador no modela. Los cache misses añaden latencia impredecible.
- Precisión del reloj: las mediciones tienen error de medición (resolución del reloj, overhead de la medición).
- Scheduling real: Linux usa CFS (no FCFS) para la clase normal. Aunque se fijen los procesos a un CPU, CFS puede repartir la CPU de forma diferente a FCFS.
- Procesos del sistema: otros procesos del sistema compiten por la CPU, incluso con taskset (porque el núcleo ejecuta tareas en todos los CPUs).
- Interrupciones: las interrupciones de hardware (timer, red, disco) interrumpen los procesos y añaden latencia.
Estas diferencias son esperadas y no invalidan el modelo: el simulador captura el comportamiento cualitativo, no el cuantitativo exacto.
7. Análisis de las diferencias
El análisis de las diferencias es la parte más importante del proyecto. Para cada diferencia, se debe:
- Identificar la causa: ¿qué factor del sistema real no se modela en el simulador? causa
- Cuantificar el efecto: ¿cuánto contribuye cada factor a la diferencia? cuantificar
- Mejorar el modelo: ¿se puede añadir el factor al simulador para reducir la diferencia? mejorar
- Validar: ¿el modelo mejorado reproduce mejor los resultados? validar
Por ejemplo, si la diferencia se debe al overhead del cambio de contexto, se puede añadir un costo de cambio al simulador (como en el tema 22) y verificar si la diferencia se reduce.
El análisis de las diferencias es un proceso iterativo: identificar, cuantificar, mejorar, validar. Cada iteración mejora el modelo y reduce la diferencia.
8. Conclusiones
Las conclusiones típicas del proyecto son:
- El simulador captura el comportamiento cualitativo: los patrones (quién espera más, quién termina antes, cómo afecta el orden) se repiten en el sistema real. El simulador es útil para comparar algoritmos y entender su comportamiento.
- Los valores absolutos difieren: el sistema real tiene overhead que el simulador no incluye. Las mediciones reales son siempre mayores que las predicciones del simulador.
- El modelo es útil para comparar algoritmos: aunque los valores absolutos difieran, la comparación relativa (qué algoritmo es mejor) se mantiene. El simulador es una herramienta válida para evaluar algoritmos.
- La validación es importante: contrastar el simulador con el sistema real da confianza en el modelo y ayuda a entender sus limitaciones.
- El modelo se puede mejorar: añadiendo el costo del cambio de contexto, el overhead del sistema y otros factores, el simulador puede acercarse más a la realidad.
9. Simulador interactivo
Este simulador reproduce el experimento: genera una carga, simula FCFS y muestra las métricas predichas. Compáralas con las que medirías en Linux:
Simulador · validación de modelo
| Proceso | Llegada | Ráfaga | Inicio (sim) | Fin (sim) | Espera (sim) | Retorno (sim) |
|---|---|---|---|---|---|---|
10. Resumen
- El proyecto valida el modelo del simulador contrastándolo con mediciones reales.
- Se usa trabajo.c para medir tiempo de CPU y espera en cola.
- Los procesos se fijan a un CPU con taskset.
- Las mediciones se comparan con las predicciones del simulador.
- Las diferencias se deben a overhead, caché, precisión y otros factores.
- El simulador captura el comportamiento cualitativo.
- La comparación relativa (qué algoritmo es mejor) se mantiene.
- La validación da confianza en el modelo.
11. Preguntas de repaso
Intenta responder cada una antes de abrir la respuesta.
1. ¿Qué se valida en este proyecto?
El modelo del simulador, contrastándolo con mediciones reales en Linux.
2. ¿Qué herramienta se usa para medir en Linux?
trabajo.c, que reporta tiempo de CPU y espera en cola.
3. ¿Por qué se usa taskset?
Para fijar los procesos a un CPU, de modo que compitan por el mismo procesador.
4. ¿Por qué difieren las mediciones del sistema real?
Por overhead del sistema, latencia de despacho, cache effects, precisión del reloj y procesos del sistema.
5. ¿El simulador captura el comportamiento cuantitativo exacto?
No. Captura el comportamiento cualitativo (patrones), no los valores absolutos.
6. ¿Es útil el simulador a pesar de las diferencias?
Sí. La comparación relativa (qué algoritmo es mejor) se mantiene.
7. ¿Qué se mide con /proc/PID/schedstat?
Tiempo en CPU, tiempo en cola y número de turnos.
8. ¿Qué conclusión se puede sacar del proyecto?
El simulador es útil para comparar algoritmos, aunque los valores absolutos difieran.
9. ¿Por qué es importante la validación?
Da confianza en el modelo y ayuda a entender sus limitaciones.
10. ¿Qué bloque del curso cierra este proyecto?
El bloque 11 (integración y cierre).
11. ¿Qué factor del sistema real no se modela en el simulador?
El overhead del sistema, la latencia de despacho, los cache effects y los procesos del sistema.
12. ¿Cómo se puede mejorar el modelo?
Añadiendo el costo del cambio de contexto, el overhead del sistema y otros factores.
Para practicar
- Ejecuta el experimento completo y compara con el simulador.
- Analiza las diferencias y explica cada una.
- Añade el costo del cambio de contexto al simulador y verifica si mejora la coincidencia.
- Repite el experimento con nice distinto y compara.
- Investiga cómo se miden los tiempos en el núcleo de Linux.
- Documenta las conclusiones del proyecto.
- Modifica el simulador para incluir el overhead del sistema como parámetro.