CS 481: Solutions for Assignment #5

Problem 11.6.
We discussed this one in class. Much of the information is not directly relevant to the problem at hand. Since external fragmentation is defined in the text as the ratio of wasted memory to allocated memory, using the same definition for internal fragmentation immediately leads to a solution. If pages have size x, then the average allocation uses 100/x pages (no need for ceilings or floors: this is an average) and wastes 1/2 page. Thus the internal fragmentation is x/200 and must match the 0.2 of external fragmentation; solving, we get x = 40 Kbytes. We would probably use 32 Kbytes or 64 Kbytes, in order to use a power of 2.

The irelevant information tells us that the total memory size is proportional to (0.7*100+0.3*50)Kbytes, i.e., is 85n Kbytes, with 70n Kbytes allocated and 15n Kbytes free -- n is some proportionality constant. The 20% of external fragmentation is wasting 0.2*70n = 14n Kbytes, leaving 1n Kbytes of usable free space.

Problem 11.18.
If the disk can transfer 2 Mbytes/s and the job can be transferred in one continuous stream once the beginning sector has been reached, it will take 0.3/2 = 0.15 s, or 150 ms, to transfer the job. This is a lot longer than what is needed to get to access the sector -- the transfer rate is low by today's standards; an ultra-wide SCCSI device has a 40 Mbytes/s transfer rate, which would cut the transfer time to 7.5ms, or less than the acess time. Swapping a job out requires one access and one transfer; swapping a job in requires another similar sequence; thus the total time will 2*(10+150) ms, or 320 ms.

Can we improve that? Well, these are small jobs; on a typical disk or 1-4 Gbytes, they would take less than a full track. On the other hand, today's disks spin quite a bit faster than the 150 ms -- typically, around 10**4 rotations/s. So the transfer is not really continuous: there is no time to move all the data read through one spin out to the computer -- instead, we will have several hundred rotations while the transfer takes place. In other words, the bottleneck is not the disk, but the transfer line. This could allow us to be clever--there is time to do different things on the disk while the data makes its slow way across the line from the controller to the memory. In particular, if we have two directional lines (in and out) between the controller and memory, we can run both swaps together, alternating between the two on a block (page) by block basis. None of this was asked for in the problem, but the performance is so miserable that it is worth reflecting on what causes the trouble and how things could be improved.

Of course, in practice, we never swap a whole job in or a whole job out. A paging system need only swap in a few pages (a working set) and much the same for swapping out, especially if the paging system runs a daemon to clean pages periodically. Clean pages (including all read-only pages) never need swapping out. Computing swapping times is now too difficult without a lot of assumptions, but we can conclude that paging would drastically improve the numbers given above.

Problem 11.26.
In this system, a job is even shorter -- 200 Kbytes -- and the disk even slower -- only 1Mbyte/s transfer rate. A complete swap, ignoring access time, takes 0.2 s or 200 ms. A job can only run for 0.3s or 300 ms between swaps (300,000 instructions at 1,000,000 instructions per second).

Thus, if we cannot overlap anything, for each 300 ms of job execution, the system will 400 ms swapping one job out and the next one in, for an effective computation rate of 3/7 of ~0.43. If we can overlap on swap with running, we can do better, but the two swaps still have to take place as we switch from one job to the other, so that the interval from the start of one computation to the next must be two swapping times, or 400 ms -- hence we still waste some time, since only 300 ms of these 400 ms are spent computing, for an effective computation rate of 3/4 or 0.75. If we can overlap all three (which requires paging, since we cannot execute a job that is being swapped out as a single block, and which also requires two channels between memory and the disk controller), then this limitation disappears: we start swapping in some pages, activate the job being swapped in, continue swapping in pages as we also finish swapping out the old job; as the computation progress, we start swapping out no-longer-needed pages of the current job and initiate swapping in some pages of the next job, to start a new cycle. The effective computation rate is 1 -- the bottleneck is the CPU.

Now, if we speed up the processor by a factor of two, we just make the numbers in the first two cases look worse: without overlap, we compute 150 ms for 400 ms of time wasted swapping, for an effective ratio of 15/55 or 0.27; with single overlap, we compute 150 ms during the 400 ms needed to swap the two jobs, for an effective ratio of 15/40 or 0.375. The third case is a bit trickier, but note that we cannot possibly move from one job to another in less than 200 ms (the swap time for one job): we can only move jobs out at that rate or move them in at that rate. But we spend only 150 ms to run the job, so the effective ratio fall to 15/20 or 0.75 -- the bottleneck is now the disk. We did gain throughput in the first and third case (from one job per 700 ms up to one per 550 ms in the first case and from one per 300 ms up to one per 200 ms in the third case), but did not gain anything at all in the second case (still one job completed every 400 ms).

On the other hand, if we speed up the disk, the first case improves drastically: for each 300 ms spent computing, we now only wasted 200 ms in swapping, for a ratio of 3/5 or 0.6; the throughput improves to one job per 500 ms. The second case also improves: the bottleneck becomes the 300 ms needed to compute, since swapping can now be done in 2*100ms; so the effective computation rate is 1 and the throughput up to one job per 300 ms. The third case was already CPU bound and remains so; increasing disk speed does not change anything: we still take 300 ms per job, although the disk system now would allow us to move from one job to another every 100 ms.

So we should improve the disk in the second case and the CPU in the third case; in the first case, both improvements help throughput, but disk improves both throughput and computation rate.