Table of Contents

SQE Test (AKA Heartbeat and CPT)

1.1 Repeaters and Heartbeat

1.2 Normal Computers and Heartbeat

1.3 Problems When Using Heartbeat

BOX: A Tale of Two Standards


SQE Test (AKA Heartbeat and CPT)

(Copyright (C) 1994, Charles Spurgeon)

When you install an outboard transceiver on your Ethernet system there is a question you need to answer: Should the SQE Test signal be enabled or disabled?

SQE Test (also known as heartbeat and formerly called CPT) is a signal that must be disabled if the transceiver is going to be connected to a repeater. For all other devices that may be attached to an outboard transceiver, the Ethernet standard recommends that the SQE Test signal be enabled.

But what is SQE Test? Why must it be shut off if a repeater is attached to the transceiver? And how did it come to have three names?

The purpose of this signal is to test the important collision detection electronics of the transceiver, and to let the Ethernet interface in the computer know that the collision detection circuits and signal paths are working correctly. The earliest Ethernet standard, DIX V1.0, did not include a test signal for the collision detection system. However, in the DIX V2.0 specifications the transceiver was provided with a new signal called Collision Presence Test (CPT) whose nickname was "heartbeat."

The way heartbeat works is simple: after every packet is sent, the transceiver waits a few bit times and then sends a short burst of the collision detect signal over the collision presence wires of the transceiver cable back to the Ethernet interface, thereby testing all aspects of the collision detection electronics and signal paths.

    FIGURE 1 Normal SQE Test operation
The result is that the Ethernet interface in the computer receives a heartbeat signal on the collision presence signal wires of the transceiver cable after every packet transmission made by the interface.

There are two things about the heartbeat signal that it's important to understand:

When the heartbeat signal was introduced in the early 1980s most interfaces didn't know what to do with the new signal, and the software driving the interfaces would sometimes report the heartbeat signal as an unknown error or as a collision problem of some sort. Transceivers could be purchased without heartbeat, or with switch-selectable heartbeat so that you could turn it off to make things work properly with older software.

Today's transceivers all have a jumper or a switch that allows the heartbeat signal to be disabled. Only these days it's called SQE Test. SQE stands for "Signal Quality Error," which is what the old collision presence signal changed into in the new IEEE 802.3 specifications. (See box, "A Tale of Two Standards")

Why use "signal quality error" instead of "collision presence" in the name? The change appears to come from the desire on the part of the IEEE committee to add a more general set of signal quality indicators to the standard. However, despite changing the name the IEEE committee never actually developed any new "quality" signals.

Therefore, in everyday practice you find essentially the same two signals being sent between the transceiver and the interface that were defined in the old DIX V 2.0 spec, only with new IEEE names: SQE (collision presence) and SQE Test (collision presence test, or heartbeat).

Technically speaking, SQE Test and CPT are not identical signals since the IEEE changed the timing specifications of the heartbeat signal somewhat. But in effect, SQE Test and CPT do the same thing: send a heartbeat test signal through the collision presence electronics from the transceiver to the interface.

To recap: the original DIX V1.0 specifications did not include a heartbeat signal for checking the collision detection circuits. DIX V2.0 and IEEE 802.3 both include a heartbeat signal which is called SQE Test in the 802.3 spec. On 802.3 transceivers (essentially anything built since 1985) the SQE Test signal can be turned on or off by flipping a switch or setting a jumper.

The question then becomes, When should you turn SQE Test on or off? The 802.3 standard states that SQE Test should always be enabled, with one major exception: SQE Test must be shut off if the transceiver is connected to an IEEE 802.3 repeater. Note that twisted-pair Ethernet hubs are repeaters.

1.1 Repeaters and Heartbeat

