| Previous | Table of Contents | Next |
The higher-performance processors for future AS/400 systems are pretty worthless if we can’t feed enough data into the processors to keep them busy. In this section, I look briefly at where we are going with the AS/400 I/O subsystem, even though I have discussed most of this in previous chapters.
In Chapter 10, we saw how the AS/400e series I/O subsystem design is in a state of transition during Version 4. This transition likely will continue beyond the year 2001. IBM’s intention is to provide a structure that can accommodate new I/O technologies very easily — not to achieve some singular new I/O design. Thus, you should view the incorporation of PCI buses and adapters as a step in this direction, rather than the ultimate destination.
We will continue to attach devices to the AS/400 using a variety of interfaces. We have already discussed most of these I/O connections in Chapters 10 and 11, including SPD, PCI, ATM, Ethernet, SCSI, and SSA. We can consider new I/O connections, such as ANSI Fibre Channel, as they are needed. The use of the System Area Network (SAN) will enable most of these new connections.
The SAN, which I have already shown is usually connected as a loop, supports the Scalable Coherent Interface Link (SCIL) protocol and is highly expandable in both throughput and speed. In Chapter 11, I mentioned that we have a parallel fiber-optics SAN connection with 32 fibers running at 500 MHz, which provides a throughput of 1 GB per second (assuming half the fibers are used for the redundant link). Faster versions are also possible. Because this interconnection is based on an IEEE standard and is being used by IBM and other companies in different systems, new attachments also will be forthcoming.
Primarily because of the move to network computing, the speed and the cost of high-bandwidth communications adapters will also continue to improve. The newer communications technologies, such as ATM, fiber optics connections, and satellite, will be far more widespread in the future, enabling the use of even more distributed applications. Wireless communications, both local and wide area, will see major improvements in cost and performance, which in turn will further accelerate the use of mobile computing.
Large storage subsystems are also in our future, and the SAN will be the mechanism that allows the attachment of such subsystems. These subsystems most likely will use the SSA. This serial architecture is optimized for storage applications, and it will be used across IBM systems. Consequently, you can expect to see large standalone arrays of disks, tape, and optical devices that can be attached to and shared by multiple systems.
The current IOPs used in the AS/400 will continue to evolve. New IOPs are all PowerPC microprocessors. Each IOP has its own memory and runs a special-purpose, real-time operating system. Future processors for new IOPs will be either from the standard 32-bit family of PowerPC processors built in Burlington, Vermont, or as we saw earlier in this chapter, IOP processors may exist on the same chip as the main processors.
Because the real-time operating systems running on the current IOPs have been updated many times over the past several years, just as any other operating system has been, different operating-system versions can be running on different IOPs in the same AS/400. The latest version of this operating system running on the PowerPC IOPs is microkernel based to make this software more portable. In the future, because the operating systems do less and less device control, we may be able to use a standard operating system on IOPs. Even today, using PCI technologies, the IOP’s responsibility is to provide the PCI bus interface and to perform higher-level I/O operating-system functions.
Individual disk devices are getting faster, but they are at nowhere near the rate they need to be to keep up with processor technology. Besides, they are mechanical devices, which means increasing their speed is also far more difficult. So rather than just depend on performance improvements in the devices themselves, we need to use them in different configurations.
Several vendors have recently announced the technique of striping data across an array of multiple disks, which they are presenting as a major breakthrough to increase system performance. This striping technique first appeared commercially in the System/38. As we previously saw, a System/38 or an AS/400 application uses several system objects. For performance reasons, IBM decided to distribute the various objects across multiple disks so the objects could be accessed in parallel. The System/38 and the AS/400 have used data striping ever since.
The data-striping technique improves AS/400 system performance when more than one object needs to be read or written. But if we want to improve the performance of a single-record access, this technique does nothing to help. A variation of the data-striping technique that can achieve a performance improvement for individual records is to spin all the disks in the array synchronously. This means that the arms on all disks are always over the same track, and sector 0 on every disk rotates under the head at exactly the same time. This synchronization allows single records to be spread across all the disks in the array, thereby improving the performance for all individual data transfers.
From a system perspective, this array would appear to be a single disk with a single arm, but it has a transfer rate four times that of any single disk in the array. This is analogous to increasing the rotational speed of the disk by a factor of four times — something that may not be physically possible.
To see how this works, imagine we have an array of four disks spinning synchronously. Assuming we have enough device controllers and data paths, we could write parts of a single record to each disk in parallel. One fourth of the total record would be written to the first disk; another fourth of the same record would be written to the second disk; and so on. The entire record could be written to the four disks in one fourth the amount of time it would take to write the record to a single disk. The same time savings occurs when we read the record.
| Previous | Table of Contents | Next |