Virtual Interface Virtually Eliminates I/O Bottlenecks
As bandwidth rises into gigabit territory, networks are reaching the point where processors are unable to simultaneously handle network and application instructions. It behooves e-business enterprises to maximize their bandwidth, so they can reduce the cost of their investments and increase the number of customers they can reach.
Virtual Interface (VI) technology promises to fill network bandwidth while keeping server processors free to run applications. One company, Giganet Inc. (www.giganet.com) has introduced VI Ethernet cards that move the network work off of the processor and onto the cards.
"TCP/IP is too slow and computation intensive to scale," says Garrett Taube, senior vice president of marketing at Giganet. Taube believes that there is an upper limit on TCP/IP networking, using traditional software networking techniques.
Steve Duplessie, senior analyst at the Enterprise Storage Group (www.enterprisestorage.com), agrees TCP is not optimal. "However, it isn’t going to go away," he says.
To maximize bandwidth utilization, computers need to process instructions for the TCP/IP stack. Now that bandwidth has reached, 1Gbps and beyond, it is difficult for most computers to both perform the network instructions and application instructions, while still filling the bandwidth. Taube says that it takes about 7,000 instructions to put a packet onto the net. With bandwidth increasing by powers of ten, servers are quickly becoming clogged with network instructions.
Although processor performance is constantly increasing, Giganet wants to maximize bandwidth today. And, as Dave Wells, director of business development at Giganet says, "When you’re doing things in Silicon, it’s much cheaper."
Giganet’s solution is to create host bus adapters that process network instructions independently of the CPU, allowing applications to use more CPU and bandwidth. According to Duplessie, only 30 percent of bandwidth is used in normal TCP/IP configurations.
Giganet’s VI host bus adapters require applications to use APIs to gain the maximum benefit. Because the TCP/IP stack is taken off the CPU, the output of applications such as databases must know to go to the adapter, rather than the TCP/IP stack. Non-VI enabled applications will function on machines with VI HBAs, but do not gain the advantage of the VI technology.
This is Giganet’s entry into the standard Ethernet space. Their previous products used a proprietary cable to connect applications servers with middleware machines, creating a high speed connection between the parts of a Web farm or between application machines and storage devices. Now that a standard Ethernet connection is used, servers can be used to connect to any number of machines, VI enabled or not.
Duplessie suspects that storage will be the "killer app" for VI, obviating the need for additional, proprietary protocols for SANs. "Nobody is going to want an independent storage network," he says, suggesting that administrators will want to spare themselves the headache of implementing both IP and Fibre Channel networks, to gain the advantage of SAN.
Network Appliance Corp. (www.networkappliance.com) seems to agree; they have announced development of a filer, a type of storage appliance, using VI.
"There is an inevitable convergence between storage networks and IP networks that is going to happen," Duplessie says. He does not think that SAN adoption will take hold until administrators can standardize between existing networks and storage networks.
Mike Kahn, chairman of the Clipper Group (www.clipper.com) is not so certain that a single protocol is necessary or attractive to users. "I don’t see one wiring scheme," he says. Kahn cites the fact that mainframe users are accustomed to using a variety of proprietary protocols, so data center users, may not be turned off by Fibre Channel. "You’re going to wind up with a bunch of storage protocols," he says.
"The reality is that this is an invisible issue," Kahn says. He believes customers don’t care how storage is put together, only that they get their web pages when they want them. Administrators will also be interested in maximizing their performance, not in adopting standards for philosophical reasons.
Kahn is unsure, also, of how many developers will want to optimize applications for VI. He raises the question, "Where do you make your money, on software or on hardware?" Some vendors interested in selling multiple boxes in the name of clustering and high availability will see no advantage in adopting VI, since better performance could cut into their sales.