🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Ron Rusnak Tue, 01 Oct 1985 23:45
Codenoll 2020 to 3Com 3C400 Multibus problem
#890
Author: Ron Rusnak
Date: Tue, 01 Oct 1985 23:45
17 lines
1180 bytes
We have built several ethernet gateways using 68000 multibus
and 3com multibus ethernet controllers.  They work quite 
well when connected to coax transceivers.  We are now
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.  

Both the 3com controllers and the Codenoll transceivers claim
to meet Ethernet 1.0 specifications. 

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
Re: Codenoll 2020 to 3Com 3C400 Multibus problem
#892
Author: Rob Warnock
Date: Thu, 03 Oct 1985 17:39
53 lines
3316 bytes
+---------------
| ...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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads