A New Metric: Response Time

In this lesson, you will be introduced to the metric of response time.

We'll cover the following

Thus, if we knew job lengths, and that jobs only used the CPU, and our only metric was turnaround time, STCF would be a great policy. In fact, for a number of early batch computing systems, these types of scheduling algorithms made some sense. However, the introduction of time-shared machines changed all that. Now users would sit at a terminal and demand interactive performance from the system as well. And thus, a new metric was born: response time.

Defining response time

We define response time as the time from when the job arrives in a system to the first time it is scheduled.Some define it slightly differently, e.g., to also include the time until the job produces some kind of “response”; our definition is the best-case version of this, essentially assuming that the job produces a response instantaneously.

More formally:

TTresponseresponse == TTfirstrunfirstrun −− TTarrivalarrival

For example, if we had the schedule above (with A arriving at time 0, and B and C at time 10), the response time of each job is as follows: 0 for job A, 0 for B, and 10 for C (average: 3.33).

Press + to interact
Response time of each job
Response time of each job

Approaches not sensitive to response time

As you might be thinking, STCF and related disciplines are not particularly good for response time. If three jobs arrive at the same time, for example, the third job has to wait for the previous two jobs to run in their entirety before being scheduled just once. While great for turnaround time, this approach is quite bad for response time and interactivity. Indeed, imagine sitting at a terminal, typing, and having to wait 10 seconds to see a response from the system just because some other job got scheduled in front of yours: not too pleasant.

Thus, we are left with another problem: how can we build a scheduler that is sensitive to response time?

Get hands-on with 1400+ tech skills courses.