[net.lan] Ethernet cable length query

mark@cbosgd.UUCP (Mark Horton) (03/20/84)

We are considering a 500 foot Ethernet.  There are two possible
configurations: a single 500 foot length of cable, and 5 100
foot lengths.  There are obvious advantages to the 5 100 foot
lengths when running the cable in the ceiling.  We can also get
delivery on 100 foot teflon (fire regulations) pieces much faster
than a single 500 foot length.  Apparently the price would be about
the same per foot either way.

My question is, will there be any noticable increase in noise due to
all the extra connectors in there?  What if the Ethernet grows past
500 feet - will it become more of a problem?

Any advice on which of the two courses makes more sense would be
appreciated.

	Mark Horton

darrelj@sdcrdcf.UUCP (Darrel VanBuer) (03/21/84)

The Ethernet specification requires random pieces of Ethernet cable to be
1 or 3 or 5 times 23.4 meters (76.8 feet) in length.  The rules are less
stringent for a single piece of cable or cable entirely from a single lot.
The rationale is that different lots of cable have slightly different
impedences, resulting in reflections at each splice.  23.4 meters is one
bit time, so this keeps reflections on bit boundaries, or even provide
destructive interference with the reflections.  (By the way, these
guidelines are not guaranteed; if you want to be SURE of a given cable
assembly, sweep testing of SWR is recommended)

-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA

salkind@cmcl2.UUCP (03/24/84)

At NYU, we are running Interlan and DEUNA boards (on VAXen) with good
success.

rpw3@fortune.UUCP (03/25/84)

#R:cbosgd:-111500:fortune:5900005:000:2640
fortune!rpw3    Mar 25 00:14:00 1984

The reason the rules are less stringent for single lot cable is
that the rules are primarily concerned with step discontinuities
in the characteristic impedance. Different lots of cable can vary
several ohms (even a single piece can wander up and down a little).
But Mark, if you are concerned primarily about maintainability of
the installed cable, buy your cable in one big roll, cut it up just
about any way you want, and don't worry. Buy as much now as you can
afford and that you think you will use for several years.

