Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ptavv.llnl.gov!oberman
From: oberman@ptavv.llnl.gov
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet "heartbeat"
Message-ID: <1991May16.134857.1@ptavv.llnl.gov>
Date: 16 May 91 20:48:57 GMT
References: <12164@uwm.edu> <1991May16.004523.21301@berlioz.nsc.com> <104479@sgi.sgi.com>
Sender: usenet@lll-winken.LLNL.GOV
Lines: 29
Nntp-Posting-Host: ptavv.llnl.gov

In article <104479@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> Perhaps this can be predicted from the fact that SQE is practically
> optional, because it is not present in all of V1, V2, and 802.3, and
> because all transceivers (that I've seen) allow you to turn it off.  What
> is optional or commonly turned off cannot be relied upon.  Any error
> reporting mechanism that cannot be relied upon, and is useful only for
> detecting a relatively unlikely error is likely to atrophy.  Yes, I've
> discovered and fixed loose connectors that heartbeat would have detected.
> Has anyone ever had a system diagnose such a problem on its own?

Heartbeat is and Ethernet V2 term. V1 had no heartbeat or anything like it.
802.3 has a SIMILAR thing called SQE. SQE is recommended for all devices save
repeaters where it is forbidden.

On the other hand, Heartbeat is present and non-switchable on all Ethernet V2
transceivers. Ethernet V2 repeaters do require heartbeat and are not satisfied
by SQE.

SQE is unlikely to be very helpful in finding loose connectors, but I do have
some workstations that gernerate LOTS of errors if they don't se it. If they
run NFS the error reporting can essentially kill the system.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov		(415) 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. Especially
anything gnu.