When first announced, WIND was careful to speak of I2O primarily as a necessary upgrade to servers, particularly as a way to provide mainframe-like input/output in an Intel-Architecture server. While COMPAQ and others were already using off-loaded I/O processors in servers, the fact that Intel was promoting I2O with Microsoft's acceptance seemed to suggest that I2O would become a de facto standard of the industry, thereby providing additional benefits of standardized interfaces. Foremost of these benefits would be the simplification and automatic compatibility of connecting various I2O devices to the same computer. That I2O would gravitate to Unix or other non-Intel platforms was unclear.
Later last year, we began to notice that I2O was being planned for lots of devices other than the traditional ones associated with servers. What these devices seem to have in common was (1) network and (2) PCI bus. The device might be a network RAID box, unattached to any particular server, or a HUB, router or switch that uses the PCI bus. While we always expected some of this to develop, the variety, creativity and speed with which non-server-attached devices began to proliferate surprised me.
During all this time, we also postulated the eventual need to put I2O on the PC, but this talk was limited mostly to this thread and a statement made by Mark Murphy last fall when he reviewed the embedded systems space. Well it now appears that PCs are officially targeted by the I2O crowd.
Why would anyone want to bother putting I2O on a PC? Most PCs communicate fast enough when connected to a network or other data sources to be excused from needing an expensive add-on feature. Speed is nice, but do we need that much extra speed that we are willing to complicate the design of PC?
Certainly there is no such thing as too much speed, especially in handling multi-media data traffic. So, I2O may be justified on PCs just as it is on servers, albeit to a somewhat lessor extent.
But I think the primary selling point for I2O on the PC is that it not only doesn't complicate the design of a PC, it radically simplifies it. Any two I2O compliant devices can communicate (with little involvement of their associated CPUs and OSs) and exchange data using a number of standardized formats. A single I2O module attached to the PC would open up a wonderful world of data connectivity with minimal traditional concerns about how to handle communication protocols, data messaging formats, etc. This world would be interesting but useless if I2O devices were rare, but it becomes priceless and absolutely necessary if I2O devices are commonplace. In other words, the secondary benefits often identified with I2O become primary when the standard becomes commonplace.
The fact that WIND is uttering the PC-word, suggests that the time has come for I2O to be positioned as a generic I/O handler on all devices: PCs, servers, disks, printers, telecomm and data communication devices, you name it. Should I2O develop as a standard to this extent, it would be extremely favorable for WIND. It is not important that i960R become the standard-bearer. Likewise it is unimportant whether or not IxWorks is the only logical implementation of I2O.
In fact, should I2O develop as an important standard, you can expect non-Intel/WIND implementations, in every conceivable combination of hardware and software. Assuming much of I2O can be accomplished without real-time, you might expect I2O functionality to be implemented as communication software on PCs without off-loading any I/O processing from the CPU. Why? Simply as a software solution to take advantage of the generic I/O where speed is secondary. You can expect I2O to be implemented on hardware platforms other that Intel's i960 R series. Some of these implementations might collaborate with WIND to gain access to IxWorks; others might decide to develop their own I2O logic. All are possible and probably will happen if the standard succeeds.
Should I2O develop as a standard. That is the only risk-factor limiting the importance of I2O to WIND. Other solutions no doubt will come into play, but WIND has an insurmountable position as market leader in this niche, and will benefit hugely in a huge market. Finally, WIND's announcement is suggestive of the mighty effort required by anyone contemplating trying to field a competitive product. Why not just build on existing capability, focus on your core strengths, and pay affordable royalties to long-term investors in WIND?
>why is I2O considered an RTOS -- where does the "real time" come into play?
Perhaps Dave can give a concrete example, but it seems natural to me that some communication protocols will want to synchronized. Video, for example, needs to come across at 30 frames a second to be high-quality. Whenever deterministic timing is required you must either service the process with a dedicated processor that has the power to keep up, or else be able to guarantee adequate attention while performing other functions in parallel. The former is a rarely acceptable solution in the complex world of modern, multi-tasking computers, and the latter is done best with real-time operating systems.
Some OSs can be multi-tasked and approximate real-time by use of priority-setting options. But, if you are building a multi-tasking, network device, wouldn't you just as soon go all the way, and satisfy real-time requirements in the best way possible, especially when doing it the right way is easier and costs less?
Allen |
