Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!hplabs!hpda!fortune!redwood!rpw3
From: rpw3@redwood.UUCP (Rob Warnock)
Newsgroups: net.lan
Subject: Re: Codenoll 2020 to 3Com 3C400 Multibus problem
Message-ID: <219@redwood.UUCP>
Date: Thu, 3-Oct-85 13:39:56 EDT
Article-I.D.: redwood.219
Posted: Thu Oct  3 13:39:56 1985
Date-Received: Sun, 6-Oct-85 06:08:43 EDT
References: <1156@sphinx.UChicago.UUCP>
Organization: [Consultant], Foster City, CA
Lines: 53

+---------------
| ...trying to connect them to Codenoll 2020 fiber optic transceivers.
| The result is that the 3Com board's throughput drops by a factor
| of six. [compared to coax transceivers] 
| Has anyone out there run into a similar problem or does anyone
| have any advice on how to get around the problem?
|   Ron Rusnak (...!ihpn4!gargoyle!sphinx!ronr)
|   University of Chicago | Computation Center
+---------------

See if your throughput varies depending on the length of fiber cable
between the 2020 and the star coupler. If so, you may be running into
a similar problem some friends had recently with some fiber-optic
"transceiver cable extenders". The problem relates to the fact that
with a coax-based net, the controller board hears its own packet echoed
back to it not more than 3 bits later (50 meters * ~5 ns/m = 2.5 bits)
when the packet hits the coax at the transceiver, while in star-coupled
fiber nets (or coax nets with "long" fiber-extended transceiver cables)
the controller doesn't hear its own packet for approximately one round-trip
delay (as much as 500+ bits).

If the controller does something like, say, not finish the preamble
until it has heard the echo of the beginning of the preamble, that
would cause a length-dependent throughput variation. (I'm not saying
that that's what the 3Com board DOES, only that that's the sort of
thing that might explain what you're seeing.) ((Note: You can check
for this by looking at the transmitted packet with an oscilloscope.
It's easy enough to see the size of the preamble with a 'scope.))

In any case, you will need to check more closely with the manufacturer
of the controller. It's probably some "safety" feature in the controller.
Not all designs have trouble with "long"/virtual transceiver cables.
Sadly enough, if the algorithm is inside a VLSI chip, such as the Seeq,
Fujitsu, Intel, AMD, or Mostek chips, it may not be possible to fix it.
(Again, I do not know that any of those chips have such a problem.)

(Hmm... I just thought of a way to kludge it externally. Get the
transceiver to echo it "locally", but remember to ignore the delayed
true echo. Complicates collision handling. Details...)

With the increase in use of fiber-optic media (and other alternative
"transceiver cable compatible" media) this is a timely question. If you
find a answer to your problem (or even just a better explanation of the
problem), please let us all know.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	until 10/7/85: 510 Trinidad Lane, Foster City, CA  94404
	after 10/7/85: 627 26th Ave, San Mateo, CA  94403


Brought to you by Super Global Mega Corp .com