[rescue] Fast Ethernet with a Sparc Classic

[r.stricklin]

On May 31, 2013, at 6:45 PM, Jonathan Katz wrote:

> hme's didn't show up on-board until the Ultra2. I think even the Ultra1 had
> le's on-board.

* SPARCclassic has an onboard le (10 Mbit).

* Ultra 1 140 and 170 have an onboard le, 10 MHz 8-bit SCSI, and 3 SBus
slots.

* Ultra 1 140E, 170E, and 200E all have an onboard hme (100 Mbit), 10 MHz
16-bit SCSI, and one of the SBus slots replaced by UPA.

* All Ultra 2 models have UPA, hme and 10 MHz 16-bit SCSI.

* The hme is not supported on sun4c. Solaris 1.1.1, 1.1.2, and 2.4 drivers are
available, but unbundled. Solaris 2.5 11/95 is first bundled release.

* qfe is not supported on sun4c either. No SunOS 4 support at all, Solaris 2.4
minimum. "One CPU per qfe port is recommended for maximum throughput. For
systems >200 MHz, a minimum of two CPUs per qfe card is recommended."

* There was an earlier SBus 100base-T card called the BigMac (be), which is
the predecessor---but otherwise unrelated---to the hme. This is half duplex
only, dropped in Solaris 7 and incompatible with any Ultra, but the only
option for sun4c (Solaris 2 only, no SunOS 4 drivers except sun4m), or Solaris
prior to 2.4 (though drivers are unbundled until Solaris 2.4).

* The qfe 1.0 is not _exactly_ "4 hmes on a board", though that is its
essential nature; the driver situation is slightly different for qfe vs. hme
if you are looking at the Solaris 2.4-2.5-2.5.1 era. qfe 1.0 wants OBP updates
as well (>= 2.9 for SS5, >= 2.10v3 for 6x0MP, >=2.26 for SS1000/2000). This
board does not support trunking.

* The qfe 2.0 is different hardware and actually has a separate driver,
bundled starting with Solaris 2.6. Minimum OS is Solaris 2.5 (qfe 2.0) or
Solaris 2.4 (qfe 2.1). This qfe can be trunked (unbundled). Not supported on
LX, Classic, or SS4, but probably works (with reduced performance). "It is
highly recommended that you have >500 MHz of CPU (i.e. 2x 250 MHz, 3x 167 MHz,
etc.) per board for maximum performance."

* SPARCstation 5 was well suited to IP routing/firewalling and was in fact
commonly used for this task "in the day". It was preferred for this specific
task over "better" SPARC systems because the CPU was clocked comparatively
high and had very low memory latency (due to being directly interfaced to the
memory controller, unlike MBus systems). Though, "the day" corresponds
strongly to a time when you wouldn't have had one involved in many 100 Mbit
networks.


Whether BSD or Linux works around any of the sun4c limitations, I couldn't
say. It's doubtful that either would work around many of the performance
limitations.

ok
bear.

--
until further notice