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: Knight who wrote (9609)	5/9/2001 6:45:31 PM
From: Allen Benn	Read Replies (1) \| Respond to of 10309

Nice to hear from a professional experiencing the exact problem TINA is designed to address. Maybe all this really does make sense! There are three practical possibilities for competition. The first and cheapest consists of putting on the NIC an ASIC, or possibly a FPGA, to offload as much as possible of the TCP/IP protocol processing. This is sort of a NIC with an accelerator. This approach helps, but not as much as does the iNIC, even though hardware solutions (ASIC or FPGA) generally run circles around software running on a microprocessor. I think we will definitely see competiton of this type early on in the GbE rollout. More on this below. The second class of competition could be another, proprietary version of an intelligent NIC, doing similar things as WIND’s iNIC but in a specialized, proprietary way. I haven’t heard of anything coming out along this line, but certainly it is possible. The problem with the latter would be the lack of standards. The standards in WIND’s iNIC have evolved with industry participation over a number of years. Intel is 100% behind the standards, so most IT managers should choose WIND’s iNIC over a proprietary copy. Finally, the reason the standards are important is the interoperability (peer-to-peer) between WIND’s iNIC and all the iTHINGS, like iSCSI, iRAID, iNP, etc. Even if a proprietary copy got a beachhead in the market, the compatibility issues would quickly cause it to be pushed aside by WIND’s iNIC. (This is a classic example of network effects.) It is not practical for a competitor to build a compatible iNIC, i.e., one that complies with all the standards, but does not use IxWorks and WIND’s TCP/IP extensions. The reason is it is just too difficult; it took WIND five years to get a generic software solution in place that meets exacting performance objectives. At worst, a compatible iNIC might be constructed using Tornado for I2O and proprietary TCP/IP processing – a solution that would still pay royalties to WIND. Like a proprietary iNIC copy, an ASIC/FPGA accelerator would not be compatible with the other iTHINGS. While devices of this type may be expected in the early days of the GbE rollout, they will be marginalized as iNIC’s and other iTHINGS take hold due to network effects. The third possible way around the problem is to re-architect the server. A private company, BlueArc, is attempting to solve the problem by re-architecting servers using reconfigurable computing throughout the I/O chain of processing, calling the result a Silicon server. (I believe they use Altera’s FPGAs.) I’m not sure what kind of reception BlueArc will get from the IT community if Silicon servers offer a new set of management problems, deviate from the tried and true, and don’t get Intel’s blessing, for one. My sense is that revolutionary changes are never adopted by the industry at large if a minor evolutionary change provides an adequate solution. Also, this solution does nothing for non-BlueArc-architected other server appliances, nor does it do anything for workstations. The inherent problems with each of these alternative approaches seem to point to iNICs as the solution with the best chance to dominate this space. Allen PS to Bill Fischofer. I wrote this before I read your recent post mentioning BlueArc. I take it BlueArc could be more of a problem for EMC where no one knows whats inside the box.