Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!mintaka!mit-eddie!rutgers!bellcore!jupiter!karn
From: karn@jupiter..bellcore.com (Phil R. Karn)
Newsgroups: comp.dcom.lans
Subject: Re: SQE and strange behavior
Keywords: SQE
Message-ID: <19024@bellcore.bellcore.com>
Date: 17 Jan 90 00:33:58 GMT
References: <408@skipper.dfrf.nasa.gov>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 25

In article <408@skipper.dfrf.nasa.gov> rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) writes:
>We recently observed some bizarre behavior on our net.
>The problem is solved, but we still don't fully understand
>the cause.  It may be very clear to someone who understands
>repeaters and heartbeat-SQE.

SQE is an "enhancement" that was made to Ethernet when it was
standardized as IEEE 802.3. Basically, it calls for the transceiver to
pulse the collision detect pair to the controller after each packet has
been transmitted "in order to make sure the pair is still working". The
problem is that some older controllers may interpret this signal as
indicating a collision, treating it as an unsuccessful transmission when
in fact it went out fine.

As with the SAP encapsulation scheme used in IEEE 802.3, SQE is a
gratuitous, brain-damaged idea that never should have seen the light of
day. The subtle incompatibilies between DIX Ethernet and IEEE 802.3 have
caused nothing but grief, but I guess the committee could not just leave
well enough alone.

We use lots of DIX Ethernet hardware around here, along with the
original encapsulation scheme. Whenever I install a new transceiver that
has the SQE option, I always turn it off. Everything works just fine.

Phil