12.1.

• advantages: Bugs are less likely to cause an operating system crash. Performance can be improved by utilizing dedicated hardware and hard-coded algorithms. The kernel is simplified by moving algorithms out of it.

• disadvantages: Bugs are harder to fix - a new firmware version or new hardware is needed; improving algorithms likewise require a hardware update rather than just kernel or device driver update. Embedded algorithms could conflict with OS's priorities or with application's use of the device, causing decreased performance. Testing is harder, since the components are autonomous and each device may behave differently.

12.2.

• (a) mouse: Buffering may be needed to record mouse movement during times when higher-priority operations are taking place. Spooling and caching are inappropriate. Interrupt-driven I/O is most appropriate.

• (b) tape drive: Buffering may be needed to manage throughput difference between the tape drive and the source or destination of the I/O. Caching can be used to hold copies of data that resides on the tape, for faster access. Spooling could be used to stage data to the device when multiple users desire to read from or write to it. Interrupt-driven I/O is likely to yield the best performance.

• (c) disk: Buffering can be used to hold data while in transit from user space to the disk, and vice versa. Caching can be used to hold disk-resident data for improved performance. Spooling is not necessary because disks are shared-access devices. Interrupt-driven I/O is always good for devices -- such as disks -- that transfer data at relatively slow rates.

• (d) graphics card: Buffering may be needed to control multiple access and for performance (double-buffering can be used to hold the next screen image while displaying the current one). Caching and spooling are not necessary due to the fast and shared-access nature of the device. Polling and interrupts are only useful for input and for I/O completion detection, neither of which is needed for a memory-mapped device.

12.4.

• Generally, blocking I/O is appropriate when the process will only be waiting for one specific event. Examples include a disk, tape, or keyboard read by an application program.

• Non-blocking I/O is particularly useful when I/O may come from more than one source and the order of the I/O arrivals is not predetermined. Examples include network daemons listening to more than one network socket, window managers that accept mouse movement as well as keyboard input, and I/O-management programs, such as a copy command that copies data between I/O devices. In the last case, the program could optimize its performance by buffering the input and output and using non-blocking I/O to keep both devices fully occupied.

  Non-blocking I/O is also important where real-time or quasi-real-time responses are needed. Examples include the need to track mouse movements in a GUI window and controls over special devices (such as landing gear).

• Blocking I/O is what makes multiprogramming possible (and we know that's good). Also, non-blocking I/O is more complicated for programmers, because of the asynchronous rendezvous that is needed when an I/O occurs. Also, busy waiting is less efficient than interrupt-driven I/O, so the overall system performance would decrease without blocking I/O.

13.2

• FCFS: Order is (125-143)-86-1470-913-1774-948-1509-1022-1750-130
  Total seek distance is 7081 cyls.

• SSTF: Order is (125-143)-130-86-913-948-1022-1470-1509-1750-1774 Total seek distance is 1745 cyls.
  Note that SSTF optimizes for immediate seek time, not total seek time.

• LOOK: Order is (125-143)-913-948-1022-1470-1509-1750-1774-130-86 Total seek distance is 3319 cyls.

• C-LOOK: Order is (125-143)-913-948-1022-1470-1509-1750-1774-86-130 Total seek distance is 3363 cyls.

• N-Step LOOK: Order is (125-143)-913-1470-1774-86-130-948-1022-1509-1750 Total seek distance is 4983 cyls.

• (a) SSTF would give good access for the high-demand cylinders, but could result in starvation for other requests if the rate of requests is high. FCFS would be fair, but could result in poor performance if references to the high-demand cylinders were interspersed with references to cylinders far away. LOOK and C-LOOK would be good performers, but again could cause starvation if the rate of requests is very high. N-Step LOOK or N-Step C-LOOK would have the performance advantages of LOOK/C-LOOK and also avoid the possibility of starvation.

• (b) One suggestion would be to use multiple queues, just as we did in multiple-queue CPU scheduling. One queue would handle the high-demand cylinders only; if a limit is placed on how many of those are serviced before servicing the same number from the other queue, starvation would not be a problem. Each queue could be ordered in LOOK or C-LOOK order to maximize performance while that queue's requests are being processed.

• (c) Locate the FAT or inodes in cache to maximize the performance of lookups. Another possibility is to use the FAT/inodes to implement the equivalent of the mapped disk space allocation we discussed as part of file systems. That is, while the entries in the FAT/inodes would reflect the logical ordering of blocks within a file, the actual data could be stored anywhere on disk. Thus, it would be possible to distribute the actual data blocks in order to maximize performance.

13.16.

• (a) Using the simplest methods, a drive would fail approximately every month. That is, 1 of the 1000 drives would fail each 750,000 hrs/failure * 1/1000 drives = 750 hrs/drive-failure = approx. 31 days.

• (b) MTBF for 20-year-olds can be approximated as:

  	MTBF = 24 hrs/day * 365 days/yr
  	       ------------------------
  	           1 / 1000 people
  

  so MTBF=8760000 person-hrs = 1000 person-yrs. Note that this only makes sense because the MTBF drops for each year beyond 20 that an adult continues living. A 20-year-old can't really expect to live that long.

• (c)This can be estimated as

  	   1M hours/failure
  	   ----------------
  	     24 hrs/day
  	----------------------
  	    365 days/yr
  

  or approximately 114 years.

15.4.

• (a) Multiaccess bus LAN. That way, computers could be added or removed from the network (important if we assume that not all students will have them) without requiring network reconfiguration.

• (b) Tree-structured or hierarchical LAN. Each building could be a sub-tree (or multiple ones, if there are multiple departments within a building). That way, if one department or building were cut off from the others, the rest of campus could still function.

• (c) Double-link ring WAN supporting LANs (which could be a mix of configurations), or multiaccess bus WAN as a trunk-line supporting heterogeneous LANs. The ring would be more costly, but would provide better reliability.

• (d) Multiaccess bus WAN supporting heterogeneous LANs. At this scale, a double-link ring would be much too costly. The problem of reliability might be solved by having multiple multiaccess bus trunk-lines, some of lesser capacity that would primarily serve as backups in case of network congestion or failures.

15.6. Faster systems may be able to send out more packets in a shorter amount of time. The network would then have more packets traveling on it, resulting in more collisions, and therefore less throughput relative to the number of packets being sent.

More networks can be used, with fewer systems per network, to reduce the number of collisions.