While I rarely post any more (trying not to be a repetitive boor), I am still around and remain extremely bullish about WIND – but more about that in a follow-on post.
The thread seems to be confused about NGIO, and in particular WIND's and I2O's roles in NGIO, as well as NGIO's relation to Future I/O and PCI-x. Let me tell you what I think is going on.
As everyone alive knows, Intel is extremely serious about targeting the server market as its largest and most important growth opportunity. Intel can only grow with PC market, since it is the PC market. Embedded systems is a must growth area for Intel, but it promises to remain a commodity market with low margins. Only in the server sector can Intel take market share, growing that segment extremely profitably for years. (This is why I find it difficult to bet on Sun, whether or not the stock market agrees with me. Sun is doing well and has exciting opportunities, but its bread and butter business is targeted by Wintel using a superior business model.)
Perhaps the primary factor limiting the use of Intel Architecture (I-A) in enterprise computing is the lack of robust I/O processing in Wintel machines. I2O was defined by Intel years ago to help address that weakness, and to this day increased I/O bandwidth remains the foremost selling point for I2O.
Meanwhile, I believe Intel formed, or energized, a new group around supercomputer types to further enterprise computing with I-A. (Recall that Intel has been working with Sandia Labs for years developing massively parallel supercomputers, and recently set the speed record of over a trillion operations a second.)
I believe those guys took one look at Wintel I/O and concluded that they needed to mimic mainframe channel I/O processors, which led logically to the so-called NGIO proposal and demonstration. The idea is to dispense with a system bus, which will become an insurmountable bottleneck in a few years, even with I2O, replacing it with direct high-speed links to multiple I/O “things”. I doubt that those guys thought one minute about I2O when they set out to mimic mainframe channel processors.
In a nutshell, this is what NGIO consists of: Rather than CPUs bridging from the local bus to a system bus (which would be the playground for I2O), the bridge connects to a device that controls the data flow in a multitude of links, or channels. The device has the name Host Channel Adapter, or HCA. Each I/O “thing” is connected to the HCA through a link, or channel, through its own device, or controller, called a Target Channel Adapter, TCA. (The word target should be meaningful to anyone experienced plugging in SCSI devices, and indeed has a similar kind of meaning with NGIO.) A server with a multitude of hard disks could run all of them through a single TCA, using one link, or break the disks up into groups with each controlled by an individual TCA and link to the HCA. The tradeoff would be made on the basis of I/O performance versus cost, since I/O is promised to increase essentially linearly with the number of TCAs (assuming balanced deployment).
In principle, none of this needs to have anything to do with I2O. However, the HCA must communicate with each TCA using some kind of message-passing protocol, queues, etc. At this point the NGIO designers at Intel discovered I2O, or the I2O advocates within Intel sold the NGIO team on I2O, but in any case I2O processors were used to demonstrate NGIO initially – both for the HCA and the TCAs. Further, the NGIO team seems to have gotten the word that, since I2O is perfectly adequate for NGIO, there are strong marketing reasons for NGIO to be perceived as an extension of I2O. A natural upgrade from I2O to NGIO should help facilitate adoption of both technologies, particularly when you consider the necessity of supporting hybrid systems deploying both TCA's and traditional bus-based I/O.
I believe the current plan is that, in production, the HCA will be a special, non-I2O device, but that TCA's will remain essentially I2O processors running a version of IxWorks. (A cheaper variation might consist of TCA's limited to a particular functionality implemented in silicon without the need for a full IRTOS.) In particular, the message-passing protocol used by NGIO will be based on I2O standards.
Meanwhile, IBM, Compaq and HP are resisting NGIO, just as most, but not all, engineering-advantaged computer companies resist deploying I2O (even though they all have completed I2O product development.) The reason has to do with Intellectual Property, not confusion or anything else. As a rule, companies resist standards that reduce their comparative advantage derived from superior engineering. They comply only when compelled, either because the technology in question is demanded by their customers, or mass-produced standard products put onerous pricing pressures on proprietary solutions.
With regard to I2O, it seems to be finding initial footing in RAID controllers. Whether or not IT managers know about or prefer I2O, already they should be voting with their dollars simply because I2O-based RAID is cheaper. It is cheaper yet if the I2O processor is on the motherboard. IT managers should begin demanding I2O directly once peer-to-peer applications begin to emerge, followed by compelling Intermediate Service Module (ISM) software applications. Further, it is incumbent on Intel to promote I2O if only to smooth the path to NGIO.
With regard to NGIO versus Future I/O, NGIO probably has the edge because Intel is such a powerful force when backed up by Dell, Gateway and a host of no-name computer makers, not to mention Sun. By the way, the skirmish over the PCI-x bus had little relevance to the NGIO outcome, and nothing at all to do with I2O. Remember that the I2O standard is not based on the PCI bus, or any bus for that matter. It just happened to be implemented using the PCI bus because the bus is universal and suitable. PCI-x is even better.
In a article posted to this thread a couple of months ago, it was mentioned that ever-changing I2O versions, the split-driver model, and bus wars were confusing the industry, thereby slowing adaptation of I2O. These claims are total nonsense. No one in the industry could be surprised or confused about advancing versions of a new I/O standard. Indeed, a major strength of I2O is its ability to upgrade through software, meaning that IT managers face less risk implementing emerging standards with I2O than without – and this includes the I2O standard itself.
The split driver model is a primary attribute of I2O, not its weakness. If device makers choke at developing an HDM, then “let them eat cake”. Once industry adopts wide-spread use of a split-driver model, every developer will experience vastly reduced device development, administration and maintenance. However, this may not be viewed as an advantage by established players.
The bus wars are not at all confusing; they are political. What we are watching is the new politics of the nation: the fight for market supremacy by technology leaders. The old politics in Washington are now so unimportant the stock market salutes an historical Presidential impeachment with an up day.
In summary, look for Intel to do a better job promoting I2O in 1999. They need to get secondary PC server makers in production with I2O functionality, so as to put pricing pressure on proprietary solutions. They also need to sell IT managers on the many other advantages of I2O unmatched by proprietary devices.
Allen |
