phil@amdcad.UUCP (Phil Ngai) (09/06/86)
DEC seems to have been less than diligent in informing their customers about what DELNI configurations are permissible. Granted, a lot of customers are of the "real programmers don't read the manual" type, but I have heard and heard of DEC employees giving bad information to customers. I personally have asked questions and gotten bad answers. When I talk to people I've never met before, I usually start out with questions I already know the answers to in order to "calibrate" the quality of the information I get. Based on my experience, you would not be wasting time if you confirm what someone tells you, even if they are a DEC employee. Even if they are sure they are right. Ask for references, page numbers from manuals or buyer's guides. Manuals aren't perfect either but they provide more confidence that this person has been trained in the subject they are talking about. In the July - September _Networks and Communications Buyer's Guide_, on page 2.44 (the page number depends on the date of your book, look up DELNI in the index), the second paragraph says: "The DELNI can be configured three ways: stand-alone, hierarchical stand-alone, and connected." Paragraph four says: "Hierarchical stand-alone configurations are not connected to the Ethernet coaxial cable." A lot of people have told me "we tried it and it works for us". This is undoubtedly true. However, it is still illegal. The configuration rules are conservative engineering guidelines. You can violate them in a small enough network and get away with it. If your network is a large enough network, you may discover the hard way why the configuration rules exist. I prefer to play it safe and follow the rules. If you chose to violate the rules, at least know which rules you are violating so that when something goes wrong, you know where to begin debugging. While we're talking about DELNI's, another poorly known rule is that in a CONNECTED configuration, the transceiver cable lengths add. If the maximum cable length for the controller is 40 meters and it's 15 meters from the transceiver to the DELNI, you only get 25 meters from the DELNI to the controller. See page 2.46. There also seems to be some confusion on why I want to connect a DELNI to a DEREP. We have 8 DEREP-RA (remote repeaters) coming together in one rack. Currently we have a lot of transceivers and a lot of coax coiled up on the wall. But gee, isn't that what a DELNI is for? Sorry, you can't connect a DEREP to a DELNI. Phil Ngai
cetron%utah-cbd@utah-cs.arpa (Ed Cetron) (09/08/86)
The facts as I have found them (both from all of the manuals as well as empirical results): 1. NOWHERE does it come out and actually say that cascading connected DELNI's is illegal.... 2. There IS a restriction that for signal propagation and timing considerations there can be no more than 2 repeaters between and two nodes on the ethernet. 3. In some ways the DELNI acts as a repeater, and in other ways it doesn't. 4. From item three stems the restriction of no DEREP to DELNI hookup since why hook a repeater to a repeater? 5. If you network HAS a repeater, than the DELNI -> DELNI -> cable -> DEREP -> cable DOES have more than two repeaters and MIGHT (since the DELNI is sort of a repeater) to violate the configuration rules.... 6. I have empirically determined that a DELNI is sort of a .6 - .75 of a repeater and have successfully cascaded the situation as in item 5 with no trouble and an ether
cetron%utah-cbd@utah-cs.arpa (Ed Cetron) (09/08/86)
sorry for the continuation....I had a terminal glitch which sent the message previous before its time.... (cont) 6. I have empirically determined that a DELNI is sort of a .6 - .75 of a repeater and have seen several successfully cascaded DELNIs as shown in the configuration above in item #5 work with no trouble on a network with both decnet and TCP/IP packets flying at a tremendous rate.... 7. I have seen stable networks with 3 cascaded DELNI's and NO DEREP's. 8. I have NOT seen networks that function with 3 cascaded DELNI's AND a DEREP.... 9. Configuration guidelines are just that, one should be willing to test 'illegal' configurations and verify whether or not they work - the specs are VERY conservative, and in many cases (except were life and limb are in danger) TOO conservative. -ed
Magill@CIS.UPENN.EDU (CETS Operations Manager) (09/30/86)
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