Can we move data from a scanner that produces data at 400 KB/sec to an EIDE disk that consumes data at 16.7 MB/sec via an ISA bus that can transfer data at 16.7 MB/sec at full speed?First, we must define full speed! Let's define it in terms of the slowest source or destination in the system. In this case, then, the system will be working at full speed if data from the scanner is consumed at 400 KB/sec.
Nothing here said how the scanner is connected to the computer! If it's connected via the ISA bus (for example, using a parallel port interface that is accessed via the ISA bus) then the scanner and disk would need an aggregate bus capacity of 17.1 MB/sec in order to run at full speed. The bus only has 16.7 MB/sec of capacity, so we cannot run at full speed.
If we manage to find a system that allows the data to be read from the scanner without use of the ISA bus, we might be able to run at full speed. Consider, for example, buying a scanner that uses a fire-wire connection. We know that the fire-wire I/O port must not use the ISA bus because it can run at 50 MB/sec.
At 10 nsec per word, it takes 340 nsec to save 32 registers plus PC and PSW, and therefore, the minimum interrupt service time is twice this, or 680 nsec. 1/.000000680 is about 1.5 million; therefore, we can handle about 1.5 million interrupts per second if the interrupt service routines do nothing at all.
There are 50 times 80 or 4000 characters per page, and 6 pages per minute, or 24000 characters per page. This is 400 characters per second or 2500 microseconds per character. We're told that the interrupt service routine takes 50 microseconds, so interrupt service while running the printer at full speed will use only 1/50 of the entire available CPU resources.Therefore, there is no reason to use complex DMA I/O hardware to drive this printer! Character at a time interrupt driven I/O is more than fast enough. (If we're using the machine from problem 5 on page 374, I suspect that the interrupt service routine is very badly written! It's extremely rare to find character sequential interrupt-driven output that takes more than a few tens of instructions per interrupt!)
If a disk copies between disk and RAM with no internal buffering, we must still consider the software overhead of the interrupt service routine and the computations required to prepare the I/O interface for the next sector's worth of data. As a result, it still may not be possible to read consecutive sectors without interleaving.
Harry Hacker's program was a single-threaded UNIX application. The UNIX programmer's interface does not allow a thread to give one read request to the disk scheduler until the previous read request had been processed.The test program Harry must write to find out if the salesman was lying would have multiple processes, each of which reads multiple blocks at random. Comparing the run-time of the single thread reading 10,000 random blocks with the run-time of 10 parallel threads reading 1000 random blocks each would be a good test of the salesman's claims.
RAID level 1 would justify a total of only 8 terabytes and it allows stable storage. RAID level 4 gives the option of fast bit-parallel I/O without needing to spin the disks in perfect synchronization, but we can't get stable storage semantics out of it. If we implement stable storage semantics in our RAID, using two RAID level 4 banks of 5 terabytes each (4 bits in parallel for fast read-write access, plus parity), we can justify 10 terabytes of disk. Perhaps the 11th terabyte represents hot spares, so that, in the event of drive failure, the system can immediately reconstruct a fully redundant view of the data off-line without blocking ongoing I/O activity.Alternately, consider the possibility that we start with a basic implementation of stable storage, requiring 8 terabytes to implement 4 terabytes of memory. Now, assume that we use RAID level 2 with 4-bit parallel access. This requires 3 bits of parity for 4-bit nibble, but we need not duplicate this for both halves of the stable storage, since under normal circumstances, they are identical. If we use this approach, our 4 gigabyte stable RAID will take exactly 11 gigabytes of physical disk!
Both of these answers are pure speculation they do justify the kinds of numbers the people at Deere used.
Part b) Where does the disk scheduling function fit in a system that uses RAID technology? Does this follow from the statement "a RAID should look like a SLED to the operating system, but have better performance ..." (page 303). If not, why not?
Since each disk drive in a RAID has an independent access arm, and since the peak performance of a RAID system can only be achieved if seek operations on one disk are overlapped with I/O activity on others, we really need the host system to request very large block transfers instead of requesting one sector at a time, and we need the disk scheduling function to be placed inside the RAID's controller.If we do not do this, the RAID must be scheduled as if it was an array of independent disk drives connected to the host through a shared controller. In this case, the host needs to maintain a separate disk request queue for each drive, and a RAID ends up being no different from the "disk farms" of the 1960's.
However, if we actually use RAID level 2 or 3, with parallel access to the rotationally synchronized disks, we the scheduling function can be on the host machine, since all heads will always move in unison.