A Report on I2O and NGIO – The Future
Our job is to assess what the future holds for I2O and NGIO, taking into account the market position of proponents as well as competitive technology. Here are the facts:
(1) I2O is production-ready and is available today for the lion's share of the entry server market.
(2) I2O will be popular on Linux, when it is available soon, because it frees the operating system from the tyranny of driver monopolies.
(3) I2O is becoming popular among embedded developers of high-end network devices for the same reason.
(4) Ironically, the Future I/O consortium has served to endorse the need for a channel I/O architecture like NGIO.
(5) With the general acceptance of the need for channel architecture I/O, no major player can afford to ignore the arrival of pre-production NGIO samples, due in the first or second quarter of 2000.
(6) Assuming the Future I/O consortium continues development of an alternative channel architecture, no major player can afford to ignore the arrival of Future I/O implementations in the year 2002, if they meet their target.
(7) Assuming Compaq and IBM are successful in promoting a major industry bus upgrade, no major player can ignore the PCI-X bus.
(8) Legacy architecture not only will co-exist with bus-less architecture for many years, early implementations of channel architecture are likely to be hybrid constructs, housing a PCI or a PCI-X bus with emulated access to on-board processors, side-by-side with channel architecture.
Now, imagine yourself trying to develop I/O devices that cut as broad a swath as possible across the computer industry. How important is it to be first to the NGIO market? How can you be first to market across all the operating system platforms, when NGIO silicon will not be available one or two quarters before production delivery? What are the implications of maintaining a new set of drivers across all supported operating systems, in addition to all drivers currently supported. What are the implications of repeating the process, and multiplying complexity two years later when Future I/O begins delivery. What about the upcoming PCI-X, or equivalent, upgrade?
Your answer might vary depending on whether you are an entrenched player or a new entrant. Let's see.
If you are a new entrant, you have few choices. In order to get quickly to market using traditional development, and to be able to manage complexity, you would be forced to limit your market to one or two high-volume operating systems.
Alternatively, you can deploy I2O, develop a single HDM, and be compatible automatically (not counting a little tweaking that may be necessary in some instances) with every I2O-compliant operating system -- for systems with traditional bus systems, channel architecture or both. The I2O-compliant operating systems soon will comprise most new server deployments. Further, you may begin I2O development and production delivery today of devices suitable for both bus architectures and NGIO, and even Future I/O, expecting only to tweak your developments after delivery of sample silicon. Initial development probably will entail an IOP, which could be value-engineered to a specialized I2O solution in silicon later if warranted.
Your primary risk is that operating system vendors may give too little attention to updating and refining OSM's. Conceivably, this could cause your products to under-perform highly tuned proprietary devices developed with traditional drivers by entrenched players, or to be late to market if OSM's are faulty.
This risk seems to be dissipating rapidly because I2O benchmarks now seem to be at near levels achievable by proprietary solutions. Further, I2O already is sufficiently mainstream to pressure operating system vendors to attend to their OSMs. If they don't, device makers will write their own OSM's or third party software developers will jump into the breech.
An entrenched player only reluctantly sacrifices an established method of development, especially one affording the player a comparative advantage over new entrants.
Some entrenched players, will realize the looming complexities are too numerous to maintain competitive advantage by continuing to devote sizable resources to overcoming ever-increasing complexity. These enlightened vendors will embark in a new direction, sacrificing yesterday's comparative advantage for today's simplicity. It's called survival.
Other entrenched players will treat NGIO as another complexity multiplier, perhaps even perceiving the added complexity as ammunition for protecting established turf. They will change their way of developing product only after being forced to surrender to market forces. The main market forces in play will be time-to-market and breath of offerings, and inevitable pricing pressures from more nimble competitors. But there is another market force that could be far more devastating for vendors resisting the new way of integrating I/O devices, whether for bus or bus-less systems. That potential force is demand for I2O-features by the IT community.
Intel offically takes the position that I2O is a software protocol that can improve I/O throughput in any architecture, and can simplify product development. These are reasons enough to jump on the I2O bandwagon, especially for any developer planning to deploy NGIO product. Consequently, Intel has decided to brand NGIO, and allow I2O to come along for the ride. I2O may remain transparent to IT professionals, who will benefit from the technology, just like they benefit VI or physical multiplexing channels. It is there, but they need not be aware of the details.
This issue, branding I2O, is of much greater import to the computer industry than first meets the eye. Since it has its own set of complications, it deserves and will get a separate post devoted entirely to I2O branding. The main conclusions here are that I2O will blossom with or without branding, if anything propelled by NGIO and even Future I/O. Further, NGIO probably will succeed, thanks to I2O, as long as Intel can deliver within the time promised at a reasonable price. The future for Future I/O is less clear, and depends greatly on the launch of PCI-X, and certainly inversely on the success of NGIO.
Allen
I2ONGIOX |
