ronr@sphinx.UChicago.UUCP (Ron Rusnak) (10/02/85)
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
rpw3@redwood.UUCP (Rob Warnock) (10/03/85)
+--------------- | ...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