| Previous | Table of Contents | Next |
Input/output (I/O) is the Rodney Dangerfield of computer systems; it gets no respect. The processor almost always is the darling of any computer system, so the I/O system is relegated to second-class citizenship. Consider megahertz, the measure most widely used to describe computer performance. Processor designers today seem more interested in designing computers with high megahertz ratings than in the other aspects of the total design. Megahertz may be a measure of how fast a processor spins, but it almost never says much about the performance of the total computer system.
In Chapter 2, we saw how the memory subsystem plays an important role in the overall performance of a computer system. I/O plays an equally important role. The I/O subsystem determines the response time and the throughput for most computers. These are the measures most computer buyers care about, even if processor designers do not.
We are rapidly approaching a time when machines from low-end PCs to the fastest supercomputers will be built from the same basic microprocessor technology, and I/O capabilities may be the only feature that distinguishes one machine from another. So it can be argued, on the other hand, that I/O is the most important component in the system. After all, without I/O, that high-performance processor would just sit there and chuckle to itself.
What is the I/O system and why is it so important? Loosely defined, the I/O system comprises the group of components, both hardware and software, that are responsible for processing input from and delivering output to a variety of devices attached to the system. Whenever you require any system resource — when you read from or write to a file, when you request some instructions of a program to execute, when you require any other system object, when you create or destroy an object, when you communicate with some device — and that resource has not already been brought into memory, the computer must go through the I/O system to retrieve or store, create or destroy the resource. As I said, without the I/O system not much would get done in the computer.
The AS/400 never has had industry-leading processor performance. Yet it handily holds its own against other systems. More often than not, it can put another system with a higher performance processor to shame on almost any real-world benchmark. In fact, the AS/400’s “secret weapon” to accomplish this feat is one of the most sophisticated and powerful I/O systems in the industry.
Simplistically, there are two ways to design an I/O system. One is to assume the processor can do everything, and to let it handle all computing and I/O. In one instant, the processor is busy executing instructions for the various user and operating-system programs. In the next instant, the processor is executing instructions that control the computer’s I/O. This type of design came from the PC and the Unix workstation world where I/O was fairly simple. The problem with this approach is that the processor can do only one thing at a time. A heavy I/O workload can have a direct impact on other computing in the system.
The other approach is to have separate processors dedicated to I/O processing. This allows multiple I/O operations to execute in parallel with little or no performance impact on the main processors. The AS/400 uses this multiple-I/O processor (IOP) approach.
Many people have a vague idea about the way AS/400 I/O is structured; but beyond the fact that there are multiple IOPs, few people understand how it works. In this chapter, we look at some aspects of the AS/400’s I/O system that are familiar, as well as many that are not so familiar. We start our discussion by looking at how the AS/400 I/O system is evolving and why these changes are occurring.
The I/O system within the AS/400 is in a state of transition. In the beginning, the AS/400 I/O devices were connected to the system only through IOPs attached to a proprietary I/O bus, called the SPD bus.1 This particular bus has served us well over the years and is still supported in the AS/400e series. We are, however, in the process of moving to other I/O buses for the e-series.
1The SPD bus came out of the failed Fort Knox project, which I describe in the Appendix. The SPD bus is named after the System Products Division (SPD), the division within IBM that tried to create Fort Knox.
Being a proprietary design, the SPD bus has one major drawback: There is only limited development for this bus outside of IBM. Customers cannot write programs or device drivers that directly address buses, IOPs, or I/O devices except through fairly restrictive OS/400 facilities. There have been a few examples of outside development for the SPD bus, most notably for fax and wireless LAN IOPs, but for the most part all support comes from IBM. We are in the process of changing that through the use of industry-standard I/O interfaces that will provide for a greater variety of devices at lower costs.
Before we get too far, let’s look at some basic concepts so we can understand how the various pieces of the I/O system fit together. I/O devices are attached to a computer via an I/O bus. A bus is simply an electrical pathway between two hardware components. Often, there are multiple buses between the device and the computer. Typically, an I/O bus will have anywhere from 20 to 100 lines, some of which are used to transfer data and some of which are used to pass control information to and from the I/O device. The SPD bus, for example, has 32 lines (where each line corresponds to a bit) for transferring data, 8 lines for transferring command and status information, 8 lines for origin/destination identification, and several control lines. We can think of these lines as individual wires, but when we’re dealing with optical serial buses, where only a few high-speed fiber-optic lines are used and the electrical signals are sent across the lines as strings of bits, the individual wire analogy breaks down.
| Previous | Table of Contents | Next |