Re: Ethernet carrier sense during transmit


Phil Ngai (amdcad!phil@decwrl.DEC.COM)
Fri, 3 Oct 86 20:20:37 pdt


> "..... Ethernet assumes a certain maximum transceiver cable length and a
> certain minimum signal propagation velocity .... The Codenoll system alters
> the parameters which permit the monitoring of carrier. As such, calling it
> "Ethernet" or "Ethernet compatible" could be misleading and could cause
> network failures which are hard to diagnose such as your case. ...... "
>
> I am curious as to how the Remote LANBridge function in conjunction with the
> DEC remote repeater. Does the AMD chip inside the LANbridge, pointing to the
> direction of the long fibre link, programmed to carry out the
> CarrierSenseTest ?

First a disclaimer. I do not represent the company in this forum. I am
only stating an opinion based on my understanding of networks. Further
more, I do not know how the DEC LAN Bridge 100 operates.

The LANCE data sheet says it wants to see carrier during a
transmission. If it ever sees a loss of carrier, it will set a status
bit, bit 11 (LCAR) in Transmit Message Descriptor 3 (TMD3). It will
continue to transmit the whole packet until done. This seems similar
to its handling of SQE. (lack of SQE sets a bit in a register but does
nothing else.) Conditions are detected and available for interrogation
by software but as little of the protocol is enforced by hardware as
possible, where this does not put an undue burden on software.

DEC probably just ignores LCAR on the LANCE which drives the fiber
interface.

By the way, I heard a very clever use of the LANCE. In a bridge, it
would be fair to get more of the bandwidth than a normal station gets.
You can disable the retry on a LANCE and implement your own truncated
binary backoff with shorter time constants in software.

> Furthermore, it is my contention that doing a CarrierSenseTest is probably a
> good thing but the timing is questionable bearing in mind that the 50 meter
> transciever cable distance is really a function of DC power attenuation
> between the controller an the transceiver. If the tranceiver is locally
> powered, that distance limitation would not have applied. The only relevant
> number will then be the 51.2 microseconds (512 bits) slot time.

Yes, there are many ways to break the Ethernet configuration rules and
(temporarily) get away with it. Actually, the 50 meter transceiver
cable distance is due to both DC and AC signal attenuation. The AC
signal attenuation is, in fact, a more severe requirement.

                        Belden 9891:
DC resistance 10 MHz attenuation
9.3 ohm/1000feet 2.1 dB/100 feet

                        Ethernet spec:
4 ohms max 3 dB max

                        Allowed length:
4000/9.3 = 3/2.1 =
430 feet roundtrip = 143 feet
215 feet
(ignoring connector resistance)

50 meters is 164 feet.

But I digress. The point is, given two incompatible implementations, I
would side with the one that didn't break any rules, at least with
regard to whether it should be called Ethernet or 802.3.

I am also against the philosophy of "as long as it's less than a slot
time you can do anything you feel like". In a large network where
personnel come and go, it is very likely that a shortcut taken in one
area will be forgotten and badly burn someone (many people?) somewhere
down the line. It's all very nice to document what you did but I
think there was a reason DIX came up with the configuration rules in
the first place. Otherwise, they could just have said "here, don't
violate the slot time and have fun". But they knew it would be much
less error prone to establish some simple, conservative configuration
rules. It's very easy to poke holes in them. They were designed to be
conservative. And I think in a network where downtime affects the
entire computing community, erring on the side of too much safety
margin is worth it.

It's true that standards retard the advancement of the state of the
art. As a system engineer, I am more concerned with connectivity than
an occasional local optimization, particularly if it means the whole
network is affected or threatened. This is even more true with the
advent of devices like the LAN Bridge 100 which allow full Ethernet
speed over extended geographic distances. There's no longer any excuse
to cheat the specs to get an extra 500 meters or whatever.

        Phil Ngai



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:58 GMT