My post from January assumed an I2O growth rate in the 200% y/y region. Perhaps this is way overly optimistic ?
I2O has gotten very little press lately, and when it did (on January 19 to be precise) it received little fan fare. As I recall the stock reacted that day by going up a dollar or so, and then began an intermediate downtrend the very next day. A careful reading of the I2O press releases on that day, provides plenty of support for most of what you indicated in your forecast. It is clear that Intel is pushing its I2O-based iRAID building blocks with the intent of commoditizing the RAID sector. The scope of the IOP market resulting from this is large, but not enough alone to account for a sustainable 200% growth.
You are correct about InifiBand. As I understand it from people close to the action, I2O has progressed beyond being an option for Target Channel Adapters (TCA) to being the only realistic option. The number of I2O IOPs used for InfiniBand starting in 2001 ought to be substantial. Remember each host computer will be capable of supporting up to 65,000 TCA's. I have no idea of a realistic forecast, but it certainly has the potential to boost IOP growth significantly.
Now let's look a more deeply at other opportunities for I2O, some you chose to ignore or didn't know about when you built your model. The building blocks referred to in articles and press releases in January represent the new thrust Intel is taking, not so much to promote I2O, but to use I2O directly to revolutionize where and how network I/O is processed. As Intel/WIND climb the value-chain, from IOP's to building blocks to final products, value-add increases, enabling commensurate increases in derived royalties. I would guess that WIND's share of the value-add for higher-level components to be an order of magnitude greater than the unit I2O royalty from IOPs alone.
The emerging building blocks alluded to January 19 could be configured to handle countless I/O tasks around network servers and workstations. To accommodate all these possibilities, it has been evident for some time that IxWorks could benefit from more VxWorks-like functionality. (The only current alternative when functionality is needed like a file system, graphics, Java, etc. is to use two processors. The host, which controls the application, would run VxWorks with an OSM, supporting an I2O IOP over a PCI bus.) Consequently, you can expect the next version of IxWorks to implement the VxWorks API, enabling full-scale I/O centric application development.
Devices to handle peer-to-peer data transfers between RAID, LAN and backup tape devices will be a no-brainer. Devices for security, firewalls, filtering, and special data handling chores will be high value-add appliances, with some hitting the market as early as the end of this year. There is now no question that the Intelligent LAN NIC's, based on building blocks available to OEM's, will be flooding the market next year and beyond, particularly as LAN speeds gravitate to the Gigabit rate. Fully off-loaded TCP/IP stacks and network I/O processing is a necessity to keep from drowning high-level workstations and servers alike in network packets.
At the more exotic level, soon it will be possible to place an IXP (Intel's new Internet eXchange Processor) on an iLAN NIC, turning the card into a powerful network switch competitive with standalone devices costing thousands of dollars. WIND's value-add in this instance might well include TMS software, IxWorks driving the NIC, building block middleware, and VxWorks on the IXP StrongARM core.
These are the same kinds of I2O functions I talked about incessantly for years. The difference now is that these devices have become practical to build with the latest development tools and hardware from Intel/WIND. Another difference is that we are not relying on the industry to accept the I2O standard and start building products. Intel is content to use the technology itself to build and ship revolutionary products. Expect other OEMs to jump on the bandwagon in order to compete.
Working together by building components and products using I2O, Intel and WIND will reduce the processing of network I/O to a commodity. Thus, even without a formal campaign to brand I2O, the inevitable outcome of this joint effort is the de facto standardization of network I/O based on I2O.
Of course, all these revenue components ignore product licensing and services revenues that should sky-rocket to support broad development using IxWorks.
I'm not sure how much revenue all this amounts to, but your assumption of 200% growth for the next few years seems conservative. Your conclusion that I2O royalties alone more than justifies WIND's market cap appears valid, as strange as it seems.
Allen |
