Here is what I learned:
----------------------------------------------------------------------------
I'm told that in fact, unless you are using certain routers and/or bridges,
SQE really doesn't matter. I always turn it off; less network noise. But
if you are consistent across your entire network, normally, it doesn't
matter.
For those cases where you do have the certain routers and/or bridges (and,
no, I don't know which ones), SQE must be off. That's another reason to
turn it off.
As far as I know, SQE doesn't care if you are using le or ie interfaces.
----------------------------------------------------------------------------
|> I have learned through painful experiences in the field that it
|> is always wise to have SQE turned off on an external tranceiver.
|>
|> 1) What is the exact function of SQE ?
SQE is where the transceiver sends a collision signal to the station
during a particular time window (just after transmission of a packet)
to tell the station that it (the transceiver) is still alive (or
working).
|> 2) Exactly how does turning it on or off effect network performance ?
Hopefully not at all. Note that SQE is a feature of the host <->
transceiver interface rather than the Ethernet network.
|> 3) Is network performance effected the same way for both Lance and Intel
|> Ethernet chips ?
Both AMD (Lance chipset) and Intel devices should be equally
unaffected.
Regarding your initial comment about painful experiences, enabling or
disabling the SQE function of a transceiver being used to connect a Sun
system to an Ethernet network should not affect that system adversely.
As far as I can tell, whilst Sun systems 'understand' SQE and may
passively keep a count of any non-occurances, they take no action about
those events.
There is one common networking device for which you would want to be
very sure the transceiver SQE function was disabled, the repeater.
Being relatively simple hardware devices, repeaters do not understand
SQE. Instead they see it as a collision and then correctly proceed to
propogate that collision event onto all the segments they are attached
to. This does cause mayhem.
----------------------------------------------------------------------------
For all, I think this will be helpful in assuring correct
configuration. It is highly recommended as stated below to "turn OFF"
SQE................
=============================================================================
ETHERNET VERSION 1, VERSION 2 AND 802.3 DIFFERENCES
INTEROPERATION:
Version 1, Version 2 and 802.3 hosts can coexist and communicate on
the same ethernet. To do so, the host i/f to transceiver integrity
must be maintained with consistent versions of host i/f, transceiver
cabling and transceiver.
Version 1.0 Version 2.0 802.3
----------- ----------- ----------
Transceiver Inner & outer shield Inner & outer shield Inner/outer shld
Cable common at backshell common at backshell iscolated,outer
and pin1. and pin1. to backshell,
inner to pin 4.
Transceiver Full step signal, Half step signal, Half step signal
No SQE avail, SQE implemented, SQE implemented,
No Jabber control, No Jabber control, Jabber control,
Ground pin 1, Ground pin 1, Ground pin 1,4
11,14. *
DROP CABLES:
Drop cables are version specific and should match the host's interface board
and the transceiver, although an 802.3 cable can usually be used universally.
UNTESTED K.W.----^^^^^^^^^^^
Version 1 and 2 cable can be visually identified by the presence of pin 1 on
the male end. Version 1 and 2 cables use the same pin out, but different gauge
twisted pairs, therefore maximum distance may be effected when using Version
1 cabling.
802.3 cable can be visually identified by the presence of pin 4 on the male
end.
The connector attaching to the host interface is male and the connector attach-
ing to the transceiver is female.
Pin Version [1-2] 802.3
--- ------------- ------------
shell outer shield to backshell
1 inner/outer shield & bckshell n/c
2 collision+ collision+
3 transmit+ transmit+
4 n/c inner shield and dc ground
5 receive+ receive+
6 logic ground login ground
7 n/c n/c
8 n/c n/c
9 collision- collision-
10 transmit- transmit-
11 n/c n/c
12 receive- receive-
13 dc power dc power
14 n/c n/c
15 n/c n/c
The interface board's version can be identified by measuring the voltage
between Transmit+ and Transmit- (pins 3 and 10) as follows:
Version 1 approximately .7 volts <<-+--- UNTESTED K.W.
Version 2 approximately .2 volts <<-|
802.3 close to 0 volts <<-+
DEFINITIONS:
Jabber Control: The transceiver will watch the transmit data stream, if longer
than maximum packet size, then the transceiver shuts itself down. Implemented
in 802.3 transceivers.
SQE (Heartbeat): At the end of each transmission by a transceiver, the trans-
ciever sends a signal to the host interface on the Collision+- leads for test-
ing purposes. Sun's ethernet software drivers do not use SQE, so it can be
either enabled or disabled in the transceiver. Implemented in Version 2 and
802.3 transceivers. SQE must be turned off in transcievers that connect to
repeaters.
Full Step Signal: Transmit+- ranges from zero to a positive voltage, with
an idle state of a positive dc voltage. Implemented in Version 1.
Half Step Signal: Transmit+- range from positive to negative voltage, with
an idle state at zero volts. Implemented in Version 2 and 802.3 .
SUN'S SPECIFIC HOST INTERFACES:
Sun's LANCE: The Am7992 Manchester Encoder sets full step verses half step
on pin 5 "TSEL". This is probably the pin which is used by the
level 1/level 2 jumper on the 3/50 cpu board.
Sun's INTEL: Is implemented using Intel 82586 coprocessor and the SEEQ
8023 Manchester Encoder. So the half/full step (V.1/V.2-802.3)
selection is done on the SEEQ 8023 which I don't have specs for.
If Sun had used the Intel 82501 Manchester Encoder then V.1 select
would be controlled at pin 1.
3/160 and 3/50 cpu board strapping calls out Level 1 and Level 2, not
Version 1 and Version 2. I feel very strongly that what is meant by
Sun's term Level 1 and Level 2 is that the Transmit +/- will have an
idle voltage "level" of logical high for Level 1 (V.1) or zero differential
for Level 2 (V.2 and 802.3). This could be verified with an O-scope.
The probable reason that Sun does not document the jumpers as V.1
and V.2 is that Sun doesn't have a full V.2 or 802.3 implementation.
Specifically, the SunOS ethernet drivers do not sense SQE (heartbeat),
even if it is provided by the transceiver.
REFERENCES:
"Unix System Administration Handbook" Nemeth Snyder Seebase
* "Cabletron ST-500 Transceiver Manual"
"STB" January 1988, page 123
"Lan Troubleshooting Handbook" Miller
----------------------------------------------------------------------------
I agree that it's a
good idea to make it a habit to turn off SQE on all transceivers
on a demo or test network. SQE's purpose is to detect an unusual
error (specifically failed collision detection circuitry in a transceiver)
on an operational network. Unfortunately SQE often causes more
confusion than it cures.
On older Cabletron gear, including the MT-800 multiport transceiver,
the same red LED on the front labelled 'CP' indicates _both_ heartbeats(SQE)
_and_ real collisions. So if you have SQE enabled, that red LED
will flash all the time whether or not there's anything wrong with
the network. At best this dismays the observant customer. At worst
it can mask real network problems.
Most equipment doesn't really care whether or not SQE is enabled.
A few pieces (ex: some IBM gear) won't boot if SQE isn't ENabled.
A few other pieces (ex: repeaters, very old Sun gear) will suffer
degraded performance unless SQE is DISabled. A degraded repeater
will affect _all_ the systems on the network. The only example I
could verify of a piece of Sun gear that insists SQE be DISabled
is a Sun 2/50--which is so old I've never even seen one.
In summary:
-SQE is probably not the real cause of an operational customer's
real problem (unless it's enabled for a repeater).
-On the other hand, all the red LEDs can be disconcerting, and
turning SQE off very seldom causes any problem.
----------------------------------------------------------------------------
heartbeat on repeaters
*Someone recently asked about problems on some cable segments but not
*others. Some kind of repeater problem was suspected. The poster
*reported that reducing the NFS write buffer size to 512 made it sort
*of work. The poster may have been from BBN.
To fix the problem, disable heartbeat on the transceivers that connect
the repeater to the thick cable. ("heartbeat disabled" == "no SQE"
== "Ethernet Type I")
Most repeaters match the standard in that they do not forward collision
signals from one side to the other. (Whether you agree or disagree with
the standard is a separate issue.) For hardware implementation reasons,
many repeaters furthermore _require_ transceivers with_out_ heartbeat...
and misbehave very badly if you don't give them what they want.
Check the documentation that came with your repeater to see if it mentions
transceiver requirements. Or, if you can't find the documentation, just
try fix and see if it works.
A "heartbeat" signal sets a latch inside these repeaters. If the very
next packet is going the opposite direction, that latch being set will
cause the packet to be truncated and jammed as though it had been
collided. Yet this fact is never relayed back to the original sending
station. Net result: lots of lost packets/timeouts/retransmissions. You
can see this in TCP retransmission statistics, or with "ping".
This applies to the 15-pin connectors on _all_ repeaters, both "multiport"
models and 2-port models. It obviously doesn't apply to the
thinnet/cheapernet/coax connectors since the transceivers for those
connectors are inside the repeater.
The repeater will probably pass all diagnostic tests, either because all
the test packets were going in the same direction, or because the repeater
was removed to a bench for testing.
Any one of these methods will get you a transceiver without heartbeat: a)
use a VERY old transceiver [ex: TCL rev A or B]; b) for transceivers that
are a couple years old, pry open the housing, find the internal jumper,
and move it; c) find one that was specifically ordered with no heartbeat
when it was purchased; or d) for some very new transceivers, find the
switch or jumper on the outside of the case and move it.
----------------------------------------------------------------------------
We wondered the same thing, so called Cabletron (most of our transcievers
are from them). The tech person there said that SQE _enabled_ was generally
needed for some (older?) DEC machines, but not for Suns. Our local network
hardware people say it doesn't matter that much, but do require it _enabled_
for our building backbones (DEC bridges/repeaters?). I have _disabled_ it
for all the machines on our local net (Suns {SS1s, SS2s, 4/XXXs}, Intergraph
Clipper; the VAXstations and DECstations have builtin thinwire attachment,
so I don't really know which way they are configured). Cabletron's number
is 603/332-9400. If you have other mfg stuff, give 'em a call... I'd like
additional data also!
----------------------------------------------------------------------------
for the lance chip, it doesn't matter. the lance chip notices
and reports whether it (heartbeat) was there or not, but doesn't
care.
----------------------------------------------------------------------------
I have always been told to turn SQE off on Sun's.
----------------------------------------------------------------------------
Thanks to:
evan@fsg.com (Evan L. Marcus [Fusion Systems Group, Ltd.])
robb@EBay (Robb Watson)
Ed.Hayduk@East.Sun.COM (Ed Hayduk - FE - Somerset NJ)
ckollars@east.sun.com (Chuck Kollars - Sun BOS Software)
ept@eptsun1.ctd.ornl.gov (E P Tinnel)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
poffen@sj.ate.slb.com (Russ Poffenberger)
===== ======= ======= Larry Rogers
= = = = Manager, UNIX Systems
= = = Princeton University
= = = 87 Prospect Street, Room 201
= = = Princeton, NJ 08544
= = = lrr@Princeton.EDU, princeton!lrr
= = = = Phone: 609-258-6483/6000
===== ======= = FAX: 609-258-1069/3943
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:39 CDT