Tuesday, May 23

Geek

Downhill Both Ways

As late as 1998, you could find papers extolling the virtues of ATM to the desktop. (Warning: Illegible in browsers other than IE6.) ATM could handle voice and video at the same time! Sure, fast ethernet looked sexy, but you only really achieved 40% of that 100mbits, and a single CSMA domain could only extend 200 metres at its furthest extremes. ATM could plug straight into the corporate backbone, and the 53-byte ATM cells meant a worst-case response time 7 times better than fast ethernet.

ATM to the desktop was the way of the future.

Right.

No-one rolled out ATM to the desktop. Everyone rolled out fast ethernet.

Why?

One: They already had ethernet. If you have ethernet, and it's slow, then the obvious solution is fast ethernet, right? Which is a large part of why 100BaseVG-AnyLAN died in the market. You can buy fast ethernet or... What was it again? 100BasicVB something? Let's just get some of that fast ethernet that everyone else is buying.

Two: Speed wins. Fast ethernet is 100mbits. ATM was being pushed for the desktop at 25mbits. 100 is more than 25. End of story.

Three: Price wins. Fast ethernet was cheaper.

Four: The price for ethernet switches fell through the floor. Suddenly, no-one in their right mind was using hubs. That 40% ceiling? Erased, utterly. Now you could not only safely hit 100%, you could safely exceed 100%, because different parts of your network were effectively on different circuits - all handled automatically.

That wiped out ATM's former big advantage - quality of service.

Let's say you had a network that was carrying both phone calls and data, such as terminal sessions to your accounting system. If your network gets full, you can't slow down the traffic on the phone calls, because then people won't be able to understand each other. But you can slow down the terminal sessions. It's annoying, but it still works. ATM looks after this for you.

On old-style ethernet, with a single network segment, once you started pushing too much traffic (and "too much" wasn't actually very much at all), everything would stop working. Both the phone calls and the terminal sessions would fail. (There was actually something called isochronous ethernet that ran 96 ISDN B-channels alongside standard 10mbit ethernet, so as to carry voice and data at the same time. It died.)

On new, switched, fast ethernet, it simply wasn't a problem. The phone calls and the terminal sessions weren't competing for scarce bandwidth anymore, because (a) they were put on different circuits, and (b) bandwidth wasn't scarce.

And ATM dropped dead, as far as computer networks go. The phone companies still haven't worked this out.

Right now, I can buy a 48-port gigabit stackable layer 3 managed network switch and 48 gigabit ethernet cards for the same price as one 155mbit ATM module from Cisco. Which way would you go?

And when you come to upgrade your gigabit ethernet, would you choose 10-gigabit ethernet, or... That other thing?

Posted by: Pixy Misa at 09:51 AM | Comments (2) | Add Comment | Trackbacks (Suck)
Post contains 507 words, total size 3 kb.

1 100BasicVB something? Heh.   I learned more about this than I wanted to as a telco eq investor toward the end of that industry's nuclear winter a few years ago.  In retrospect it's sort of amazing anyone thought ATM to a desktop could be competitive with cost per bit dropping so fast.  It's almost like POTS vs. VOIP today; sure, POTS is theoretically more reliable (for now), but who wants to pay 10x the price for it?   Of course, the car analogy is a dead giveaway that the author is smoking something.  But this is my favorite part:   As you can see, even with all of these applications running simultaneously, the required bandwidth is still within the capability of 25 Mbps.   Uh huh, sure.  It's not like anyone would ever want video data faster than real-time.

Posted by: TallDave at Tuesday, May 23 2006 11:35 AM (YpqqW)

2 Ah, here's the money quote from the article criticizing Ethernet: Therefore, the actual throughput capacity of a switch is directly linked to its processor's power and limitations. Obviously, they didn't spend enough time considering the implications of that statement.  (Hey, isn't there some sort of law about processor speeds and how quickly they improve?)

Posted by: TallDave at Tuesday, May 23 2006 11:48 AM (YpqqW)

Hide Comments | Add Comment

Comments are disabled. Post is locked.
49kb generated in CPU 0.0185, elapsed 0.1023 seconds.
56 queries taking 0.0941 seconds, 347 records returned.
Powered by Minx 1.1.6c-pink.