Skip to main content

Turnaround, Response Time, Throughput, and Fairness

What This Concept Is​

Four common scheduler metrics, each measuring a different thing:

  • Turnaround time = completion - arrival. How long from when a job appeared until it was done.
  • Waiting time = turnaround − burst. How long the job spent not running.
  • Response time = first_dispatch - arrival. How long from arrival to first slice.
  • Throughput = jobs completed per unit time. System-level rate.
  • Fairness = how equally resources are distributed. Often quantified as Jain's fairness index:
J = (sum x_i)^2 / (n * sum x_i^2)

where x_i is process i's share of CPU. J = 1 is perfectly fair; J = 1/n is one process getting everything.

Why It Matters Here​

Real schedulers must choose. You cannot simultaneously:

  • minimize average turnaround (favors SJF, unfair to long jobs)
  • minimize response time (favors small quanta, hurts throughput via overhead)
  • maximize throughput (favors long quanta and batch ordering, hurts response)
  • maximize fairness (forbids any "burst type" preference)

If a benchmark looks great it is usually picking one metric and hiding another. Naming which metric you optimize is the first honest step.

Concrete Example​

Two workloads, same scheduler (RR, q=2):

Workload A (three equal jobs, arrive at 0):

JobBurst
J16
J26
J36

Gantt: J1 J2 J3 J1 J2 J3 J1 J2 J3. All finish at t=18.

  • Turnaround: 18, 18, 18 -> avg 18
  • Response: 0, 2, 4 -> avg 2
  • Throughput: 3 / 18 = 0.167 jobs/unit
  • Fairness: J = 1.0

Workload B (three unequal jobs):

JobBurst
J12
J26
J310

RR Gantt with q=2: J1(0-2) J2(2-4) J3(4-6) J2(6-8) J3(8-10) J2(10-12) J3(12-14) J3(14-16) J3(16-18).

  • Turnaround: J1=2, J2=12, J3=18 -> avg 10.67
  • Response: 0, 2, 4 -> avg 2
  • SJF on the same set -> turnaround avg (2+8+18)/3 = 9.33

So SJF beats RR on average turnaround by 1.3 units, but RR's response time (2) is much better than SJF's (0, 2, 8 -> avg 3.33).

No single policy wins all four metrics.

Common Confusion / Misconception​

"Low average is good." Averages hide the tail. A scheduler with mean turnaround 10 and max 500 can be worse in practice than mean 20 and max 50, because a few very slow jobs disproportionately hurt user experience, SLA compliance, and connection timeouts. Always look at the distribution, not only the mean. The 99th percentile ("p99") is a common production metric for exactly this reason.

"Fairness always helps users." Perfectly fair CPU sharing can be disastrous if one user submits a thousand background jobs while another has one interactive shell. Linux addresses this with group fairness (cgroups) -- fair between groups, not between individual tasks.

How To Use It​

Before picking or criticizing a scheduler:

  1. Name the metric you actually care about (interactive response? batch throughput? SLA p99 turnaround?).
  2. Pick a workload model (uniform jobs? heavy-tailed bursts? mixed I/O + CPU?).
  3. Predict which policy does best on that metric + workload using hand analysis.
  4. Only then run the benchmark.

If you skipped to step 4 you cannot interpret the numbers.

Check Yourself​

  1. Give a workload where minimizing average turnaround makes tail (p99) turnaround worse.
  2. Why does lowering response time usually hurt throughput?
  3. What would a scheduler with Jain's fairness = 0.5 on two identical jobs be doing wrong?

Mini Drill or Application​

Workload:

JobArrivalBurst
P108
P201
P301
P401

For FCFS, SJF, and RR (q=2):

  1. Compute average turnaround, average response, and throughput.
  2. Compute Jain's fairness index over CPU time received after t = 5.
  3. Pick the policy you would recommend for an interactive terminal multiplexer. Justify in one sentence.

Read This Only If Stuck​