CS 481: Assignment #1

Assume you have a dial that allows you to set the length of the time slice in a simple, time-shared operating system. Further assume that processes in the runnable queue are handled on a first-come, first-served basis.

Describe as accurately as possible what you would observe as you used the dial to try possible settings of the slice length, from a minimum of one CPU cycle to a maximum of infinity. Points of interest along the way might include (in no particular order): (i) the context-switching time for an interrupt (saving and restoring registers); (ii) the average CPU burst (continuous use of the CPU without resource request or release) of a process; (iii) the average time between external interrupts; (iv) the average time from resource request to resource acquisition.

Where would you set your dial if your system was to run a small number of large, CPU-intensive jobs? if it was to serve a large student population? if it was to be used in air-traffic control? Discuss each choice (why did you make the choice? is the result any good or would you have to modify other mechanisms? etc.).

The most common mistake was to assume that the quantities given in the first part of the question were quantum-dependent variables to be analyzed as such. They were intended as (more or less) constant values used in calibrating the dial -- "points of interest along the way" as you tried possible settings from one CPU cycle to infinity.

So, let us consider this dial and what we might observe. (How to observe it and exactly what we might actually be able to measure is a harder question.) If the dial is at the minimum (1 CPU cycle), then the machine will slow to a crawl, because most of the CPU cycles will be devoted to context switching. (We would expect a context switch to take a few hundred cycles at least, so we would have an overhead of over 99%!)\ \ The system is extremely fair, but who cares!

Until the dial reaches at least the context switch time, the system will remain extremely inefficient. By the time we have set the quantum to a small multiple (say 3 to 10) of the context switch time, the system starts running reasonably. (At 3 times the context switch time, we have about 25% overhead; at 10 times, overhead does not exceed 10%.) The system divides its time quickly between tasks in the runnable queue, so a job goes round the queue quickly, so that lack of priorities does not matter too much---whether the queue is managed FIFO or otherwise is almost irrelevant. Because the quantum is very small, short jobs are favored---we get good response time and good interactive behavior. For CPU-intensive jobs, the system remains inefficient, since we will add to the I/O requests of these jobs a lot of pre-emptions based on the time slice interrupt.

Nearly optimal efficiency is achieved with a quantum set slightly above the average CPU burst. In that case, in the absence of external interrupts, a job leaves the CPU most often of its own will (resource request) rather than through preemption. The number of context switches is thus further minimized and reduced to nearly its lower bound, the number of resource requests. If the average CPU burst is high, response time will be poor, but should not matter too much.

Further increases of the quantum will move the system closer and closer to pure FCFS (no timer at all): jobs will leave the CPU only under external interrupts (I/O, etc.) or because they request a resource. Depending on the job mix, this could be good (just a few long, CPU-intensive jobs) or disastrous (a single CPU-bound job can delay execution of everything else as long as it does not get interrupted). At infinity, we have true FCFS---there is no time-slice interrupt left.

In the second part of the question, the most common mistake was to "ice the cake" by adding priorities or such. The question was whether or not setting the dial to some value or other would help improve the system. For a system with a few large, CPU-intensive jobs, the assumption is that response time is irrelevant and turnaround time not that high in the list either. What matters most is finishing all of the jobs and thus, because they are CPU-intensive, getting optimal use of the CPU. For that, a very long quantum is best, something well above the average CPU burst (although that itself would be quite long). For a system supporting a student population, response time is the main objective, but one should also keep in mind the heterogeneity of the system---all sorts of jobs are being run. A small quantum, perhaps 10 times the context switch, will give excellent response time, but may be too extreme for heavy computational users; much larger values for the quantum will create response time problems when a lot of users are logged in, though, at least in presence of a diverse mix of users. So, we cannot get a great solution (which would require multilevel queues), but can do OK with a small quantum. For the real-time problem, the time slice is the wrong parameter; giving short slices ensures that an interrupt handler cannot finish its task in one round and will have to go through the whole queue again -- potentially much too slow; and giving a long slice enables a non-critical process to hog the CPU. There is no good setting with no other information; the solution lies in priority assignments more than in size assignments.