I/O performance measures and Designing I/O

I/O performance has measures that have no counterparts in CPU design. One of these is diversity: Which I/O devices can connect to the computer system? An- other is capacity: How many I/O devices can connect to a computer system? In addition to these unique measures, the traditional measures of performance, namely response time and throughput, also apply to I/O. (I/O throughput is some- times called I/O bandwidth, and response time is sometimes called latency.) Another measure of I/O performance is the interference of I/O with CPU execution. Transferring data may interfere with the execution of another process. There is also overhead due to handling I/O interrupts. Our concern here is how much longer a process will take because of I/O for another process. Throughput versus Response Time  An interaction, or  transaction, with a computer is divided into three parts: 1. Entry time—The time for the user to enter the command. The graphics system in Figure 7.26 required 0.25 seconds on average to enter a command versus 4.0 seconds for the keyboard system. 2. System response time—The time between when the user enters the command and the complete response is displayed. 3. Think time—The time from the reception of the response until the user begins to enter the next command. The sum of these three parts is called the transaction time. Several studies report that user productivity is inversely proportional to transaction time;  transactions per hour are a measure of the work completed per hour by the user. Whether these results are explained as a better match to the human attention Designing an I/O system. The art of I/O system design is to find a design that meets goals for cost, depend- ability, and variety of devices while avoiding bottlenecks in I/O performance and dependability. Avoiding bottlenecks means that components must be balanced between main memory and the I/O device, because performance and dependabil- ity—and hence effective cost-performance or cost-dependability—can only be as good as the weakest link in the I/O chain. The architect must also plan for expan- sion so that customers can tailor the I/O to their applications. This expansibility, both in numbers and types of I/O devices, has its costs in longer I/O buses and networks, larger power supplies to support I/O devices, and larger cabinets. In designing an I/O system, we analyze performance, cost, capacity, and availability using varying I/O connection schemes and different numbers of I/O devices of each type. Here is one series of steps to follow in designing an I/O sys- tem. The answers for each step may be dictated by market requirements or sim- ply by cost, performance, and availability goals. 1. List the different types of I/O devices to be connected to the machine, or list the standard buses and networks that the machine will support. 2. List the physical requirements for each I/O device. Requirements include size, power, connectors, bus slots, expansion cabinets, and so on. 3. List the cost of each I/O device, including the portion of cost of any controller needed for this device. 4. List the reliability of each I/O device. 5. Record the processor resource demands of each I/O device. This list should include Clock cycles for instructions used to initiate an I/O, to support operation             of an I/O device (such as handling interrupts), and to complete I/O Processor clock stalls due to waiting for I/O to finish using the memory,             bus, or cache Processor clock cycles to recover from an I/O activity 6. List the memory and I/O bus resource demands of each I/O device. Even when the processor is not using memory, the bandwidth of main memory and the I/O connection is limited. 7. The final step is assessing the performance and availability of the different ways to organize these I/O devices. When you can afford it, try to avoid single points of failure. Performance can only be properly evaluated with simulation, although it may be estimated using queuing theory. Reliability can be calcu- lated assuming I/O devices fail independently and that the times to failure are exponentially distributed. Availability can be computed from reliability by esti- mating MTTF for the devices, taking into account the time from failure to repair.