To be real picky, put your cuts on 2.5 meter boundaries (at one of the
little annular ring markings). This way, your cuts look like 3com
transceivers with nothing in them! ;-}  [Besides, you can always
put in-line transceivers (such as 3com's) at the cut-points later.]
Be sure to use the standard N-type males one the cable, with barrel
females between.

When we wired up our the Twin Dolphin building before we moved in,
we did that -- bought one big piece but installed it as several
concatenated sections. (Not enough experience yet to know the effect.)
You have to start pushing (or exceeding) the 100-transceiver/500-meter
(not feet) limits before you're going to see any problems. Friends at
Xerox/PARC tell me they've got one 10 Mb/s link running with 160 transceivers
on it at 600+ meters, and it's o.k. No guarantee; your mileage may differ.

Other tips: MAKE SURE you get a blueprint with the routing of the cable
on it, preferably (as we did) with the 2.5 meter spots marked on it
(actually, the print only shows every third one). That way, when you have
problems, a TDR from one end can pinpoint the trouble to within a couple
of ladder shiftings (yes it's a new technical term... ;-} "a couple of turns
at climbing UP the ladder, then DOWN the ladder, then MOVE the ladder").

Let's see... remember that transceivers can be 50 METERS from the station,
so don't be to worried about snaking cable into every little corner.

Also, loop the cable around so that both ends are in the machine room, or
the comm lab, or someplace where you can get at them easily. Make sure the
joins in the cable are centered over open corridor, etc.. Basically, sit
down and think for 3 or 4 minutes about how you are going to wish you had
done it, a year or two from now. Imagine some horrid scenario of the Big Boss
coming upstairs with the Important Visitors and you just got a shorted
transceiver "somewhere" in the net. There. Go build it like that.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065

mark@cbosgd.UUCP (Mark Horton) (03/25/84)

I am very grateful for all the replies.  What's been posted summarizes
the situation pretty well.  (Yes, we know the limit is 500 or 1K or 2.5K
meters, depending on who you talk to and what kinds of repeaters you
use, but we happen to only need 500 feet.)

Another interesting question has come up here.  The type of tap.
We have Interlan "vampire" taps.  I've been told that the 3-Com
tap, which you screw in between two cable segments, is much better.
Since our taps currently don't seem to work (probably a bad
drilling or improperly installed tap, the directions were pretty
poor when it came to specifying how far to tighten down the clamp
("do not overtighten" indeed!) and I don't know how to adjust the
other screw that controls the position of the top probe.  We also
don't know how to diagnose a bad tap - I would like to be able to
use an ohmmeter or the like to track it down but don't know what
to check.  When you're new to this game you don't necessarily know
what you are doing.  I was quite surprised to find that plugging
in the tap to the board on our 750 causes the 750 to reboot.  This
is not true of our 730.  Does this mean the 750 tap is shorted or
something like that?

Others seem to feel that vampire taps are wonderful.  The major
advantage I can see is that with 3-Com taps, you have to cut the
cable (or at least unscrew it) to add a new tap, which takes the
network down.  I gather that DEC sells vampire taps.  Does anybody
except 3-Com sell the screw-in type?  I'd be interested in opinions
on which type is better and who to buy them from.

I can say one thing for sure - going up in the ceiling and drilling
into ethernet cable with these heavy duty cables and boxes is a
gigantic pain in the wazoo.

	Mark

mark@umcp-cs.UUCP (03/26/84)

Why should both ends of the ethernet cable be in the machine room?
Sheesh, you might as well have a RING!
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!mark

zben@umcp-cs.UUCP (03/26/84)

^Why should both ends of the ethernet cable be in the machine room?
^Sheesh, you might as well have a RING!

So if it goes open somewhere you have the choice of which half of your
network you can talk to?...

So you have two places to make TDR measurements from?...

As an ex-engineer the naivete of some theoretical types amazes me.
When it doesn't scare me...

Ben Cranston        ...seismo!umcp-cs!zben        zben@umd2.ARPA

james@umcp-cs.UUCP (03/26/84)

But when the cable gets opened somewhere, how can you talk to either
half of the network?  Doesn't ethernet cable have to be properly
terminated to prevent all signals from bouncing back from the open
point?

  --Jim

zben@umcp-cs.UUCP (03/26/84)

^  But when the cable gets opened somewhere, how can you talk to either
^  half of the network?  Doesn't ethernet cable have to be properly
^  terminated to prevent all signals from bouncing back from the open
^  point?

Um, er, well, depending on the material and length of cable and the exact
topology of the net, it might or might not work with the cable unterminated.
I would still try it, to get the network up, and if it didn't work go on to
find and repair the cable.  If I can get it up at noon, I can go fix it that
night when it won't cost my company productivity...

Still, I stand chastened.  I interpreted the original article as a gratuitous
attack on some working stiff who, after all, took his time to write what 
looked like a fairly informative article to spare some newcomer-to-networks
some stress.  Such are fair game for my flame...

Ben Cranston       ...seismo!umcp-cs!zben         zben@umd2.ARPA

dmmartindale@watcgl.UUCP (Dave Martindale) (03/26/84)

You can always turn a "vampire" tap into the other type by taking a few
feet of Ethernet cable, putting appropriate connectors on each end, and
attaching the "vampire" tap to it.  But I would expect that the vampire
tap causes the least impedance disturbance in the cable, since it doesn't
involve adding two connectors and a non-homogeneous piece of cable every
time a transceiver is added to the network.

When DEC installed our transceivers, they had problems with the drilled
holes shorting out the cables.  I note that the catalog says that the
installation kit includes "braid terminators".  I don't remember DEC
installing anything that would fit that description.  Does anyone know what
they are?

Anyway, to check your transceiver's connection:  If you have transceiver
housings made by AMP, at least, the transceiver board connects to the cable
by 3 pins in the housing and receptacles for these pins on the circuit
board.  Take the cover off the transceiver housing, pull the circuit board
straight out of the housing, and the three pins will be obvious.  The outer
two should be connected to the cable ground; check with an ohmmeter between
them and the ground of the nearest cable end.  The centre pin is the centre
conductor of the cable, and an ohmmeter reading between there and the
centre pin of the cable end connector should show only a couple of ohms.
Finally, the resistance from the centre to either outer pin should be
either infinity, 50, or 25 ohms, depending on whether 0, 1, or 2 terminators
are installed on the cable segment in question.  If any of these measurements
is incorrect, that should tell you that there is a short or open somewhere.
An open is easy, a short between the signal and ground conductors in
the cable means that there is a short somewhere along the cable.  It's
probably at one of the transceivers, but don't overlook the terminators
either.  We had intermittent shorts caused by metal chips in the terminator,
caused by someone using a wrench or pliers to tighten the cable connector.
(They should be hand-tight only)

The clamp bolts on the transceiver are just there to hold the clamp together.
"Snug" is probably the best way to describe the proper torque.  The
screw in the centre of the clamp cover is a pin which pushes the
centre conductor of the cable into firm contact with a pin in the transceiver
housing.  It should be tightened firmly enough to make good electrical
contact.

darrelj@sdcrdcf.UUCP (Darrel VanBuer) (03/26/84)

There are three distinct kinds of Ethernet tranceivers (not counting devices
like a box to replace 8 tranceivers in a small region):
Connectorized tranceivers (like 3-Com):  a real pain to insert or remove
since it partition your net for several minutes (especially if you have to
install a pair of new connectors).
Interlan vampires (also used by DEC):  a big plastic box which is bolted to
  the side of the cable (with a rather expensive instalation kit)
Xerox vampires (currently made by TCL):  the cable tap is a small two-piece
metal clamp which bolts to the cable and has a small threaded hole at right
angles to the cable.  The (cheaper) installation tools cut thru the
insulation and braid under the hole (with a small circular saw), finally
you screw the tranceiver (a metal box the size of two packs of cigarettes)
into the hole.  The tranceiver has a sharp stinger which pierces the
insulation to make contact with the center.  With great care in cleaning
loose bits of braid from the bottom of the hole, these can be installed
without disrupting the net.  Also, extra clamps are only about $10 each,
making it cheap to have "floating" tranceivers.  My bias is toward these
because this was the only kind on the old Experimental ethernet, and they're
the least expensive.
On "too tight": with the Xerox type, at least, the force needed to screw in
a tranceiver goes up an order of magnitude when it bottoms out in the hole,
so you can't miss it.  One problem with the old taps was the rubber O-ring
that came with the cable taps.  The installation directions  (from the tap
manufacturer) say be sure to use it.  The verbal directions from Xerox
(confirmed in practice) is don't use it because it keeps you from screwing
the tranceiver in far enough, resulting in poor center contact.  This may
not be a problem with the new stuff.

On crashing a 750 by connecting a tranceiver to it:  this is a previously
reported problem.  Basically, the Unibus in a 750 doesn't have enough
+15 volt power to stand the starting inrush demanded by the tranceiver,
and apparently doesn't depend on brand of tranceiver.

-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA

dmmartindale@watcgl.UUCP (Dave Martindale) (03/26/84)

When the cable goes open, you can't talk to it at all.  When a transceiver
transmits, its output has a DC offset as well as an AC signal component.
This is used for collision detection, since DC from two sources adds in
a much more predictable way than two sources of AC.
If one of the terminators is missing, the DC offset on the cable is twice
what it should be for a single transceiver transmitting, and the transceiver
detects it as a collision.

rentsch@unc.UUCP (Tim Rentsch) (03/27/84)

Interesting that connecting your transceiver tap causes your 750 to reboot,
whose controller are you using?  (For that matter, which driver are you
using?  The standard 4.2 one?)

My experience with transceivers is that any idiot can use 3Com transceivers
and make them work (at least this idiot could), but some finesse is required
for the pressure tap kind.  Most of the pressure tap kind (DEC, Interlan,
...?) are physically similar and I have heard that they are all made by a
separate company (Singer, as I recall).  Quite plausible, from my handling
of Interlan transceivers and looking at photographs of the DEC stuff.  I
have heard of a pressure tap transceiver that is spring loaded and so
"cannot" be overtightened.  Personally, I would recommend the connectorizing
(aka 3Com) type, once you realize that the cable should never be cut but
just screwed and unscrewed.

Another thing:  there are at least two companies (DEC and TCL) that make a
box (DEC calls its box a DELNI) which allow multiple controllers to be
plugged into a single xcvr.  In fact, as long as you can fit all your
devices (maximum of 8) into the one box, the cable is optional.  (Just try
explaining to your boss that you are getting an ethernet without the ether.)
Both DEC and TCL's boxes can be cascaded another level, making a total of 64
devices running off of one xcvr.  One very appropriate use for these things
is to get around the problem of having to run scads of wire when all you
really need is scads of xcvr outlets.  Or use them for after-the-fact
reconfiguring (e.g., more devices in a single office).

Tim

rpw3@fortune.UUCP (03/27/84)

#R:cbosgd:-115100:fortune:5900007:000:962
fortune!rpw3    Mar 26 22:43:00 1984

You put both ends in the machine room so when the day comes that you
finally have to split the net in two (due to too many transceivers) and
you want to have two pieces with a repeater between, you have a nice table
to mount the repeater on! (Sheeesh! Do I have to think of EVERYTHING?)

;-}

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065

p.s.
Seriously, sometimes it helps (yes) to be able to TDR from both ends, since
after you've got a whole bunch of transceivers attached the TDR ain't always
that accurate. Do it from both ends (leaving the far end UNterminated each
time, to make a clear marker), and you can save some ladder shuffling trying
to pin it down to that last couple of meters.

And yes, you have to terminate the cable. HAVE TO! But when you broke the
cable in two, didn't YOU install terminators on the "new" ends?? ;-}

rpw3@fortune.UUCP (03/27/84)

#R:watcgl:-230900:fortune:5900008:000:1534
fortune!rpw3    Mar 26 23:05:00 1984

The "braid terminators" on the AMP taps are little pieces of spring
metal with teeth on them that are supposed to bite into the cable
shield/braid to make a good cable ground (NOT building ground, pul-eez).

The AMP-style taps are supposed to come with 3 or 4 of these thingies,
because they're only good for ONE use. You should use a fresh one if
you ever move the tap.

----------------[new subject]----------------------------------------

Besides DEC and Interlan (AMP tap) and 3com (in-line with cable), you might
want to check out transceivers from TCL Incorporated, 2064-B Walsh Ave,
Santa Clara, CA. 95050 Phone:(408)727-3800

This isn't an ad, but they seem to consistently get left out of the
discussions, and they WERE after all the first volume manufacturer of
the 3 Mbit devices and are still Xerox's biggest supplier for the 10 Mbit
transceivers.

They use a modified Gerrold CATV tap, wherein the transceiver screws
onto the tap after the cable's been prep'd. The old stinger got a bad
reputation for opening up when people wiggled the cable a lot(!), but for
about $5 more they now sell you a "new improved" tap with an "Energy
Stinger" (spring loaded) which is said to completely solve the problem.
The price isn't bad, either: $232.80 (quan. 1) for the new transceiver/tap.
They also give good quantity discounts: 30% @ 100, 35% @ 250, 40% @ 500.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065

dmmartindale@watcgl.UUCP (Dave Martindale) (03/27/84)

Not all of us have TDR (time-domain reflectometry) equipment at hand to
help find Ethernet cable faults.  The DEC DEUNA Ethernet interfaces,
however, do have a "TDR" register which is supposed to give some sort
of tdr info if all its retries failed.  I expect it is some measure of
the time elapsed between the transceiver starting up and the ocurrence
of the "collision detect" signal.

Now, does anyone know how to interpret this value?  The manuals say
nothing useful, and I haven't been able to make any sense out of the
values I've observed.

	Dave Martindale
	{decvax,allegra,ihnp4,clyde}!watmath!dmmartindale

dmmartindale@watcgl.UUCP (Dave Martindale) (03/27/84)

I have heard that VAX 750's have 15volt power supplies which are barely
adequate for driving the Ethernet transceivers.  And, the transceivers
will have their own local filter capacitors for that incoming power,
so there will be a current surge when they are plugged in.  When DEC
installs a DEUNA and transceiver, a small panel is installed on the
back of the machine to provide the connection between the transceiver
cable and the short cable which goes the rest of the way into the
Unibus box to the transceiver.  This panel contains a current limiter
which prevents this large initial drain on the 15V supply.

If you are using someone else's Ethernet board which doesn't have this
current limiter, you are probably causing the 15V supply to drop so
low that the machine detects a power failure and reboots.

The problem with the DELNI Ethernet-without-the-cable is that it costs
approximately as much as 4 transceivers.  At Waterloo, we had to buy
Ethernet cable since not all of the machines to be connected were even
on the same floor.  There are 3 machines in the same room, but it is
cheaper to buy 3 transceivers than 1 DELNI and the one transceiver to
connect it to the main cable.  So the breakeven point where a DELNI
becomes worthwhile is about 4 machines in the same room if that is the
whole network, and 5 machines if they have to talk to a cable anyway.
Not nearly as attractive as one might have hoped.

smb@ulysses.UUCP (Steven Bellovin) (03/28/84)

What sort of experience do folks have mixing different brands of
transceivers and controllers?  I learned (the hard way, of course) that
the DEC DEUNA will not work with a 3Com transceiver, for example -- and
DEC warns you that they won't guarantee performance of the DEUNA with
*anyone* else's transceiver.

		--Steve Bellovin

rpw3@fortune.UUCP (03/29/84)

#R:watcgl:-232100:fortune:5900009:000:4713
fortune!rpw3    Mar 28 22:01:00 1984

In fact, MOST of the Ethernet chips have some sort of TDR register, and
where they don't, it is easy for the designer to add one externally (as,
for example, outside the Seeq chip).  They aren't really "Time Domain
Reflectometers", but the effect is similar.

The way they work it quite simple, but has a irritating limitation.
The "TDR" register simply counts the number of bit times from the start
of transmission until the collision-detect signal comes back from the
transceiver. Simple. If all your stations report continuous "failure to
send after 16 collisions", you probably have a solid fault in the cable
somewhere, and the "TDR" numbers will tell you how far from the station.
Get "TDR" reading from two stations to resolve the ambiguity of which
direction down the cable has the fault.

Now the catch. Since they are counting transmission bit times, the
resolution is about 100 nanseconds, or about 20 meters (65 feet).
And since the collision-detect signal is normally generated by an
unsynchronized clock in the transceiver (yes!), that doubles the
uncertainty, to 40 meters or so. But since they are measuring round-trip
times, the actual uncertainty is half that. (Got that? Back to 20 meters...)
Since transceivers may be spaced as close as 2.5 meters, that's still
a lot of poking around up in the ceiling!

What you need to do is attempt to transmit from a given station several
times, and take the LOWEST value reported from the "TDR" register. This
will hopefully remove the uncertainty caused by the unsynchronized
transceiver oscillator. This should lower the uncertainty to about 10 meters
(~30 feet). Do this for several stations. Remember to subtract the transceiver
cable length from each station to the cable when converting "TDR" numbers to
distance. There should be no more than four or five taps in the area
thus pointed to. Example:

	Terminator						Terminator
                    <--25m-><-25m-><-10m-><---37.5m--><-5m->
	   R--------X-------X------X--X--X------------X----X--------R
		    |       |      |  |  |            |    |
	+---+	    |       B      C  D  E        10m |    G
	| A +-------+                               +-+-+
	+---+  20m                                  | F |
		                                    +---+

Suppose station A's TDR flickers between 8 and 10, and station F's flickers
between 5 and 7. Then allowing that a count of 8 COULD be as low as 7.001
rounded up, you can assume that the problem is not less than about
(7 * 100ns)/(5 ns/m) ~= 140m or 70 meters one-way from A, and likewise
not less than (4 * 100)/5/2 ~= 40 meters one-way from F. (It could be as much
as 20 meters further from each if you only took a few samples, but it's not
likely.) Looking at the map, you should check out taps C, D, and E.

One further note: Each brand of network controller and each brand of
transceiver will have it's own particular "start-up delay" in both the
transmission path and the collision-detection path, which will result in
a constant (positive) offset in the TDR register values of 4-5 or more bits.
When you are first setting up your network, you should check this out by
forcing a failure (take off a terminator resistor, for example) and noting
the minimum values. (You MAY be able to do this on a transceiver that's
simply not connected to the Ethernet cable, but "clever" transceivers may
be able to detect that condition. If this DOES work, it will automatically
take care of the length of the transceiver cable for you, so don't count
that twice.)

True TDR's (Time Domain Reflectometers) are calibrated oscilloscopes with
fast rise-time pulse generators in them. Depending on price, their accuracy
and resolution can be as good as a few centimeters. Not only that, but you
will be able to SEE all of the good splices and taps between the TDR and the
fault (as little bumps in the trace), so that the fault can be located
relative to the nearest known tap/splice, rather than in absolute distance
from one end. A large site should probably invest in one of them to be kept
in the main machine room at one end of the cable, where the end terminator
can be taken off to do measurements on the (hopefully) rare event of the whole
net going down. MAKE SURE you keep an accurate cable map up-to-date, marked
with all your transceivers and splices in meters from one end.

Having said all of the caveats, the "TDR" register feature IS quite useful
if used properly, and using it properly is no problem once you have made
a few baseline notes. Don't buy a controller without one.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065

rpw3@fortune.UUCP (03/29/84)

#R:watcgl:-232100:fortune:5900011:000:4723
fortune!rpw3    Mar 29 02:01:00 1984

In fact, MOST of the Ethernet chips have some sort of TDR register, and
where they don't, it is easy for the designer to add one externally (as,
for example, outside the Seeq chip).  They aren't really "Time Domain
Reflectometers", but the effect is similar.

