Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!think!nike!ucbcad!ucbvax!CIS.UPENN.EDU!Magill From: Magill@CIS.UPENN.EDU (CETS Operations Manager) Newsgroups: mod.computers.vax Subject: Re: cascading CONNECTED DELNIs is illegal Message-ID: <8609292340.AA00439@linc.cis.upenn.edu> Date: Mon, 29-Sep-86 19:28:00 EDT Article-I.D.: linc.8609292340.AA00439 Posted: Mon Sep 29 19:28:00 1986 Date-Received: Wed, 1-Oct-86 01:54:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 78 Approved: info-vax@sri-kl.arpa Please excuse a possibly redundent reply. I have spent the past several weeks bring up a new 8650 and expanding our net. Therefore I am just commenting on early September without having read late September. I would hope that someone has said this before, but here goes. First, we have a large, multi vendor, multi host, ethernet. It runs across ISN fiber optic backbones with ethenet interfaces from ATT. It has many and assorted bridges, repeters and delni's allover the bloody place. We have devices ranging from 20+ real vaxes (750 to 8650) 30+ micro vaxen (I,II,GPX) 20 HP 300s, 6 Symbolics Lisp machines, and an assortment of assorted other things. Yes the ethernet "specs" are conservative. Ethernet's existance is based on the ability of any given segment to determine within a rational time period, wether or not it's data has gotten walked upon.... cd/cmsa. That in a very loose translation into english? is what the various length restrictions amount to. Every piece of cable, and every device adds TIME to the size of your network. If you have a short network... two delni separated by one meter of FAT orange cable.... you can cascade (I think, as I haven't tried it) 8 deap. I don't know why you would want to, however. But if you replace that one meter length of FAT orange cable with skinny (ie cheep) cable, then you have to reduce your depth according to the propagation delay introduced by the difference in transmission characteristics between good (FAT orange) and bad (thin) transmission mediums. Now into this equasion you must add the "standard" characteristics of a device - transceiver, delni, port... whatever. If you have "good" ones... ie, ones which have wide tolerances for signal levels and signal to noise rations, then you have one set of optimal characteristics. If you have "bad" ones... ie ones which won't hear anything below +5db and can't differenitate ac hum from collisions, then you have another set of design problems. In short, a lot of engineering went in to the published "specs" for ethernet. But then so does a lot of engineering go into a Chevy. But if you get a hot mechanic you can turn that same Chevy into a "Heavy Chevy" without changing any of the parts, just by retuning it. That Heavy Chevy now wins $$ at the drags.... But try to climb Mount Washington with it. It will probably blow its head gaskets! Similarly, if you have a small ethernet environment, you can violate almost all of the "published" specs with a reasonable degree of impuinity. But when you try to expand that net to the next floor, you suddenly find strange problems that will go away if you stop violating the "rules". If you will be the only one responsible for your network for the next 20 years (or until it is ripped out and replaced), you can streach the rules to meet your local situation. But, if you don't plan or expect to be in the same position for that time period, you better DOCUMENT YOUR DEVIATIONS so that you can pass them on to your successor. Or you will discover yourself being called many nasty things after you have gone and they try to expand your "optimized" network. Remember, TIME is the villen. Your net MUST be able to sense collisions within a reasonable period of time or you will have undetected collisions which equal garbage at the receiving end. It's been a long day, plesae ignore the spelling errors. William H. Magill Operations Manager Computing and Educational Technology Services (CETS) (formerly Moore School Computing Facility - MSCF) School of Engineering and Applied Sciences (SEAS) University of Pennsylvania Office Mailing Address: William H. Magill 215/898-4707 CETS 200 South 33rd Street Philadelphia, PA 19104-6314 Network addresses: SEASnet: Magill@eniac PENNnet: Magill@eniac Internet: Magill@eniac.seas.upenn.edu -or- Magill@upenn.edu BITnet: Magill@pennlrsm