From: oberman@ptavv.llnl.gov
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: SQE
Date: 23 Jul 92 18:16:48 GMT

In article <chrisc.18.711811686@ramrod.lmt.mn.org>, chrisc@ramrod.lmt.mn.org (Chris Cox) writes:

> Probably a FAQ (although I must admit I haven't seen it A'd F!), but what 
> exactly is SQE (or heartbeat if you prefer) and what advantage('s) does it 
> serve if it is enabled on a LAN?

Actually, Pat Thaler may answer this more accurately than I, but since I seem
to be one of the few people who has even a clue on the subject (or maybe just
the only one who cares) and have this awful urge to post something, I'll give
it a shot. Pat may have expansions/corrections. If s/he disputes anything,
s/he's almost certainly right. At least I've never found him/her to be wrong.
(Sorry, but I've never met Pat, so I'm not sure on gender.)

                         SQE, Heartbeat, and Ethernet
                    (Or, Why does everyone look confused?)

This is a very brief discussion of SQE and Heartbeat for IEEE 802.3 and 
Ethernet. FOr really gory details, see the appropriate documents, IEEE standard
802.3, ISO standard 8802-3, and the DIX Ethernet V2 Standard. (The first 2
references are, in theory, identical.)

First, SQE and Heartbeat are not quite the same thing. Heartbeat is a part of
DIX Ethernet Version 2 and is simply a test of collision detection
functionality in the MAU (that's the correct name for a transceiver, Media
Access Unit). It is ALWAYS present in Ethernet V2 MAUs and can't ever be
disabled (without modifying the hardware). It is required for correct operation
of Ethernet V2 repeaters as well as terminal equipment.

SQE, on the other hand, is part of the 802.3 specification and performs a
number of MAU tests and "reports" to the controller if all is well. It is
usually switchable, as 802.3 required SQE for all terminal equipment, but
prohibits it for repeaters.

SQE and Heartbeat both appear as a signal in the collision lines from the MAU
to the controller after every write. This is why MAUs with displays show a
collision every time they show a write. THIS IS NORMAL!

Quick digression: What is a collision? Of course, we all know tat a collision
is when two controllers start to transmit at the same time (more of less) and
that when this happens both will stop and wait for a random interval and then
retransmit if carrier is not present. This function is critical to proper
network operation. A MAU which can't detect a collision can mess up a network
badly. This makes it critical to be able to quickly isolate "broken" MAUs. If
you don't understand this, read any of the old papers on multiple access nets,
especially the old Aloha Net.

In practice, MAUs hardly ever fail. BUT IF ONE DOES, YOU HAVE A BIG PROBLEM!

While SQE indicates a bit more than heartbeat did and is slightly different in
both timing and electrical characteristics, they are essentially the same from
the perspective of most terminal equipment and you can replace an Ethernet V2
MAU with an 802.3 MAU with SQE enabled most of the time. (A notable exception
is an Ethernet repeater which really requires an Ethernet V2 MAU. There may be
others.) You can even replace an 802.3 MAU with an Ethernet V2 one most of the
time. In fact, there are "fixes" for some Ethernet V2 MAUs to disable heartbeat
and make them into something like an 802.3 MAU with SQE disabled. This also
seems to work almost all the time.

Anyone still with me? OK

RULE FOR SQE. Always turn it on except for repeaters. There should be no
exceptions to this rule, but there are. Some manufacturers can't seem to read
standards (or just don't care). As a result there are some terminal services
that get upset when they see SQE. The SGI Indigo seems to be one of these. I
suspect any device using the same 802.3 chip (SEEQ?) would also get upset by
SQE. I have been told that the same is true of the cisco AGS, but not the IGS.
Not that there is any documentation on this.

We've now covered the basics. So what happens when a MAU fails? In theory,
every time it transmits a packet, an error is logged. This happens on some
equipment. But most software I've dealt with simply ignores the error flag and
does nothing. So SQE makes absolutely no difference to these systems. THIS IS
BAD SOFTWARE DESIGN.

Once in a while a MAU does fail. If it is on some device that does not log SQE
failures or has a MAU with SQE turned off, you don't know what is happening.
If you are on 10baseT, it can be isolated to a hub pretty quickly, but on coax
you are reduced to segmenting the cable (physically disconnecting it) until you
have isolated the problem. This is NOT fun and makes the network manager very
unpopular since the network tends to be down for a LONG time. It took about 4
hours last time I had this problem and could have taken longer.

What's a network manager supposed to do? Complain vigorously to vendors of
equipment that don't adhere to the standard. Complain equally to vendors of
software that doesn't bother to log the failures. SNMP is no good if the agents
don't have any information to send out.

If anyone is not confused by now, congratulations. I think I may even have
confused myself.

Comment on this post will be gratefully accepted, even from Vernon. :-)
Especially from Vernon if I got any of the facts about his company's products
wrong. I'd like to update and expand this into a good discussion of SQE and
heartbeat in hopes that eventually vendors and implementors will start to do
the right thing. SQE is very useful, but only if it is actually used!

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.