The Gigabit killer app is within vendors’ reach

Every story written about Gigabit Ethernet to the desktop, it seems, has an obligatory reference to the “killer app.” Most analysts note that, well, there isn’t one. Intel says you don’t need one. I disagree with both assessments.

Analysts start with taking on the cliché of “real-time video” being the poster child for Gigabit desktop applications by noting, accurately, that business-grade video doesn’t even put a strain on Fast Ethernet desktop links (See story).

For its part, Intel engages in a clever bit of obfuscation. The company concurs that there is no app that can use anywhere near the full bandwidth of Gigabit Ethernet – but you still need Gigabit Ethernet. Why? Because in today’s multitasking world, you’ll likely be running lots of bandwidth-needy applications simultaneously. Thus, it is something of an aggregate killer app that replaces the single killer app of old. (See DocFinder: 5645.)

There is a killer app – it isn’t sexy and it is sitting right in front of everyone’s face: bulk data transfer. If there is one universal truth in enterprise computing these days, it’s that users are dealing with larger and larger chunks of data all the time. As databases have become more sophisticated and more portable, we even have end users synchronizing nontrivial data stores between client and server.

Moving 500M bytes of data between client and server is common.

With Gigabit Ethernet’s theoretical capacity of more than 100M byte/sec (in just one direction), it should take just 5 seconds for such a file to move across the network. However, Windows 2000 users on very high-end machines will find that it takes more than 90 seconds to move this much data using Windows file copy utility.

Even using purpose-built “data mover” applications such as Retrospect from Dantz, the transfer takes some 40 seconds – eight times longer than one would expect. This Gigabit Ethernet performance isn’t even twice as fast as when run across Fast Ethernet. Bumping up an order of magnitude in bandwidth, you’d expect to see a more dramatic improvement in throughput. But you don’t.

And Sonic Solutions’ Backup MyPC product fared worse, with its Gigabit results barely besting the Dantz Fast Ethernet results. (Note: This information is the result of independent research that The Tolly Group conducted; ITclarity report number 503001.)

Being able to move 500M bytes in 5 seconds rather than 90 seconds sounds like a killer app to me. The absence of this killer app isn’t the fault of Gigabit Ethernet – it can handle the load – it is the fault of application vendors who’ve just tuned out the whole issue.

A big stumbling block for app vendors is that they’ve grown accustomed to the old-fashioned, DOS-style, single-tasking way of doing things. In every case, the programs we studied seem to do their work one file at a time. Clearly, a parallel approach is needed to keep that Gigabit pipeline full.

Equally problematic is that all of these applications rely on using the Common Internet File System file access model for interacting with the remote file system. You might remember this better as Server Message Block. If you are wondering if this could possibly be related to the Server Message Block protocol first put forth by IBM in the mid-1980s, the answer, sorry to say, is yes. It’s basically the same thing.

Maybe Intel or Dell should pay some app vendor to write this killer app. Then they could really wave the flag about Gigabit Ethernet. Until then, it remains a story of unrealized potential.