From: mwr@tridom.uucp (Mark Reardon)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Should SQE test be disabled or enabled when connected to a Cisco?
Date: 24 Jul 92 15:32:36 GMT
Reply-To: mwr@tridom.uucp (Mark Reardon)
Organization: AT&T Tridom; Marietta, Georgia

In article <1992Jul21.144716.4064@midway.uchicago.edu>, chris@gargoyle.uchicago.edu (Chris Johnston) writes:
|> In article <1992Jul20.081403.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:
|> >In article <1992Jul17.190752.21847@midway.uchicago.edu>, chris@gargoyle.uchicago.edu (Chris Johnston) writes:
|> >> 
|> >> I always turn SQE/Heartbeat OFF for every transceiver.  
|> >
|> >This sort of thing really frustrates me.
|> >SQE IS THERE FOR A REASON! TURNING IT OFF IS ASKING FOR TROUBLE!
|> > [several paragraphs deleted]
|> >
|> >R. Kevin Oberman			Lawrence Livermore National Laboratory
|> >Internet: koberman@llnl.gov		(510) 422-6955
|> 
|> 802.3 standard lawyers not withstanding, using the same signal to
|> indicate both "Collision" and "Transceiver OK" is a MAJOR DESIGN FLAW.
SQE is not "Tranceiver OK". It is instead "tranceiver to station collision
signal functional".  How else do you test this than by sending a signal
through the wire?

|> 
|> I'm still waiting for someone to tell me exactly why turning SQE off
|> on every transceiver is a bad idea...  I am relieved to learn that
|> most, if not all, software/firmware ignores SQE even when it is
|> enabled.  
The reason for it to be on is so that this test is performed.  Bad
AUI cables and tranceivers can be detected by this test.  Running
without it is the equivalent of using a table saw without a blade
guard.  It works well but has its risks.  In addition, software that
ignores SQE is poor software.  The driver should at least count the
errors and let the user view the count at their option.  Also, since
most chips require that the bit in the controller be cleared after
each transmission, not have SQE on adds to the nodes software overhead.

|> 
|> For now SQE stays disabled on my net.  The risk of losing one computer
|> is trivial compared to the risk of losing the entire network.  (I'm
|> always open to and invite arguements against this policy.)
I don't understand this statement.  If a tranceiver can't tell a host
that a collision has occurred, that host will be misbehaving.  It can
take a network to a crawl and it (the host) will not know that its own
transmissions have been garbled.  I know of at least one system 
administrator that lost his job because a faulty tranceiver caused his
network to not function properly for a couple of days.  Once his superiors
knew that the problem could have been avoided with proper wiring, they
decided to hire someone to do the job right.

How do you find faulty collision detection circuitry without SQE?  How
do you even know that is your problem?  What harm does using SQE cause?
|> 
|> IMPORTANT: Remember, the standard does say turn off SQE/Heartbeat/Jam
|> when connecting a transceiver to a repeater or hub.  If you forget
|> this your throughput will be very poor.
Agreed, and in the spec.

|> 
|> cj
|> 
|> Chris Johnston AM Investors work312-786-4889 home312-761-0091
|> 
|> If you are "humor challenged" please ignore the following.
|> Standards?  We don't need no stinking standards.
After all, It's magic.
|> ...and remember, please don't try this at home I'm a professional. :-)

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 
From: mmoore@hpcc01.corp.hp.com (Mike Moore)
Date: Wed, 29 Jul 1992 04:07:16 GMT
Subject: Re: High speed serial interface
Organization: Hewlett Packard