Larry Boucher is the founder of a couple of companies in the storage space, including Adaptec Inc., where he served...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
on the board of directors until 2001. In 1997, Boucher founded Alacritech Inc. and now says the company has seen an uptick over the last fiscal year in users deploying its TCP/IP offload engine (TOE) cards for use with iSCSI storage. He sat down with SearchStorage.com to talk about the trends he's seeing in the market, and why he feels TOE cards will almost inevitably be coming to an iSCSI storage area network (SAN) configuration near you.
You say your TOE card business is growing. Can you share any hard numbers there?
Larry Boucher: Our revenue numbers are confidential at this point, and we also are not defining total revenue or splitting out portions of it, but we can say that particular part of our business has doubled in the last year. We've added as many as 100 customers -- we're also seeing more reseller traction as far as iSCSI is concerned.
Boucher: We've been shipping product for four years, but it's only in the last year that the SAN business as a separate business has been ramping. This is a significant business change for us, and it's also what we think the market in general is seeing. People have been saying that this was the year of iSCSI for the last five years, but we think finally that statement is correct.
We've been seeing growth in people moving from DAS to SAN and NAS. As far as the configurations, we're seeing high port counts, which means there's more storage behind the card, which means SANs are growing. It also means we're seeing a lot more midrange and enterprise deployments of iSCSI. It's maturing not just into small implementations but large ones.
Aren't today's servers powerful enough to eliminate the need for offload cards?
Boucher: There's no question an alternative to using acceleration is to add more processors. That's always true. The question is which would you prefer to do? In general, people don't want to add processors because they take up power and space. By using accelerators, you significantly reduce the number of processors.
Still, a lot of users already have some consolidated, beefy physical hosts because of VMware.
Boucher: Which data moving application are you aware of that's running on top of VMware? I'm talking about applications that are compute rather than data-oriented. People don't generally put data-oriented applications on VMs [virtual machines] because it kills them. The areas we support, file services, streaming data, video and audio, high-end databases, or anything that's moving a lot of data.
People aren't using VMs as file servers?
Boucher: If I have a lot of file movement, the last thing I'd ever do is put it on VMware. If you look at customer applications for VMware, you'll discover almost every single customer is aggregating servers. So what somebody did is take 20 machines at 2% to 5% utilization and put them on one machine. None of them were data moving machines, like Web servers, file servers …
With some databases it can be a real big help, and others, not so much. It's really a function of the particular database application … In transaction processing, the single most important issue is latency, and while TCP offload can help latency to some extent, that hasn't been the area we've focused on. We're now starting to reduce latency, as well, but all of our work in the past has been toward bandwidth support. In the database area, the only area where bandwidth support is really effective is when databases are comprised of relatively large objects.
File service, backup, Web services and transport of large objects -- Sounds a lot like Web 2.0.
Boucher: Yes. We've seen it in the video world also. For example, Avid Technologies uses our cards in their post-production work. A number of video providers use us for exactly that reason. In general, our customers have been what you would consider either the lunatic fringe in performance -- that's the video guys -- or what you'd consider the midrange market. Generally, it's going to be somebody who has a few servers serving the same data. As soon as you're in that position, the last thing you want to do is add a server -- you want to reduce the number of servers while adding performance. That's the sweet spot of our market in the file services business.
How do you expect the picture to change with 10 Gigabit Ethernet (GigE)?
One of the areas we think is very exciting is the fact that as any particular technology becomes fairly ubiquitous, especially I/O technologies, they tend to get integrated into what has become known as the 'South Bridge,' the part of most motherboards that contains chips with Ethernet, USB, printer, serial bus and audio connections. We're looking to partner with the companies building those chipsets to add our technology, because I think over time TCP offload becomes a generic inherent part of Ethernet. This was considered important for quite awhile. Invidia designed and announced a product that incorporated it for 1 Gig[E], but it died out as processors got faster. For 10 Gig everyone knows they have to have it.
So are you partnering with any of the major chipmakers yet?
Boucher: Not that we can formally announce.
So, isn't 10 GigE a similar story to iSCSI, where it's 'The Year Of…' for about five years? When do you think we'll see real 10 GigE adoption?
Larry Boucher: My guess is it won't be seriously ramping until 2009. There are two major things that need to happen. Basically, first we need a solid copper interface that's considered a standard that everybody's going to use. The second thing is that we have to agree on backward compatibility standards. Right now, I have a 10 Gig interface that 1 Gig doesn't work with. Do you think all these 1 Gig laptops are plugged into 1 Gig backbones? Not a chance. We have a backward compatibility 'spec' and copper on the market, but everybody hasn't agreed this is the standard. You can't go someplace and do a compatibility test. We're just not there yet.