Translate

Friday, January 4, 2013

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.           

No comments:

Post a Comment