response time

When you click a button, what you notice is not how long the whole task takes, but how long before something happens — the cursor moves, a spinner appears, the first line of output shows. Response time captures exactly that first-flicker delay: the time from when a request is submitted until the system produces its first response, not its final result.

Precisely, response time is measured from a process becoming ready (or a request being made) to the moment it first starts producing output or first gets the CPU — it does not wait for the job to finish. This is why it differs from turnaround time: a job can start responding quickly (low response time) yet take a long time to fully complete (high turnaround), and that is often exactly what an interactive user wants. Round-robin scheduling, by giving every ready process a quick turn, deliberately optimizes response time.

Why it matters: for interactive and time-sharing systems, response time is the criterion users feel most. A policy that finishes batch jobs efficiently but makes the screen freeze for half a second feels broken, even if its throughput is excellent. The tension is real — making response time tiny means switching often, which costs context-switch overhead and can hurt throughput — so designers pick a time quantum that keeps response snappy without thrashing on switches.