[e2e] on local ethernet throughput?
Cannara
cannara at attglobal.net
Sun Oct 21 21:33:26 PDT 2001
What Vernon says is quite right and I'll only add that Collision sensing and
recovery happens in times on the order of 200 uS to a few mS, on even
extremely highly contended Ethernet segments (many stations ready with pkts to
send all the time). This is far faster than Token passing (many mS), in any
of its forms, as a very pertinent graph from the original IEEE 802
standarization simulations shows (it can be faxed to anyone who wishes a
copy). This graph is particularly telling in that CSMA/CD become better in
relation to Token as the number of contending nodes increases -- yes, better.
One reason for trying to rid the world of 'collision' myths is that they serve
as an alarm for how easily misinformation can arise and how hard it is to
gather peoples' intellects together to stamp the myths out. Confining
ourselves to networking, we must be aware that this applies in the TCP/IP
realm as well. Back to the LAN realm, which the original IP world had no
cognizance of, the collision myth, that started as an IBM marketing weapon,
matured into a switch vendors' scare tactic to sell at first cut-through (a
bad idea now in disrepute) and later "a segment for every node", so that
"collisions would no longer occur" -- just pushing the problem into
provisioning of the switch fabric. "Caveat emptor" is as necessary today as
it has ever been.
Alex
Vernon Schryver wrote:
>
> > From: Dan HE <he at enseirb.fr>
>
> > ...
> > Is the >90% throughput maitained for every nodes communicating at the
> > same time or not?
> > Vernon's email hints that if there are n machines sharing one common
> > segment,
> > the bandwidth of each node can be fairly allocated up to 1/n of the
> > total bandwidth.
> > because of "colliding". So does colliding result in triggering CSMA/CD
> > restransmit?
> > I remember that one email said "NO". It concludes that packet loss is
> > possibly caused
> > by ethernet collision, right?
>
> Ethernet collisions are no more than the mechanism by which CSMA/CD
> distributes the available bandwidth of the shared wire among requesting
> stations. The best you can hope for a wire shared among N machines
> is that each machine will get 1/N of it. (Priority schemes such as
> in FDDI have all failed, perhaps because unlike WAN QoS, it is cheaper,
> more reliable, and easier to use separate wires for separate classes
> of service.) For decades people have heard the word "collision," not
> bothered to understand the protocol definition, and assumed that a
> "collision" is something bad. It is not bad but merely a "bus
> arbitration event." At least one of those who chose the word "collision,"
> Rich Seifert, has often agreed in public that the choice of the word
> "collision" was a mistake because of what lazy people assume.
>
> As I recall, IEEE-802.3 says that stations "retransmit" after a
> "collision," but that is another unfortunate word choice that allows
> people to falsely assume something bad. In fact after a "collision"
> only the first "slot time" worth of the packet is sent again, because
> only that much has been transmitted when the "collision" stopped things.
> A CSMA/CD collision rate of 100% (one collision for every successful
> packet) for a typical TCP/IP/Ethernet stream (67% 1460 byte data segments
> and 33% ACKs) spends only about 6.5% of the available bandwidth on
> "collisions" and "retransmissions."
>
> I don't think this mailing list is about Ethernet or local area networks.
> Anyone who really cares about CSMA/CD should read the IEEE standard or
> the preceding "blue book." Rich Seifert's book "Gigabit Ethernet,"
> ISBN 0-201-18553-9, might be more accessible, and since the author is
> one the inventors of CSMA/CD, almost as authoritative as the IEEE
> standard. The Boggs et al paper that Mr. Cannara mentioned is readable.
> relevant, contains useful references, and can be found via Google at
> ftp://gatekeeper.dec.com/pub/DEC/WRL/research-reports/WRL-TR-88.4.pdf
>
> Vernon Schryver vjs at rhyolite.com
More information about the end2end-interest
mailing list