The way they work it is quite simple, but has a irritating limitation.
The "TDR" register simply counts the number of bit times from the start
of transmission until the collision-detect signal comes back from the
transceiver. Simple. If all your stations report continuous "failure to
send after 16 collisions", you probably have a solid fault in the cable
somewhere, and the "TDR" numbers will tell you how far from the station.
Get "TDR" readings from two stations to resolve the ambiguity of which
direction on the cable the fault is.

Now the catch. Since they are counting transmission bit times, the
resolution is about 100 nanseconds, or about 20 meters (65 feet).
And since the collision-detect signal is normally generated by an
unsynchronized clock in the transceiver (yes!), that doubles the
uncertainty, to 40 meters or so. But since they are measuring round-trip
times, the actual uncertainty is half that. (Got that? Back to 20 meters...)
Since transceivers may be spaced as close as 2.5 meters, that's still
a lot of poking around up in the ceiling!

What you need to do is attempt to transmit from a given station several
times, and take the LOWEST value reported from the "TDR" register. This
will hopefully remove the uncertainty caused by the unsynchronized
transceiver oscillator. This should lower the uncertainty to about 10 meters
(~30 feet). Do this for several stations. Remember to subtract the transceiver
cable length from each station to the cable when converting "TDR" numbers to
distance. There should be no more than four or five taps in the area
thus pointed to. Example:

	Terminator						Terminator
                    <--25m-><-25m-><-10m-><---37.5m--><-5m->
	   R--------X-------X------X--X--X------------X----X--------R
		    |       |      |  |  |            |    |
	+---+	    |       B      C  D  E        10m |    G
	| A +-------+                               +-+-+
	+---+  20m                                  | F |
		                                    +---+