The major reason for disabling heartbeat for 802.3 repeaters has to do with the timing of various signals on the Ethernet. To make all repeated segments function like one big segment (which is the repeater's role in life) it's important for a repeater to react to events on the network segments as fast as possible.

While a normal Ethernet interface in a computer has no need to react to anything immediately after a packet has been sent, a repeater is different. Repeaters are required to monitor the signals on a network segment at all times, and do not have any "dead time" during which they can receive a heartbeat signal.

Another reason to disable heartbeat on outboard transceivers attached to repeaters is that the signal has been observed to cause problems with network throughput. Network managers report extremely slow network performance when SQE Test is mistakenly left on. This happens because of the way a repeater reacts to the presence of the heartbeat signal.

Tests in the network lab show that if you leave the heartbeat signal enabled on a transceiver connected to a twisted-pair hub, for example, the repeater electronics in the hub mis-interpret each burst of heartbeat signal as news of a real collision, which causes the repeater to send a "collision enforcement" jam signal out onto all other ports for each heartbeat signal received. The jam signal is part of the normal operation of the repeater, and sending a short burst of the jam signal upon collision detection makes sure that all stations attached to network segments connected to the repeater get news of the collision.

In normal operation, the repeater sends every packet it hears on a given segment out onto all other segments. If the packet is sent through an outboard transceiver with the heartbeat signal enabled, then after every packet through that transceiver the repeater will get a heartbeat signal. In response, the repeater thinks that it is being told of a collision, and sends a jam signal out onto all other ports of the repeater.

In this scenario, you could end up with Ethernet segments filled with jam signals sent by a repeater that's trying to do the right thing but is being fooled by the heartbeat signals sent by the transceiver. That's why you want to be absolutely certain that the SQE Test signal is turned off when attaching a repeater to a transceiver on your network.

Note that this whole issue of whether to enable or disable SQE Test affects only outboard transceivers. For normal Ethernet interfaces with built-in transceivers, like thin Ethernet and twisted-pair Ethernet, the transceiver chips are wired up so that SQE Test signal is always enabled. For repeaters with built-in thin Ethernet and twisted-pair Ethernet transceivers, the transceiver chips are wired up with the SQE Test signal disabled. It's only outboard transceivers attached to 15-pin AUI connectors that can be configured incorrectly for a repeater.

1.2 Normal Computers and Heartbeat

For normal computers attached to a network segment with outboard transceivers, the standard recommends that SQE Test be enabled. The reason being that the absence of an SQE Test signal after a packet transmission can alert the Ethernet interface that there may be a problem with the collision detection circuits. On the other hand, you will probably find that the Ethernet interface software on most computers does not provide a useful response to either the presence or the absence of the SQE Test signal.

The unfortunate fact is that the interface software on the vast majority of today's computers does not make it easy for you to get any use from the SQE Test signal. The failure of the SQE Test signal to show up after a transmission is an indication that something is wrong with the collision detect circuit, or the signal path between the transceiver and interface. It could be caused by something simple, like a transceiver cable having come loose. Or it could be a more serious problem, like the collision detection circuits in the transceiver having failed.

Without a correctly functioning collision detect system, the Ethernet interface in your computer could end up ignoring collisions on the network and transmitting at incorrect times. While rare, this kind of failure can be quite difficult to debug. Therefore, you would like there to be some way for the software on your station to let you know if it detects a problem through the absence of an SQE Test signal after a packet transmission.

However, even if the software on your station does detect the failure of the SQE Test signal it will typically just log the failure in a count of network interface errors maintained somewhere in computer memory by the interface software. These statistics are not easily available to users without special programs designed to interrogate low-level software counters.

Most interface software is designed not to make a fuss if the SQE Test signal is missing because SQE Test is an optional signal on outboard transceivers and is not well understood by most users. Rather than take worried phone calls from people asking what the error message about SQE Test on their computer screen might mean, and rather than try and diagnose whether it's a real problem or just reflects the fact that the signal was intentionally disabled, most vendors take the approach of silently logging the presence or absence of SQE Test in low-level software counters.

1.3 Problems When Using Heartbeat

One side effect of enabling SQE Test for all normal computers is that the SQE Test signal can cause the collision presence light to flash on transceivers and interfaces equipped with troubleshooting lights. This happens because the SQE Test pulse is sent over the same collision presence pair of wires in the transceiver cable as a real collision signal, causing the troubleshooting light to flash for both real collisions and SQE Test signals.

Depending on the type of outboard transceiver in use, when SQE Test is enabled you may see a collision light after every packet sent by your computer. This can confuse people, leading them to think that there is an excessive level of collisions occurring on the network. Therefore, if you enable SQE Test as recommended by the standard for all normal computers, you may need to ignore the effect that the SQE Test signal has on any collision presence lights on your network hardware.

By the way, just to confuse things further you may find that some vendors do not label things correctly on their troubleshooting lights. For example, you may find that troubleshooting lights designed to show whether or not heartbeat is enabled will be labelled "SQE" instead of the correct "SQE Test."

While there may seem to be a number of special cases concerning when to use SQE Test, all you really have to remember is that you must make sure to disable the SQE Test signal on outboard transceivers that are attached to repeaters. As for the rest of the devices you can attach to an outboard transceiver, enabling the SQE Test signal is recommended unless there is some problem with using the signal.

In practice, the choice of whether or not to use the signal is a local decision. Some sites may choose to disable SQE Test on all outboard transceivers since they find that they cannot predict when someone may attach a repeater (such as a 10BASE-T hub) to a transceiver cable. Given that it is difficult to derive any benefit from the SQE Test signal in many systems, these sites may prefer to avoid the problems that a misconfigured repeater can cause by making sure that the SQE Test signal is disabled.

Sites with more stringent requirements for monitoring network performance may prefer to adhere to the recommendation of the standard and leave the signal enabled (except for repeaters) so that they may monitor the signal status with special driver software, perhaps using the Simple Network Management Protocol (SNMP).

BOX: A Tale of Two Standards

Ethernet technology predates the Institute of Electrical and Electronics Engineers (IEEE) LAN standards committee. Therefore, the first Ethernet standard was developed by a vendor consortium made up of Digital Equipment Corp. (DEC), Intel, and Xerox. Taking the first initial of each company, the first Ethernet standard became known as the DIX Standard. This was the first open standard for LAN technology ever published.

There were two versions of the DIX standard, after which the IEEE 802 committee took over the task of creating open standards for LANs. The first "Ethernet-like" IEEE standard was published in 1985 and formally called the "IEEE 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications."


Back to the Ethernet home page.
Charles Spurgeon, c.spurgeon@utexas.edu