A Report on I2O and NGIO – Background
Three years ago, Intel proposed I2O as a standard for bringing the equivalent of mainframe I/O processing to servers. Advertised as the functional equivalent of Channel I/O Processors used since the seventies in mainframes, I2O promised to be just the ticket to block escalating I/O interrupts and I/O context switches from disrupting instruction sequences in super-pipelined CPUs. I2O promised to rid CPUs from unnecessary I/O processing by off-loading much of it onto specialized, I/O processors. At the time, Intel clearly worried that traditional architecture would never measure up to the demanding requirements of mission-critical enterprise computing, at least not without disentangling I/O processing from the CPU. In those days, everyone expected a killer 3-D application like Virtual Reality to fuel demand for faster, super-pipelined microprocessors.
The standard Intel proposed goes beyond increasing I/O efficiency and improving availability of the CPU, it brings extremely rich functionality and abstraction to bear on some of the most vexing problems in the computing industry. I2O all but eliminates the massive inefficiencies and obstacles to attaching I/O devices due to the industry's arcane dependence on device drivers. Peripheral manufacturers must develop, test, document, package, inventory, deploy, support, debug conflicts with other device drivers, and manage updates for device drivers which vary by connection (SCSI, system bus adapter, serial, PC Card, IR, etc.) and by operating system (Windows 95/98, NT, Apple, Linux, OS/2, Netware, SCO, Solaris, other Unix flavors, AS/400 and others). I2O reduces the driver requirement to the preparation of a single Hardware Device Module (HDM) for attachment to any I2O-compliant operating system. This single driver broadens the market for any peripheral device to the totality of all operating systems providing Operating System Modules (OSM) for the product class of the device.
Full-featured I2O is capable of much more than just passing data between an I/O device and the system data bus, or equivalents, using a platform-independent messaging protocol. The standard includes an Intermediate Service Module (ISM) that opens the door to unlimited transformation of data. Protocols can be implemented flexibly in software housed in the ISM. Encryption, compression, transformation, monitoring, timing (for example with live video delivering 30 frames per second, no more, no less) and ultimately smart packets, that are executable programs wrapped around data, can be implemented using ISM's and broadly disseminated across a vast network.
I2O is a software standard and is not inherently dependent on any particular hardware architecture. I2O applies equally well to any adequate data bus or, as with NGIO, to bus-less architectures. The reason I2O is so important and will endure as a standard is because it transcends temporal aspects of computer architecture, choosing to focus instead of the appropriate level of abstraction distinguishing I/O processing from applications. Only when I2O is to be implemented in a particular computer setting do the characteristics of the specific architecture matter. To date, the target architecture has been based on the PCI bus.
For block storage devices, today that market includes Windows NT, Netware, OS/2 and SCO Unix. Linux will be available as soon as possible, and Solaris either is available now or will be soon. High-end embedded systems developers (e.g. systems with a PCI or CompactPCI system bus) are attracted to I2O because it enables them to finesse one of the biggest problems they face: lack of drivers for mainstream devices. Thus, VxWorks, pSOS and potentially other RTOSs should be added to the list of operating systems supporting I2O.
While the computer industry generally was smitten by the elegant I2O abstraction for interfacing peripherals to computers, some groups inside Intel began to have concerns that I2O did not provide a complete solution for enterprise computing. The explosion of eCommerce on the internet served to frame the dominant context for enterprise computing as far as the eye can see: huge data flows in the form of browser bitmaps and multi-media applications, like streaming audio and video, integrated with distributed database transaction processing. None of this is computationally intensive, and serves to underscore the growing importance of I/O processing in the modern enterprise. Intel realized a while back that enterprise computing soon must encounter limits to benefits derived from centralized microprocessors increasing at the speed of Moore's Law. In time, the PCI bus, even with extensions like PCI-X, will begin to starve faster and faster CPU's.
I2O can mitigate some dire consequences of exploding I/O, and perhaps delay the day of reckoning, but ultimately the central role played by the PCI bus in Intel architecture unduly restricts enterprise computing. Intel visualizes the future enterprise consisting of clusters of tightly integrated servers all connected at high speeds over relative long distances to tens of thousands of storage and web-server subsystems. Enterprise computing must scale up by an additional three orders of magnitude, connect at much faster speeds, and achieve reliability beyond anything possible with current architecture.
A new group was formed in Intel to redesign the entire I/O architecture underpinning the Intel Architecture. Dubbed Next Generation Input/Output (NGIO), they soon came up with a radical design that, once again, was likened to mainframe Channel I/O Processors. Only this time, the design focused on channel architecture rather than off-loading I/O. A channel is a virtual link that connects an I/O device to a host adapter with a direct bridge to local processor memory. By using fiber-optics and fast, matrix switches, the connection can be made much faster over longer distances than possible with traditional cabling. While the channel itself may be multiplexed at the physical level, with proper design, each virtual channel is effectively isolated from others, eliminating any possibility of I/O conflicts of the sort that occur when a system bus is shared by multiple I/O devices. Further, the NGIO design lends itself to almost infinite scaling. Channels are the equivalent of slots on a PCI bus and are limited only by the size of the index address, currently supporting upwards of 65,000 in number. Fast, robust and scalable, fiber-channel is the perfect architecture to feed hungry processors.
Needless to say the surprise announcement of NGIO last fall shook the computer industry. IBM and Compaq reacted by initiating Future I/O, a competitive channel I/O architecture yet to be specified. The I2O movement, which should have been hopping about then, because Windows NT just produced a production OSM for block storage devices, was put in a state of shock. Messages coming from Intel about NGIO and its relationship to I2O were confusing. Compaq and IBM intensified the confusion by challenging the timing for NGIO, suggesting its dependence on I2O IOP's renders the new I/O architecture impractical. Intel has responded by de-emphasizing the use of i960Rx processors for implementing I2O, arguing instead on the efficacy of specialized I2O cores embedded in silicon.
No wonder the I2O campaign appeared to have slowed noticeably during 1998. A confusing new I/O architecture was proposed, and in the face of the Compaq-IBM challenge, Intel has been put on the defensive about full-featured I2O. But don't be fooled by appearances.
Allen
I2ONGIOX |
