HP3000-L Archives

April 1997, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Tue, 29 Apr 1997 15:38:59 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
Jeff Kell writes:

> I have been working with 100TX and 100FX recently as that was the path
>  we decided on for our backbone.  One of the big attractions of 100TX is
>  that most (but not all) 100TX equipment is full duplex, and you can push
>  100FX full-duplex quite a distance.  Point-to-point connections such as
>  between a router and hub, or a switched port and a device, when set for
>  full duplex, essentially eliminates collisions.

I am constantly amused (or bemused, or c-mused, or something) at the
"high-speed evolution" of all of this technology. LANs replaced statistical
multiplexers, a 30-year-old idea -- and were inherently far superior to
statmuxes, judging by all of the hyperbole attendant to their introduction,
making the "older" technology into dinosaurs.

Statmuxes were part of that age of dinosaurs. They used a process called
"commutation" to send data from one statmux to the other. Essentially, the
process was much like sending a continuous stream of coal buckets from device
to the other, the only difference being that the statmux dropped a piece of
your data into the coal bucket, along with a port address that the data was
to be directed when it reached the other end. And the process was
full-duplex. There was a constant stream of synchronous packets coming the
other way, from the remote statmux.

Collisions were impossible in this architecture. Bandwidth was the only
concern. If very many people tried to transmit and receive data
simultaneously, things slowed down a bit -- simply because everyone's packets
were being interleaved with everyone else's and no one had full access to the
full bandwidth of the lines connecting the two statmux ends.

LANs made all of this obsolete -- but necessarily did no one any favors in
the interim. The design of the statmux not only eliminates the possibilities
of collisions, it also inherently provided for a maximally efficient packet
packing. Under a commutation scheme, packets are lined up, nose-to-tail, as
close as they can be.

In contrast, most LANs ushered in a free-for-all form of technology, a
packing scheme based more on Chicago taxicab service protocols than logical
order, where the cabby listens for the first quiet spot in radio traffic and
then says repeatedly into the microphone "439" (indicating his taxicab
number), trying to get central dispatch's attention. A lot of collisions and
a lot of retransmissions result from this form of protocol architecture. And
once traffic density approaches bandwidth, the process avalanches into
virtual collapse while everyone is trying to break in and transmit the
packets they have in their queue.

The "LAN-based" point-to-point system that Jeff describes above re-invents
statistical multiplexers (if these new devices run a common synchronous clock
between them and commutate, and thus maximally pack, the packets).

Wirt Atmar

ATOM RSS1 RSS2