Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!killer!texbell!bellcore!ka9q.bellcore.com!karn From: karn@ka9q.bellcore.com (Phil Karn) Newsgroups: comp.dcom.lans Subject: Re: Token Ring (was: Re: Info on LANs) Message-ID: <13137@bellcore.bellcore.com> Date: 2 Jan 89 23:53:03 GMT References: <12786@cup.portal.com> <920001@hposdl.HP.COM> <10777@s.ms.uky.edu> <18659@agate.BERKELEY.EDU> <13096@bellcore.bellcore.com> <18672@agate.BERKELEY.EDU> Sender: news@bellcore.bellcore.com Reply-To: karn@ka9q.bellcore.com (Phil Karn) Organization: Home for Burned-out Hackers Lines: 63 >Boggs' argument may ignore certain key practical considerations.... I suggest that you read his paper. It contains actual test measurements made on a real live Ethernet network, not theoretical predictions. >On an Ethernet, one must send a packet to acknowledge receipt of a message -- >with all the delays inherent in setting up a buffer, waiting for the cable >to clear, etc. This overhead can cut the net throughput of an Ethernet by >more than 75% under any protocol requiring reliable data transport.... Nonsense. Surely you must understand the principles of internetworking well enough to know that an end-to-end acknowledgement and retransmission mechanism is essential in any heterogeneous internetwork, even if one component subnet happens to be a "reliable" ring. Because of its collision detection mechanism, Ethernet drops packets without warning so rarely that there is simply no need for a "link level" ack -- end-to-end retransmission is sufficient. (The only time Ethernet *does* silently drop packets is when the destination host is down or somebody pulls the plug on an intervening repeater -- and then neither end-to-end or link-level retransmission will help.) I refer you to the classic paper by Saltzer et al: "End-to-End Arguments in System Design". I suspect you are referring to Logical Link Control Type 2 (the connection-oriented version closely resembling LAPB). However, I don't personally know anyone using it. In fact, I don't know anyone using LLC Type 1 either; the original Blue Book (DEC-Intel-Xerox) Ethernet spec works just fine for us. In my opinion, the world would be a better and less confusing place if the IEEE 802.3 committee never existed. Anyone with experience in writing drivers can tell you that performance depends much more strongly on the hardware design of the controller than anything else. There are good Ethernet controllers, and there are bad ones. Van Jacobson of LBL recently presented the results of experiments with two controller chips (AMD LANCE and Intel 82586) and found dramatic differences. He was able to run the useful throughput of the LANCE chip very close to 10 megabits/sec, but the Intel chip did no better than about 5 megabits/sec. It didn't run into collision problems on the Ethernet; the chip simply didn't ask for data from the host fast enough. By the way, these were true end-to-end throughput figures, using TCP/IP. Note that both are greater than 4 megabits/sec. >>"Ethernet works in practice, but not in theory". > >By this, does Boggs mean that the IEEE and others are standardizing >equipment that can't be proven to work? I was taught that when many people can confirm that something happens in practice that doesn't match the predictions of a theory, then it is usually safe to assume that there's something wrong with the theory. The token ring does have its advantages over CSMA/CD when distances are large or data rates are very high. But your cause is not helped by spreading misinformation about the competition. Ethernet and token rings have complementary strengths and weaknesses, and they each have their place. At the moment, Ethernet is clearly superior to the token ring in doing what it is designed to do -- providing simple, reliable and relatively inexpensive computer networking over a small local area. Token rings, because of their more complex design, are inherently more expensive and less reliable, but they can cover much larger physical areas and run at much faster physical speeds. The Internet philosophy allows you to apply each technology where it makes sense, while still producing a single virtual network. Phil