5.3.2: Disk Arm Scheduling Algorithms

These algorithms are relevant only if there are several I/O requests pending. For many PCs this is not the case. For most commercial applications, I/O is crucial.

1. FCFS (First Come First Served): Simple but has long delays.
2. Pick: Same as FCFS but pick up requests for cylinders that are passed on the way to the next FCFS request
3. SSTF (Shortest Seek Time First): Greedy algorithm. Can starve requests for outer cylinders and almost always favors middle requests.
4. Scan (Look, Elevator): The method used by an old fashioned jukebox (rember ``Happy Days'') and by elevators. The disk arm proceeds in one direction picking up all requests until there are no more requests in this direction at which point it goes back the other direction. This favors requests in the middle, but can't starve any requests.
5. C-Scan (C-look, Circular Scan/Look): Similar to Scan but only service requests when moving in one direction. When going in the other direction, go directly to the furthest away request. This doesn't favor any spot on the disk. Indeed, it treats the cylinders as though they were a clock, i.e. after the highest numbered cylinder comes cylinder 0.
6. N-step Scan: This is what the natural implementation of Scan gives.
   • While the disk is servicing a Scan direction, the controller gathers up new requests and sorts them.
   • At the end of the current sweep, the new list becomes the next sweep.

Minimizing Rotational Latency

Use Scan, which is the same as C-Scan. Why?
Because the disk only rotates in one direction.

Homework: 9, 10.

RAID (Redundant Array of Inexpensive Disks)

Tannenbaum's treatment is not very good.

• This name is from Berkeley.
• IBM changed the name to Redundant Array of Independent Disks
• A simple form is mirroring, where two disks contain the same data.
• Another simple form striping (interleaving) where consecutive blocks are spread across multiple disks. This helps bandwidth but is not redundant so shouldn't be called RAID but it sometimes is.
• One of the normal RAIDs is to have N (say 4) data disks and one parity disk. Data is striped across the data disks and the bitwise parity of these sectors is written in the corresponding sector of the parity disk.
• A variation is to rotate the parity. That is, for some stripes disk 1 has the parity, for others disk 2, etc.
• A serious concern is the small write problem. Writing a sector requires 4 I/O. Read the old data sector, compute the change, read the parity, compute the new parity, write the new parity and the new data sector. Hence one sector I/O became 4, which is 300% overhead.
• Writing a full stripe is not bad. Compute the parity of the N (say 4) data sectors to be written and then write the data sectors and the parity sector. Thus 4 sector I/Os became 5, which is only a 20% penalty and is smaller for larger N, i.e., larger stripes.

5.3.3: Error Handling

Disks error rates have dropped in recent years. Moreover, bad block forwarding is done by the controller (or disk electronic).

5.3.4: Track Caching

Often the disk/controller caches a track, since the seek penalty has already been paid. In fact modern disks have megabyte caches that hold recently read blocks. Since modern disks cheat and don't have the same number of blocks on each track, it is better for the disk electronics to do the caching since it is the only part of the system to know the true geometry.

5.3.5: Ram Disks

• Fairly clear. Organize a region of memory as a set of blocks and pretend it is a disk.
• A problem is that memory is volatile.
• Often used during OS installation, before disk drivers are available (there are many types of disk but memory all memory looks the same so only one ram disk driver is needed).

5.4: Clocks

Also called timers.

5.4.1: Clock Hardware

• Generates an interrupt when timer goes to zero
• Counter reload can be automatic or under software (OS) control.
• If done automatically, the interrupt occurs periodically and thus is perfect for a time of day (TOD) clock (assuming time of day initialized somehow).

5.4.2: Clock Software

1. TOD: Bump a counter each tick (clock interupt). If counter is only 32 bits must worry about overflow so keep two counters: low order and high order.
   
   
2. Time quantum for RR: Decrement a counter at each tick quantum expires when counter is zero. Load this counter when the scheduler runs a process.
   
   
3. Accounting: At each tick, bump a counter in the process table entry for the currently running process.
   
   
4. Alarm system call and system alarms:
   • Users can request an alarm at some future time and the system also needs to do things specific future times (e.g. turn off floppy motor).
   • The conceptually simplist solution is to have one timer for each event. Instead, we simulate many timers with just one.
   • The data structure on the right works well.
   • The time in each list entry is the time after the preceeding entry that this entry's alarm is to ring. The other entry is a pointer to the action to perform.
   • At each tick, decrement next-signal.
   • When next-signal goes to zero. process the first entry on the list and any others following immediately after with a time of zero (which means they are to be simultaneous with this alarm. Then set next-signal to the value in the next alarm
   
   
5. Profiling
   • Want a histogram giving how much time was spent in each 1KB (say) block of code.
   • At each tick check the PC and bump the appropriate counter.
   • At the end of the run can assign the 1K blocks to software modules.
   • If use fine grainularity (say 10B instead of 1KB) get higher accuracy but more memory overhead.

Homework: 12

5.5: Terminals

5.5.1: Terminal Hardware

Quite dated. It is true that modern systems can communicate to a hardwired ascii terminal, but most don't. Serial ports are used, but they are normally connected to modems and then some protocol (SLIP, PPP) is used not just a stream of ascii characters.

5.5.2: Memory-Mapped Terminals

• Less dated. But it still discusses the character not graphics interface.
• Today, the idea is to have the software write into video memory the bits to be put on the screen and then the graphics controller converts these bits to analog signals for the monitor (actually laptop displays and very modern monitors are digital).
• But it is much more complicated than this. The graphics controllers can do a great deal of video themselves (like filling).
• This is a subject that would take many lectures to do well.
• The tannenbaum description of keyboards is, however, correct.
  • At each key press and key release a code is written into the keyboard controller and the computer is interrupted.
  • By remembering which keys have been depressed and not released the software can determine Cntl-A, Shift-B, etc.