Suppose station A's TDR flickers between 8 and 10, and station F's flickers
between 5 and 7. Then allowing that a count of 8 COULD be as low as 7.001
rounded up, you can assume that the problem is not less than about
(7 * 100ns)/(5 ns/m) ~= 140m or 70 meters one-way from A, and likewise
not less than (4 * 100)/5/2 ~= 40 meters one-way from F. (It could be as much
as 20 meters further from each if you only took a few samples, but it's not
likely.) Looking at the map, you should check out taps C, D, and E.

One further note: Each brand of network controller and each brand of
transceiver will have it's own particular "start-up delay" in both the
transmission path and the collision-detection path, which will result in
a constant (positive) offset in the TDR register values of 4-5 or more bits.
When you are first setting up your network, you should check this out by
forcing a failure (take off a terminator resistor, for example) and noting
the minimum values. (You MAY be able to do this on a transceiver that's
simply not connected to the Ethernet cable, but "clever" transceivers may
be able to detect that condition. If this DOES work, it will automatically
take care of the length of the transceiver cable for you, so don't count
that twice.)

True TDR's (Time Domain Reflectometers) are calibrated oscilloscopes with
fast rise-time pulse generators in them. Depending on price, their accuracy
and resolution can be as good as a few centimeters. Not only that, but you
will be able to SEE all of the splices and taps between the TDR and the fault
(as little bumps in the trace), so that the fault can be located relative to
the nearest known tap/splice, rather than in absolute distance from one end.
A large site should probably invest in one of them to be kept in the main
machine room (or wherever one end of the cable is), where the end terminator
can be taken off to do measurements on the (hopefully) rare event of the whole
net going down. MAKE SURE you keep an accurate cable map up-to-date, marked
with all your transceivers and splices in meters from one end.

