1. Por qué el quantum importa
El quantum es el único parámetro de Round Robin, y determina todo el comportamiento del algoritmo. No hay un valor «correcto» universal: depende de la carga de trabajo, del hardware y de los objetivos del sistema.
El quantum afecta a dos magnitudes que compiten:
- Tiempo de respuesta: cuanto más corto sea el quantum, más frecuentemente reciben la CPU los procesos, y mejor es la respuesta.
- Overhead: cuanto más corto sea el quantum, más cambios de contexto se producen, y mayor es el tiempo perdido en ellos.
Elegir el quantum es elegir dónde poner el equilibrio entre estas dos magnitudes. Un quantum mal elegido puede hacer que Round Robin sea peor que FCFS (si es demasiado largo) o que desperdicie la CPU (si es demasiado corto).
No existe un quantum perfecto. Un valor que es bueno para una carga de trabajo puede ser malo para otra. Por eso, los sistemas operativos modernos no usan un quantum fijo, sino que lo ajustan dinámicamente.
2. Los dos extremos
Los dos extremos del quantum son instructivos:
| Quantum | Comportamiento | Equivalente a |
|---|---|---|
| q → ∞ (infinito) | Cada proceso se ejecuta hasta terminar. No hay interrupciones. | FCFS |
| q → 0 (cero) | La CPU se reparte en infinitos turnos infinitesimales. Todos los procesos se ejecutan simultáneamente. | Processor sharing (compartición perfecta) |
Un quantum infinito convierte a Round Robin en FCFS: no hay apropiación, los procesos se ejecutan en orden de llegada. Un quantum infinitesimal convierte a Round Robin en un procesador compartido ideal: todos los procesos avanzan a la misma velocidad, pero el overhead de cambios de contexto es infinito.
El quantum real está entre estos dos extremos, y su valor determina qué tan cerca está Round Robin de cada uno.
3. Quantum demasiado corto
Si el quantum es muy corto (por ejemplo, 1 ms o menos), ocurren varios problemas:
- Demasiados cambios de contexto: cada quantum implica un cambio de contexto. Si el quantum es 1 ms y hay 10 procesos, se producen 10 cambios de contexto por cada 10 ms de CPU.
- Overhead excesivo: cada cambio de contexto consume tiempo (guardar/restaurar registros, actualizar estructuras del núcleo). Si el cambio tarda 0,1 ms y el quantum es 1 ms, el 10 % de la CPU se desperdicia en overhead.
- La CPU no avanza: si el overhead es mayor que el trabajo útil, los procesos avanzan muy lentamente.
- Cache thrashing: cambios de contexto frecuentes invalidan la caché de la CPU, reduciendo el rendimiento.
En el límite, con quantum → 0, el overhead tiende a infinito y la CPU no hace trabajo útil. Round Robin deja de funcionar.
El quantum debe ser significativamente mayor que el tiempo de cambio de contexto. Si el cambio tarda 10 μs, el quantum debería ser al menos 100-1000 μs para que el overhead sea aceptable (1-10 %).
4. Quantum demasiado largo
Si el quantum es muy largo (por ejemplo, 100 ms o más), ocurren otros problemas:
- Se acerca a FCFS: si la mayoría de los procesos terminan en menos de un quantum, no hay interrupciones. Round Robin se comporta como FCFS.
- Mal tiempo de respuesta: un proceso que llega justo después de que otro empezó su quantum debe esperar todo el quantum para recibir la CPU.
- Efecto convoy: un proceso largo que recibe la CPU bloquea a los demás durante todo el quantum.
- Mala interactividad: el usuario percibe retrasos notables (más de 100 ms se percibe como lento).
En el límite, con quantum → ∞, Round Robin es FCFS: no hay apropiación, no hay equidad, no hay buena respuesta.
5. El trade-off
El quantum determina el equilibrio entre respuesta y overhead. Esta tabla resume el trade-off:
| Quantum | Tiempo de respuesta | Overhead | Equidad | Comportamiento |
|---|---|---|---|---|
| Muy corto (1 ms) | Excelente | Alto (10-50 %) | Excelente | Cerca de processor sharing |
| Corto (10 ms) | Bueno | Moderado (1-5 %) | Bueno | Equilibrio típico |
| Medio (50 ms) | Aceptable | Bajo (0,1-1 %) | Aceptable | Cerca de FCFS |
| Muy largo (100 ms+) | Malo | Muy bajo | Malo | Prácticamente FCFS |
El valor óptimo depende de la carga de trabajo y del hardware. No hay una fórmula universal, pero hay reglas prácticas.
6. Efecto en el tiempo de respuesta
El tiempo de respuesta promedio en Round Robin depende del quantum. Para n procesos que llegan en 0, con ráfagas similares:
- Si todas las ráfagas son menores que q: cada proceso se ejecuta de una vez. El tiempo de respuesta es el mismo que FCFS (0 para el primero, q para el segundo, etc.).
- Si las ráfagas son mayores que q: los procesos se intercalan. El tiempo de respuesta del primer proceso es 0, del segundo es q, del tercero es 2q, etc.
En general, el tiempo de respuesta promedio en Round Robin es mejor que en FCFS (porque los procesos cortos no esperan a los largos) pero peor que en SJF (porque los procesos cortos se intercalan con los largos).
Un quantum más corto mejora la respuesta, pero a costa de más cambios de contexto. Un quantum más largo empeora la respuesta, pero reduce el overhead.
7. Efecto en el overhead
El overhead de Round Robin se mide como el porcentaje de tiempo de CPU que se gasta en cambios de contexto. Si el cambio de contexto tarda c y el quantum es q, el overhead es:
Overhead = c / (c + q) × 100 %
Por ejemplo, si el cambio de contexto tarda 10 μs y el quantum es 10 ms (10 000 μs), el overhead es 10 / (10 + 10000) = 0,1 %. Si el quantum es 1 ms (1000 μs), el overhead es 10 / (10 + 1000) = 1 %. Si el quantum es 100 μs, el overhead es 10 / (10 + 100) = 9 %.
El overhead también incluye el costo de la caché: cambios de contexto frecuentes invalidan la caché de la CPU, lo que reduce el rendimiento de los procesos. Este costo es difícil de cuantificar pero puede ser significativo.
Además del tiempo de guardar/restaurar registros, hay el costo de la caché (cache misses), el costo del planificador (buscar el siguiente proceso) y el costo de actualizar las estructuras del núcleo. El overhead total puede ser 2-5 veces el tiempo del cambio de contexto.
8. La regla del 80 %
La regla práctica más conocida para elegir el quantum es la regla del 80 %:
El quantum debe ser tal que el 80 % de las ráfagas de CPU sean más cortas que el quantum.
La idea es que la mayoría de los procesos terminen en un solo quantum, evitando cambios de contexto innecesarios. Solo los procesos con ráfagas largas (el 20 % restante) se interrumpen.
Esta regla se basa en la distribución de cola larga de las ráfagas (tema 2): la mayoría de las ráfagas son cortas, pero unas pocas son muy largas. Si el quantum cubre al 80 % de las ráfagas, la mayoría de los procesos se ejecutan de una vez, y solo los largos se interrumpen.
Para aplicar la regla, se necesita conocer la distribución de las ráfagas. En la práctica, se mide la distribución en el sistema y se elige el quantum que cubre al 80 %.
Si el 80 % de las ráfagas son menores que 10 ms, el quantum debería ser de 10 ms. Con este valor, el 80 % de los procesos se ejecutan de una vez, y solo el 20 % se interrumpen. El overhead es bajo y la respuesta es buena.
9. Un ejemplo desarrollado
Un sistema tiene estas ráfagas (en ms): 2, 3, 5, 8, 10, 15, 20, 50. Calculemos el quantum óptimo según la regla del 80 %:
| Ráfaga (ms) | Porcentaje acumulado |
|---|---|
| 2 | 12,5 % |
| 3 | 25,0 % |
| 5 | 37,5 % |
| 8 | 50,0 % |
| 10 | 62,5 % |
| 15 | 75,0 % |
| 20 | 87,5 % |
| 50 | 100,0 % |
El 80 % de las ráfagas son menores o iguales a 20 ms. Según la regla del 80 %, el quantum debería ser de 20 ms. Con este valor, el 87,5 % de los procesos se ejecutan de una vez.
Si el quantum fuera de 10 ms, solo el 62,5 % se ejecutaría de una vez, y el overhead sería mayor. Si fuera de 50 ms, el 100 % se ejecutaría de una vez (equivalente a FCFS para esta carga).
10. Valores en sistemas reales
| Sistema | Quantum típico | Notas |
|---|---|---|
| Linux (CFS) | Dinámico (1-10 ms) | No hay quantum fijo. Se calcula según el número de procesos y la latencia objetivo. |
| Windows | 10-15 ms | Quantum fijo, ajustable por el usuario. |
| macOS | 10 ms | Quantum fijo para la clase normal. |
| Sistemas embebidos | 1-5 ms | Quantum corto para respuesta rápida. |
| Servidores | 10-100 ms | Quantum más largo para reducir overhead. |
Los valores típicos están en el rango de 1 a 100 ms. Un valor de 10 ms es un buen compromiso para la mayoría de los sistemas.
11. Simulador interactivo
Este simulador ejecuta Round Robin con diferentes valores de quantum y muestra el efecto en el Gantt y las métricas. Cambia el quantum y observa:
Simulador · efecto del quantum
| Proceso | Llegada | Ráfaga | Inicio | Fin | Respuesta | Espera | Retorno |
|---|---|---|---|---|---|---|---|
12. Resumen
- El quantum determina el equilibrio entre respuesta y overhead en Round Robin.
- Un quantum demasiado corto genera demasiados cambios de contexto y overhead excesivo.
- Un quantum demasiado largo se acerca a FCFS y pierde la equidad y la respuesta.
- El overhead es c / (c + q) × 100 %, donde c es el tiempo de cambio de contexto.
- La regla del 80 %: el quantum debe cubrir al 80 % de las ráfagas.
- Los valores típicos están entre 1 y 100 ms; 10 ms es un buen compromiso.
- Linux usa un quantum dinámico que se ajusta según el número de procesos.
- No hay un quantum universal: depende de la carga de trabajo y del hardware.
13. Preguntas de repaso
Intenta responder cada una antes de abrir la respuesta.
1. ¿Qué ocurre si el quantum es demasiado corto?
Demasiados cambios de contexto, overhead excesivo, la CPU no avanza.
2. ¿Qué ocurre si el quantum es demasiado largo?
Round Robin se acerca a FCFS: mala respuesta, efecto convoy, pérdida de equidad.
3. ¿Cuál es la fórmula del overhead?
Overhead = c / (c + q) × 100 %, donde c es el tiempo de cambio de contexto y q el quantum.
4. ¿En qué consiste la regla del 80 %?
El quantum debe ser tal que el 80 % de las ráfagas de CPU sean más cortas que el quantum.
5. ¿Por qué la regla del 80 % se basa en la distribución de cola larga?
Porque la mayoría de las ráfagas son cortas. Si el quantum cubre al 80 %, la mayoría de los procesos se ejecutan de una vez.
6. ¿Qué valor de quantum es típico en Linux?
No hay un valor fijo: es dinámico, entre 1 y 10 ms, calculado según el número de procesos.
7. ¿Qué ocurre en el límite cuando q → 0?
Round Robin se convierte en processor sharing: todos los procesos avanzan simultáneamente, pero el overhead es infinito.
8. ¿Qué ocurre en el límite cuando q → ∞?
Round Robin se convierte en FCFS: no hay apropiación.
9. ¿Por qué un quantum de 10 ms es un buen compromiso?
Porque es suficientemente corto para buena respuesta y lo suficientemente largo para mantener el overhead bajo (1-5 %).
10. ¿El overhead incluye solo el cambio de contexto?
No. También incluye el costo de la caché, del planificador y de actualizar las estructuras del núcleo.
Para practicar
- Calcula el overhead para c = 10 μs y q = 5 ms, 10 ms, 50 ms.
- Dibuja el Gantt para el mismo conjunto con quantum 2 y quantum 5, y compara las métricas.
- Aplica la regla del 80 % a la distribución: 1, 2, 3, 5, 8, 10, 15, 20, 30, 50.
- Explica por qué un quantum muy corto causa cache thrashing.
- Investiga cómo Linux calcula el quantum dinámico en CFS.
- Modifica el simulador para mostrar el overhead estimado.