Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!nike!ucbcad!ucbvax!amdcad.UUCP!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: mod.protocols.tcp-ip
Subject: Ethernet carrier sense during transmit
Message-ID: <8609300147.AA08651@amdcad.UUCP>
Date: Mon, 29-Sep-86 21:47:25 EDT
Article-I.D.: amdcad.8609300147.AA08651
Posted: Mon Sep 29 21:47:25 1986
Date-Received: Thu, 2-Oct-86 19:53:31 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 25
Approved: tcp-ip@sri-nic.arpa

Terry Slattery asks "<should> the interface monitor carrier during
transmit?" I have reviewed the 802.3 spec and see no requirement to do
so. (But I still find the language of the spec a bit confusing so I
may have overlooked it.)

The Ethernet 2 spec calls for a CarrierSenseTest process on page 53
which reports if carrier disappears while transmitting or if it never
appears during an entire transmission.  It does not seem to be used.

Is Codenoll without fault? Ethernet assumes a certain maximum
transceiver cable length and a certain minimum signal propagation
velocity. The transceiver is supposed to send to the controller
everything which appears on the cable. One may conclude that carrier
should be present during transmission. The advantage of monitoring the
presence of carrier is that you have more information with which to
perform problem isolation. 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.

This is not to say the Codenoll product is bad or that you shouldn't
use it. However, I will be cautious whenever someone proposes breaking
one of the Ethernet configuration rules. If someone does break the
rules and has a failure, then that would be one of the first places to
look at.