The problem round robin was born to fix
In the previous guide you met FCFS and watched its quiet disaster, the convoy effect: one long job arrives first, grabs the CPU, and every short job behind it waits and waits, like a single slow truck blocking a whole lane of cars. You also met SJF, which is provably optimal for average waiting time but cheats — it needs to know the future, the exact length of each job's next CPU burst, which a real OS simply does not have. So we are stuck between a scheduler that is fair but can freeze everyone, and one that is brilliant but clairvoyant. Round robin walks a different road entirely.
Here is the whole idea in one sentence: give each ready job a small, equal slice of CPU time, and the instant its slice runs out, stop it and move to the next job in line. Picture a teacher with one microphone and a circle of eager children. Instead of letting the first child talk until they are completely finished (that is FCFS), the teacher hands the mic to each child for thirty seconds, then gently takes it back and passes it on — round and round the circle. Nobody hogs the mic, and a child with one quick question is heard almost immediately instead of waiting an hour for a long-winded classmate to wrap up.
That "gently takes it back" is the crucial move. Round robin is the textbook example of a preemptive scheduler — see preemptive vs non-preemptive. It does not wait for a job to finish or to voluntarily give up the CPU; it forcibly interrupts a running job the moment its slice expires. This is the same mechanism that makes time-sharing possible, the trick that lets dozens of users (or dozens of your browser tabs) feel like they each have the machine to themselves. The slice it hands out has a name we will live with for the rest of this guide: the time quantum.
Meet the time quantum
The time quantum (also called the time slice) is the fixed length of CPU time each job is allowed to run before the scheduler steps in. Typical real values sit in the small-milliseconds range — often something like 10 ms to 100 ms — though the exact number varies wildly by system and we will see why the choice matters so much. The whole behavior of round robin lives in this one number. Turn the dial too high and round robin quietly becomes FCFS again. Turn it too low and the machine spends all its energy switching and almost none doing real work. Getting this number right is the entire art.
How does the OS actually take the mic back? It does not (and cannot) trust a running job to politely stop. Instead the kernel programs a hardware timer to fire an interrupt — a doorbell — after exactly one quantum. When that doorbell rings, the CPU jumps out of the running job and into the kernel, which then runs the scheduler. This is why preemption needs hardware help: without a timer interrupt, a job that never makes a system call could run forever and no software could stop it. The timer is the building manager's alarm clock, going off on a fixed schedule no matter what any tenant is doing.
Trace it: three processes, a quantum of 4
Numbers make this real. Suppose three processes all arrive at time 0 and need these CPU bursts: P1 needs 10, P2 needs 4, P3 needs 5. We set the quantum to 4 time units. The scheduler keeps a ready queue — a simple FIFO line of jobs waiting for the CPU. It takes the front job, runs it for up to one quantum, and if the job still has work left when the timer fires, it goes to the back of the line. Let's walk it minute by minute, the way you would actually step through it on paper.
- Time 0–4: P1 runs for a full quantum. It needed 10, so 6 remain. The timer fires, P1 goes to the back of the queue. Order now: P2, P3, P1.
- Time 4–8: P2 runs. It needed exactly 4, so it finishes right as the quantum ends and leaves for good. Order now: P3, P1.
- Time 8–12: P3 runs a full quantum. It needed 5, so 1 remains. P3 goes to the back. Order now: P1, P3.
- Time 12–16: P1 runs a full quantum. It had 6 left, so 2 remain. P1 goes to the back. Order now: P3, P1.
- Time 16–17: P3 runs its last 1 unit and finishes. Order now: P1.
- Time 17–19: P1 runs its last 2 units and finishes. The queue is empty; everyone is done.
quantum = 4 bursts: P1=10 P2=4 P3=5 | P1 | P2 | P3 | P1 |P3| P1 | 0 4 8 12 16 17 19 finishes: P2 @ 8 P3 @ 17 P1 @ 19 turnaround (arrived @0): P1=19 P2=8 P3=17 avg = 14.7 response (first run): P1=0 P2=4 P3=8
Look hard at what this bought us and what it cost. The win is response time: every process got a taste of the CPU early, so an interactive job feels alive almost immediately — exactly what you want when you are typing and expecting the cursor to move. The cost shows up in turnaround time: P1, the long job, did not finish until time 19, later than it would under plain FCFS where it might have run 0–10 and finished at 10. Round robin deliberately trades a little turnaround for a lot of responsiveness. That trade is the soul of every interactive system you have ever used.
The dial: why the quantum size is everything
Now the heart of the matter. Every time the timer fires and we switch from one job to another, we pay for a context switch: the kernel must save the outgoing job's registers and CPU state, load the incoming job's, and the run finds cold caches afterward. That switch takes real time — call it the overhead — and during it the CPU does zero useful work. The quantum decides how often we pay this toll. If the quantum is q and a switch costs s, then the fraction of time genuinely wasted is roughly s / (q + s).
Push the dial to one extreme. Make the quantum very large — larger than every job's burst — and no job ever gets preempted, because each one finishes before its slice runs out. Round robin has silently turned back into FCFS, convoy effect and all. Now push to the other extreme. Make the quantum tiny, say 1 ms while a switch also costs about 1 ms; now nearly half of all CPU time is burned on switching and the machine crawls. Worse, this is a real pathology with a name worth keeping: when the quantum gets too small the system can thrash on context switches, doing more bookkeeping than work.
One honest subtlety to retire a common misconception: turnaround time does not improve smoothly as you shrink the quantum. You might expect that smaller slices always mean a better average, but it is not so — turnaround can actually get worse with a smaller quantum once switching overhead piles up, and the real relationship is bumpy rather than a clean downhill slide. The lesson is that the quantum is a genuine engineering trade-off with no free lunch, not a knob you simply turn toward zero.
What round robin still cannot do
Round robin is fair, simple, and starvation-free — every job in the ready queue is guaranteed a turn within roughly (n-1) quanta if there are n jobs, so nobody is left waiting forever. That guarantee is genuinely valuable and is why round robin sits at the core of so many real schedulers. But fairness is also exactly its blind spot. Round robin treats every job as equally deserving, which is wonderful for equals and terrible when jobs are not equal. Your music player and a background backup both get the same slice, even though you would gladly let the backup wait so your audio never stutters.
There is a second, subtler unfairness. Plain round robin is unkind to jobs that do a lot of input/output. Recall from guide 1 that processes alternate between CPU bursts and I/O bursts. An I/O-bound job often runs for only a sliver of its quantum, then blocks waiting for the disk or network, surrendering the rest of its slice. When it comes back it must rejoin the end of the queue and wait again, while a CPU-bound job happily consumes its whole quantum every single time. The job that uses the CPU least ends up waiting the most — the opposite of what good throughput wants.
So round robin gives us the right instinct — preempt, take turns, stay responsive — but a single flat queue with one fixed quantum is too blunt for a world full of different jobs with different needs. The fix is not to abandon round robin but to layer it: several queues, different quanta, and a rule that lets the system learn which jobs are interactive and which are CPU hogs by simply watching how they behave. That structure is the multilevel feedback queue, and combined with priorities it is where the next guide picks up.