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