Path: utzoo!attcan!uunet!samsung!think!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: ethernet version 1 or 2
Message-ID: <46547@sgi.sgi.com>
Date: 18 Dec 89 19:56:53 GMT
References: <8912142230.AA06853@uxe.cso.uiuc.edu> <294@mincom.OZ>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 61

In article <8912142230.AA06853@uxe.cso.uiuc.edu>, swanson@uxe.cso.uiuc.edu (Amy Swanson) writes:
> 
> Is there a way to tell which version of ethernet (Ethernet v.1 or v.2) your 
>PI or Power Series machines are running?  We are currently experiencing severe 
> network problems orginating from our SGIs which we suspect are due to an 
> incompatibility of the SGIs with the SQE (heartbeat) enabled/disabled on the 
> ethernet transceivers.
> 
> Amy Swanson
> amys@ncsa.uiuc.edu

As I recall, none of our drivers care whether heartbeat or SQE is present
or absent.  At one time, in what seems like ancient times, I committed an
error which made unexpectedly present (or was it absent?) SQE increment the
transmit error count by one for each packet transmitted on the VME board.
I think this error was correct by 3.2, if not before.  I figured it out at
the Connectathon before last.

Please note that SQE/heartbeat generally does not matter.  Whether it is
present or absent, you will get the same number of collisions, runt
packets, bad CRC's, and so forth.  Recall that SQE occurs in the dead time
between packets.

I have heard that putting an 802.3 transceiver (and so with SQE) upstream
of some multi-port mux's can make some machines unhappy.  Some (or many?)
mux's send the SQE to all connected machines, not just the one which just
transmitted, and some computers do not like "collision detect" (which
is what SQE is) coming out of the blue.  I do not think IRIS's care.

In article <294@mincom.OZ>, stephen@mincom.OZ (Stephen Kirby) writes:
> We have a IRIS 140 and our ethernet would slow then stop to the 140, if
> we ran on the integrated ethernet controller.  We swapped to a VME 
> controller and the ethernet has not failed.  This problem only occurred
> on our 4 CPU 140.  the PI's give no trouble.  This problem occurred in 
> IRIX 3.2  I have not tested it under IRIX 3.2.1.
> Stephen Kirby
> MINCOM

The current built-in ethernet hardware on the PI and the IRIS-4D 1xx is
similar, based on AMD 7990's.

One difference between v.1 and v.2 is in the quiesent voltage.  An ethernet
that is not overly healthy can make a mismatch between v.1 and v.2/802.3
between host and transciever trash packets and so forth.  I think we are
may still be shipping the VME board jumpered for v.1, while the PI and MP
systems are now set for v.2/802.3.  (sigh)

Almost all of the field problems I have heard of to date have been caused
by dirty ethernets.  If you see "late collision" messages or non-zero error
counts from `netstat -i`, your ethernet is more or less broken.  The higher
layer protocols are amazingly resistent to lost or damaged ethernet
packets.  You can loose a large fraction, and never notice anything but
many complaints from the ethernet driver(s), and reduced performance.

A good ethernet will have 0 (!) "Ierrs" and "Oerrs" and no more than .15 as
many "Coll" as "Opkts" reported by `netstat -i`.


Vernon Schryver
Silicon Graphics
vjs@sgi.com