Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!ncs.dnd.ca!jstewart
From: jstewart@ncs.dnd.ca (John Stewart)
Newsgroups: comp.dcom.lans
Subject: Re: SQE and strange behavior
Message-ID: <734@ncs.dnd.ca>
Date: 18 Jan 90 17:03:17 GMT
References: <732@ncs.dnd.ca> <286@cfa.HARVARD.EDU>
Reply-To: jstewart@ncs.dnd.ca (John Stewart)
Organization: DREO, Ottawa, Ontario
Lines: 24

In article <286@cfa.HARVARD.EDU> wyatt@cfa.HARVARD.EDU (Bill Wyatt) writes:
...
>While disabling SQE may work for some devices, it's not a good idea.
>The use of SQE is necessary since data corruption and general havoc
>will ensue if a node's collision detection has failed. Data integrity 
>is a vital commodity on a shared bus!

It's been about 2 years since I last went thourgh the 802.3 spec, but I
seem to remember that the cd line would be used as the SQE for a certain
time period after transmission. So:

1) if no SQE, but the controller expects one, then the controller
   thinks that the tranceiver is dead.

2) if SQE, and the controller doesn't expect one, it will be interpreted
  as a collision, and the controller will try a re-transmit.

So, if the above is correct, then 1) above would seem to be the
lesser of two evils. Note that disabling SQE does not disable
the collision detect!

Am I correct, or should I get the spec for bed-time reading again?

John Stewart.