What Metrics Are Used to Evaluate a CPU Scheduling Algorithm?
Learn the five CPU scheduling metrics — utilization, throughput, turnaround, waiting, response time — with an interview-ready example.
Expected Interview Answer
CPU scheduling algorithms are compared using five core metrics — CPU utilization, throughput, turnaround time, waiting time, and response time — and no single algorithm maximizes all of them at once, so the right choice depends on whether the workload is batch, interactive, or real-time.
CPU utilization is the percentage of time the CPU is actively executing work rather than sitting idle, and schedulers generally aim to keep it high. Throughput measures how many processes complete per unit time, which matters most for batch systems processing many jobs. Turnaround time is the total time from a process’s submission to its completion, including waiting, execution, and I/O, and is what a batch user cares about most. Waiting time is the total time a process spends sitting in the ready queue rather than running or doing I/O, isolating the scheduler’s own contribution to delay. Response time, most relevant to interactive systems, is the time from submission until the first response is produced, not until full completion — a system can have long turnaround time but still feel responsive if response time is low. These metrics often trade off against each other: minimizing average waiting time (like Shortest-Job-First does) can starve long jobs, while maximizing fairness (like Round Robin) can raise average turnaround time due to more frequent switching overhead.
- Gives a concrete vocabulary for comparing scheduling algorithms
- Clarifies that CPU utilization alone is a misleading single metric
- Distinguishes turnaround time from response time for interactive systems
- Explains why algorithm choice depends on workload type
AI Mentor Explanation
CPU utilization is like how much of a training session the bowling machine actually spends firing balls versus sitting idle between batters — high utilization means little idle machine time. Turnaround time is how long from a player joining the queue to finishing their full net session, while response time is only how long until their very first ball is delivered. A scheduler favoring quick first-ball delivery for everyone can still leave some players waiting long overall, exactly the trade-off between response time and turnaround time.
Step-by-Step Explanation
Step 1
Track submission and completion
Record the arrival time and completion time of each process to compute turnaround time.
Step 2
Track ready-queue time
Sum the time each process spends only in the ready queue (not running, not blocked) to compute waiting time.
Step 3
Track first response
Record the time from submission to the first CPU burst actually starting, to compute response time.
Step 4
Aggregate system-wide
Compute CPU utilization as busy time over total time, and throughput as completed processes per unit time, across the whole run.
What Interviewer Expects
- Naming all five core metrics: utilization, throughput, turnaround, waiting, response
- Correctly distinguishing turnaround time from response time
- Explaining that no single algorithm optimizes every metric simultaneously
- Connecting metric priorities to workload type (batch vs interactive)
Common Mistakes
- Treating turnaround time and response time as the same thing
- Assuming higher CPU utilization always means a better scheduler
- Forgetting throughput as a distinct batch-oriented metric
- Not acknowledging the trade-offs between fairness and average wait time
Best Answer (HR Friendly)
“When comparing scheduling algorithms, we look at how busy the CPU stays, how many tasks finish per unit time, how long tasks take overall from start to finish, how long they sit waiting their turn, and — especially for anything interactive — how quickly they get their very first response. No one algorithm wins on every one of these at once, so the right choice depends on whether you are optimizing for batch throughput or for a snappy, interactive feel.”
Code Example
struct run_stats {
int arrival_time;
int first_run_time; /* when it first got the CPU */
int completion_time;
int burst_time; /* actual CPU time used */
};
void compute_metrics(struct run_stats *s) {
int turnaround = s->completion_time - s->arrival_time;
int response = s->first_run_time - s->arrival_time;
int waiting = turnaround - s->burst_time; /* time NOT running or new */
printf("turnaround=%d response=%d waiting=%d\n",
turnaround, response, waiting);
}Follow-up Questions
- Why can a scheduler have low response time but high turnaround time?
- How does Shortest-Job-First affect average waiting time versus fairness?
- Why is throughput more relevant to batch systems than interactive ones?
- How would you measure CPU utilization on a real running system?
MCQ Practice
1. Response time measures?
Response time is specifically the delay before the first output or CPU burst, not full completion.
2. Which metric is most relevant to a batch processing system handling many jobs?
Throughput, the number of jobs completed per unit time, is the primary concern for batch systems.
3. Waiting time specifically measures?
Waiting time isolates the scheduler's own delay contribution by counting only time spent in the ready queue.
Flash Cards
Name the five core CPU scheduling metrics. — CPU utilization, throughput, turnaround time, waiting time, response time.
Turnaround time vs response time? — Turnaround is submission-to-completion; response is submission-to-first-output.
What does waiting time isolate? — Time spent only in the ready queue, excluding running or I/O time.
Why does no algorithm win on every metric? — Metrics trade off — e.g., minimizing average wait can starve long jobs; fairness raises switching overhead.