From: oberman@ptavv.llnl.gov
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: SQE, Once more
In article <1992Jul31.124357.10781@relay.nswc.navy.mil>, tdrake@relay.nswc.navy.mil (Tim Drake - E41) writes:
>
> I've read all the postings on SQE I've seen in the last two
> weeks (many). I'm still unclear on a few points. SQE should
> help me find problems in faulty MAU's, but how?? Say I'm working
> on a Unix system, what command will report the error's I shoud see
> if I have SQE turned on and the MAU is faulty. In short how can
> SQE help me find problems.
You've just hit one of my big gripes with vendors. Many, but not all U*ix OSes
simply ignore the SQE error. In this environment there is little you can do
with the fact that SQE is enabled except to complain loudly to the vendor.
For those systems that do count SQE errors, something like netstat should
return the counts. SNMP is a better way to get this information.
> My other confusion is if it looks like a collision to my MAU
> (the "CP collision packet" LED lights up) how does the system
> tell the difference between the "test" and an actual collision?
It's all a matter of timing. The SQE signal is generated immediately after a
packet is transmitted. During this interval the network is not (or should not)
be carrying any traffic. Since the SQE check is sent by the MAU itself, it
expects it and so does the controller.
> I must admit that we turn SQE off religiosly because of problems
> we had with it being enabled and connected to repeater equipment.
Amazing to me how many people don't read the instructions, hook up a MAU with
SQE enabled to a repeater, have it fail, and declare SQE a BAD THING to be
turned off all the time. I know of several sites that operate this way and I
think they are all crazy (or lazy).
If a driver counts SQE errors, as many do, turning off SQE has deprived you of
a significant tool for discovering network problems. If a driver does not count
SQE errors, the vendor has deprived you the tool and you should complain
LOUDLY!
R. Kevin Oberman Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov (510) 422-6955
Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
Newsgroups: comp.dcom.lans.ethernet
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: What is SQE?
Organization: Silicon Graphics, Inc. Mountain View, CA
timl@maxwell.concordia.ca (Tim Lapin) writes:
+---------------
| What is SQE? What does it mean?
| Does it generate packets, a line condition or something else entirely?
+---------------
It's called "Signal Quality Error" (SQE) in IEEE 802.3, but in the D/I/X
Ethernet 2.0 spec (Section 7.4.7) it's called the more understandable
"Collision Presence Test". [Still, everybody pronounces it "squee".]
The desire for it arose after Ethernet version 1.0 [which doesn't have it]
had been out and in use for a while, because of the following concern:
Since it is *possible* that in a lightly-loaded net there might never be
any collisions, the situation of never getting a Collision Presence signal
from the transceiver cannot by itself be considered an error. So how can
you tell if the Collision Presence wires from the transceiver to the station
are broken or shorted? [Standards committees worry about these things. ;-} ]
The solution (not provided in Ethernet 1.0, but present in Ethernet 2.0
and IEEE 802.3) is to force a signal onto the Collision Presence pair to
"test" it every so often, so that a failure of the Collision Presence pair
would be noticed even when there were no collisions.
But of course, that "test" signal must be at a time when the Collision
Presence pair is not being used to signal Collision Presence! The solution
they chose was to redefine the meaning of the Collision Presence pair
during a small interval after the end of the transmission of a packet.
The transceiver would emit a small burst of Collision Presence signal
during that interval unconditionally. The station (host) could look for
that signal during that interval (after a transmit), and if it *didn't*
see it, set a "Signal Quality Error" flag in a status register somewhere,
so that network maintenance people could come fix the transceiver (or the
cable, or the station).
[By the way, this is a very reasonable time to pick. If the station's not
transmitting, you don't really care if the Collision Presence pair isn't
working, and if it *is* transmitting, you get to test it on every packet!]
As things have a way of doing, the term "SQE" (a.k.a. "squee") has come to
mean informally the burst of Collision Presence signal itself, rather than
the *absence* of that signal. And the self-redundant phrase "SQE error" gets
used to mean the absence of the "SQE" signal. (Oh, well. Worse things have
happened.) So that when someone says a certain transceiver has "SQE enabled",
that means that the transceiver will emit the burst of Collision Presence
signal after its station transmits.
Oops! I almost reinforced another one of the common myths. I said, "the
transceiver will emit the burst of Collision Presence signal". It does,
but NOT ONTO THE ETHERNET! The SQE signal goes *only* to the attached
station, via the Collision Presence pair. From the Ethernet side of a
transceiver (thick cable, thin cable, 10baseT), it is *not* possible
to tell whether the transceiver has SQE enabled or not.
So why would one ever want to disable SQE? Several reasons:
1. There are still Ethernet 1.0 stations out there. Since Ethernet 1.0
did not define the SQE function, sending a burst of signal on the
Collision Presence pair after transmit will be seen by an Ethernet 1.0
station as a "late collision", a serious error usually indicating
a serious configuration mistake, or broken hardware. [So disable SQE
on transceivers you connect to Ethernet 1.0 stations.]
2. Some brands of "transceiver multiplexers" (e.g., DEC DELNI or "TCL boxes",
though I don't know if they have the problem) have a nasty habit of
broadcasting the SQE to *all* the attached stations, rather than the
one(s) that have just finished transmitting [even though doing it right
only costs about $2.00 worth of logic gates per hub]. This can seriously
confuse those stations that *weren't* transmitting into thinking there
was a "collision" when there wasn't. [So disable SQE on transceivers
connected to such "evil" multiplexers.]
3. Some Ethernet repeaters do not have a "bullet-proof" state machine,
and can be confused by the SQE [though it *is* possible to build a
repeater that is not so confused]. They confuse SQE with "receiver-based
collision detection", that is, detecting a collision even when you're
not transmitting, which repeaters *must* do. Two such confused repeaters
on the same net can get into a state where they "scream" at each other,
jamming the net. For this reason, it has become common practice to
disable the SQE function on all transceivers connected to a repeater
[especially if the repeater is attached to an "evil" multiplexer].
4. There exist fiber-optic based "transceiver cable extenders", which some
people like to use (because they're cheaper) instead of repeaters with
fiber links. Due to the added delay from the added distance between the
station and the transceiver, it is possible that the SQE signal coming
back from the transceiver will be delayed until *after* the time window
assigned to that function following packet transmission, in which case
the station will see the SQE as a "late collision" rather than a "SQE"
(since they share the same wire). Not good. [Such "transceiver cable
extenders" can also cause the "transmit: No carrier!" errors detected
by many Ethernet chips. Again, because of the excess delay.]
For these reasons (and probably others I've forgotten), it is now standard
practice for transceivers to come with a way to enable or disable the SQE
function (usually a little jumper plug inside).
So what happens if SQE is disabled by mistake or because of an awkward
configuration (see #2, above)? Isn't the *lack* of SQE signal going to
cause alarms to go off in the station? Not really. Because it is so common
to need to disable SQE, most station software merely reports the lack of
SQE in a low-priority status display, if at all [most don't even bother].
And this is not all that serious. All it means is that the station is
running in the same mode as an Ethernet 1.0 station, trusting blindly
that the Collision Presence pair is working.
It *is* nice if there is some piece of software that can be run to look
at the SQE status (even if it's only a bit in an SNMP MIB), so that if
you're trying to debug a network that seems to have too many packet errors,
you can look to see if any station's Collision Presence pair isn't working.
Because without SQE, it's actually fairly hard to find a broken Collision
Presence pair.
Other authors have reported networks that have continued to work for *months*
with several stations' Collision Presence pairs broken. All that happens
is that those stations end up using the "CSMA" access protocol instead of
"CSMA/CD(exp.backoff)". If the net is lightly loaded and/or those stations
are not sending much, you might never even notice...
-Rob
-----
Rob Warnock, MS-9U/510 rpw3@sgi.com
Silicon Graphics, Inc. (415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA 94043
From: pat@hprnd.rose.hp.com (Pat Thaler)
Date: Mon, 15 Jun 1992 16:58:32 GMT
Subject: Re: What is SQE?
Organization: HP Roseville Networks Division
Newsgroups: comp.dcom.lans.ethernet
In comp.dcom.lans.ethernet, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
timl@maxwell.concordia.ca (Tim Lapin) writes:
+---------------
| What is SQE? What does it mean?
| Does it generate packets, a line condition or something else entirely?
+---------------
It's called "Signal Quality Error" (SQE) in IEEE 802.3, but in the D/I/X
Ethernet 2.0 spec (Section 7.4.7) it's called the more understandable
"Collision Presence Test". [Still, everybody pronounces it "squee".]
signal_quality_error Message (SQE) is the name in IEEE 802.3 for the
collision detect message. The test of SQE that occurs at the end of
each transmission is called signal_quality_error Message Test or more
informally, SQE Test. So SQE is the the same as Collision Detect and
SQE Test is the same as Collision Presence Test. (The name comes from
the fact that something being wrong about the quality of the signal is
used to detect the presence of collision on the coax, but I don't know
why they didn't use the more straight forward name of Collsion Detect.)
The explanation Rob gives of the reason for performing SQE Test is basically
correct. What one is disabling if one chooses not to run the test is
SQE Test, not SQE. Disabling SQE would cause the transceiver to not detect
collisions. (This error in terminology seems very common.)
3. Some Ethernet repeaters do not have a "bullet-proof" state machine,
and can be confused by the SQE [though it *is* possible to build a
repeater that is not so confused]. They confuse SQE with "receiver-based
collision detection", that is, detecting a collision even when you're
not transmitting, which repeaters *must* do. Two such confused repeaters
on the same net can get into a state where they "scream" at each other,
jamming the net. For this reason, it has become common practice to
disable the SQE function on all transceivers connected to a repeater
[especially if the repeater is attached to an "evil" multiplexer].
SQE test occurs at a time when a DTE does not need to be detecting collision.
There is no equivalent "blind time" available to a repeater. Collision
fragments can arrive at a repeater with little or no gap between them.
When they arrive, it is important to proper operation of the network
that they be repeated to the other side. If SQE test was enabled, there
would be no way to differentiate between a real collision fragment and
SQE test. (The work of LLoyd Oliver, Geoff Thompson, Rich Williams and
myself as members of the Repeater Task Force substantiated this.)
It is not possible to "bullet-proof" the repeater state machine to ignore
SQE test and still have it react properly to these collision fragments.
That is why the repeater standard IEEE 802.3c requires that SQE test be
disabled on MAUs attached to a repeater. (IEEE 802.3c is in the second
and later editions of IEEE 802.3 and prior to those was published in
IEEE 802.3 Supplements.)
Pat Thaler