Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Wind River going up, up, up! -- Ignore unavailable to you. Want to Upgrade?

To: Allen Benn who wrote (4294)	2/17/1999 9:14:00 PM
From: Allen Benn	Read Replies (1) \| Respond to of 10309

A Report on I2O and NGIO – Current Status NGIO provides a basic level of communication between the host adapter and the adapter on the other end of the channel (called the Target Channel Adapter or TCA), consisting essentially of SCSI-like send and receive commands. In addition, NGIO builds on the basic commands to provide higher-level, I2O-compliant messaging as well. All this is accomplished in the Host Channel Adapter (HCA), which will be embedded in silicon with an I/O bridge to local memory. Thus, a target device can communicate with the HCA along the lines of a SCSI device, using host drivers compatible with the operating system. Alternatively, the target can communicate using I2O messages as governed by a local HDM, independent of the host operating system – as long as the operating system supports the device class with an appropriate OSM. Intel realized that it confused the industry with the NGIO foray, and took action by making an organizational change that took effect around November 1998. The NGIO and I2O groups within Intel were combined organizationally, along with the VI group. (The VI group promotes the Virtual Interface Architecture standard, the technology NGIO uses to implement “virtual” channels.) Without any doubt, NGIO is absolutely critical to Intel's vision of enterprise computing, and enterprise computing is Intel's most important market for achieving profitable revenue growth. Intel is having to respond in Internet time to this challenging market, as evidenced by the aggressive schedule for getting NGIO into production. The technology should be available in the Q3 of next year, making its debut along with the long-awaited Merced processor. NGIO will be available for other processors as well, even 32-bit processors. Of particular note is the deal struck between Sun Microsystems and Intel whereby Sun plans to make NGIO available on its Sparc servers – that should imply that Solaris for Sparc, not just their I-A version of Solaris, will fully support I2O. The newly formed NGIO/I2O/VI group has decided to emphasize NGIO and to view I2O as more of a stealth technology. While I2O is not essential for interfacing with NGIO, it is expected to be preferred. For now, Intel is not concerned about branding I2O on devices in order to create demand from the IT community, because they only want to benefit from I2O, not suffer if there is any resistance to adopting the high-level I/O standard. In particular, Intel is sensitive to the Future I/O consortium charge that NGIO requires expensive I2O IOPs. Consequently, NGIO-compatible devices will be available in one of three forms: (1) Basic in which SCSI-type device drivers are needed much like traditional I/O devices. (2) Specialized I2O in which the target speaks just enough I2O to perform a specialized function, obviating the need for an I2O processor. (3) Full-featured I2O using an I2O IOP. The second type of I2O interface can be implemented in silicon or in software. An example of a software implementation of specialized I2O might be an embedded device using Windows NT without an I2O IOP. The following link shows how local and remote I2O can coexist on a host computer. For legacy devices, the host computer could have a PCI bus supporting I2O. The change would be on the backside of the bus. The traditional I/O bridge would be altered to adapt to the channel-based I/O handler on the host. Other I/O devices would connect to a virtual channel through a normal Target Channel Adapter that attaches to the Fabric. developer.intel.com The Future I/O consortium proposes a slightly different approach. First, they propose that the industry upgrade the PCI bus to PCI-X, using traditional drivers or I2O, or whatever. Then the Future I/O architecture will guarantee connectivity through a remote transport that adapts a PCI-X bus on the target to the Fabric and on to CPU memory. PCI-X first, then Future I/O with no fuss or muss. Allen I2ONGIOX