[SunRescue] help with CPU ID

[James Lockwood]

On Fri, 17 Sep 1999, Gregory Leblanc wrote:

> Why on earth would they do something like that?  If the MBUS speed has to be
> slower than the CPU speed, why can SM50's run at the 50MHz bus speed?  It it
> something to do with the cache, or lack thereof.  I don't understand WHY
> they would have engineered it to force the MBUS to communicate with the
> module slower than the CPU communicates with the cache, assuming that my
> logic isn't faulty.

Modules with e-cache (SMx1, all HyperSPARCs) require that the CPU run
faster than mbus speed.

Modules without e-cache (SM20/30/40/50) run the CPU at exactly mbus speed.

The cache controllers on each module must maintain cache concurrency with
each other by snooping the bus.  This takes extra cycles which explains
the requirement that the mbus be slower than the CPU.  What it doesn't
explain is why Sun built the SM51 to run at exactly 50MHz and not 50.3MHz
or something similar (it certainly saved them a few bucks being able to
use identical cores for the SM50 and SM51). 

> Memory Contention?  What's that?  I'd imagine that they did it so that there

There is only so much maximum memory bandwidth available from RAM to the
mbus.  In the SS20 it tops out at about 400MB/sec (this is an aggregate
figure for both CPU's). 

CPU's with cache (SMx1) require less bus bandwidth (otherwise, what's the
point of cache?).  2 SuperSPARC CPU's can easily stress the mbus limits if
they don't have cache, but if they have cache and are running code with a
high degree of locality then the bottleneck moves away from the mbus.
This is noticable even with only one CPU, but two make it worse and four
make it much worse.  If (and all of these numbers are made up) for your
typical application an SM50 requires 250MB/sec memory bandwidth and an
SM51 requires 150MB/sec, then a single-CPU configuration will not
bottleneck at the mbus.  A dual-SM50 configuration, however, will start
suffering due to lack of bandwidth (500MB/sec needed, 400MB/sec
available).  This is shown in the following benchmarks:

System            CPU        ClkMHz  Cache      SPECint SPECfp  Info
Name              (NUMx)Type ext/in  Ext+I/D    rate92  rate92  Date
================= ========== ======= ========== ======= ======= =====
Sun SS20/50       SuprSP     50      20/16        1628    1842  Mar94
Sun SS10/51       SuprSP     40/50   1M+20/16     1546c   1969c Apr93
Sun SS20/502      2xSuprSP   50      20/16        3218    3193  May95
Sun SS10/512      2xSuprSP   40/50   1M+20/16     2950    3744  Apr93

Single-CPU configurations are comparable, the cache of the SM51 makes up
for the slower mbus speed.  On dual CPU configurations the SM51 has a
large edge for specfp, which is very memory intensive compared to specint
(which is much more CPU-bound).  It scales nearly linearly compared with
the SM50, which hits a wall.  Key portions of specint are small enough to
fit inside the SM50's cache, which gives the faster CPU an edge.

> was a nice upgrade path.  You could probably get the SS20 with SM51s for
> only a little more than SS10s with the same CPUs, but you'd be able to
> upgrade the SS20 to be faster in the end IF the mbus speed really makes that
> big of a difference.  

The cost of the CPU's was prohibitive at the time, it made little sense to
buy with the thought of upgrading.  Dual SM50's were cheap ($2k) compared
with dual SM51's ($6k) at their intro (a typical SS20 base was around $12k
before adding CPU's).  The SS20/514 configuration was even crazier, you
paid $18k for just the CPU's.

-James