Having said all of the caveats, the "TDR" register feature IS quite useful
if used properly, and using it properly is no problem once you have made
a few baseline notes. Don't buy a controller without one.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065

mark@umcp-cs.UUCP (03/30/84)

It seems to me that if the main reason to put both ends of the ethernet
cable in the machine room is to make TDR's easier, that is actually
a reason to have both ends accessible.  Accessibility is a considerably
weaker requirement than same roomness.  

This goes for the splitting and adding a repeater too.
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!mark

darrelj@sdcrdcf.UUCP (Darrel VanBuer) (03/30/84)

One important detail missed in the otherwise excelent article on TDR from
Fortune Systems:  Real ethernet coax is specified to use a foam dielectric,
resulting in a propagation speed of .78c (instead of .66c for a solid
dielectric).  As a result all the distances in the coax are 17% greater
than the figures they used.  The cables to the tranceiver, however do have
a speed of .66c.
1c   = 3E8    m/s = 15m/bit   round trip = 49.2 ft/bit round trip
.78c = 2.34E8 m/s = 11.7m/bit round trip = 38.4 ft/bit round trip
.66c = 2E8    m/s = 10m/bit   round trip = 32.5 ft/bit round trip

The propagation speed is supposed to be controlled withing about 1% in well
made cable.


-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA

teus@haring.UUCP (04/11/84)

Be carefull with swapping transceivers: f.i. you can not use a DEC DEUNA
board with a 3COM transceiver. Tranceiver cables can be swapped.
We have not tried an Interlan tranceiver on the different controllers
boards yet.
-- 
	Teus Hagen	teus@mcvax.UUCP  (CWI, Amsterdam)