Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.dcom.lans Subject: Re: Ethernet collisions Message-ID: Date: 21 Dec 90 16:00:53 GMT References: <467@pirates.UUCP> <2184@cybaswan.UUCP> <1990Dec11.174941.12301@zoo.toronto.edu> <1990Dec14.191255.20529@freedom.msfc.nasa.gov> <1990Dec14.163357.2361@jarvis.csri.toronto.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 69 Nntp-Posting-Host: odin In-reply-to: mart@csri.toronto.edu's message of 14 Dec 90 21:33:57 GMT On 14 Dec 90 21:33:57 GMT, mart@csri.toronto.edu (Mart Molle) said: mart> In article <1990Dec14.191255.20529@freedom.msfc.nasa.gov> mart> cornutt@freedom.msfc.nasa.gov (David Cornutt) writes: cornutt> The percent utilization of the channel capacity of an Ethernet cornutt> (or any CSMA-type network) depends not so much on the total cornutt> volume of traffic as on the number of nodes that have traffic cornutt> ready to transmit simultaneously. [ ... look at Tanebaum's book cornutt> and see that ... ] The theoretical worst case occurs about n = cornutt> 100, where the channel utilization is down to about 37%. mart> Pay no attention to Tananenbaum's calculation of Ethernet mart> throughput. It is a gross simplification, [ ... ] For example if mart> the ``useful'' slots are 1/a times longer than ``wasted'' slots, mart> the capacity is about 1/ (1 + a * (e-1)), where e is the base of mart> the natural logarithm and 1/e is the capacity of slotted Aloha. mart> If you want a more accurate analysis of the throughput for mart> unslotted 1-persistent CSMA/CD used in Ethernet, go read the mart> articles by Sohraby, Molle and Venetsanopoulos, and by Takagi and mart> Kleinrock, in IEEE Transactions on Communications, February 1987. mart> [ ... ] These papers show that CSMA/CD can get very high channel mart> efficiencies even in the limit of infinitely many active stations. But this is just the utlization factor of the channel. Okay, Ethernet is not slotted Aloha, and it can get very high utlization factors basically because latency is very small and in the occurrence of a collision the abort is nearly istantaneous, and the retry by another station has good chance of success. However what about delay? The medium gets near its rated thruput, but the average station will have to wait a time that is pretty long, retrying quite a bit. Suppose we have 100 stations on the net, each of them, if efficiency is 100%, will get almost 10KB per second bandwidth, 1% of the total, and wait (assuming equal sized packets) 99% of the time for a chance to send its packet, by waiting for silence on the wire or for retransmit timeouts. Even with 10 stations, say communicating in pairs, things are fairly bleak. How do we square the model that says that we should get near optimal efficiency with the reality that we do not get it? A hint is given by comparing: cornutt> (I have seen values close to this in a campus network that I cornutt> once worked on.) In practice, an Ethernet starts to break down cornutt> at this point as controllers begin giving up due to exceeding cornutt> their max retry settings. mart> However, they fail to include the truly bizarre influences of the mart> truncated binary exponential backoff algorithm used on Ethernet mart> and thus are not the last word on the subject. In practice even if the medium efficiency is high, the big problem is that the network interfaces are bad, and are not fast enough. If you take into account the limitations of network interfaces the picture changes suddenly, in particular for rooted communications patterns, in which a lot of the traffic goes to a single interface, which gets swamped. If the idea that Ethernet-the-wire-and-protocol can achieve 100% efficiency (but with long and variable delays) is true, and I think this is now established, it is interesting but not much relevant, because the real bottleneck is the network interface, and those are usually quite horrid. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk