[SunRescue] help with CPU ID

[Gregory Leblanc]

> -----Original Message-----
> From: James Lockwood [mailto:lockwood at ISI.EDU]
> Sent: Friday, September 17, 1999 2:11 PM
> To: 'rescue at sunhelp.org'
> Subject: RE: [SunRescue] help with CPU ID
> 
> 
> 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). 

Well, that makes a lot of sense.  I don't totally understand the mechanics
involved in multi-processors yet, but I'm getting there.  

> 
> > 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). 

Ahh, why didn't you just say the memory pipe wasn't fat enough in the first
place.  :)

> 
> 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.

Yowza...  That much?  I guess I'm used to affordable hardware like less than
5K for the best available system.  Still how big of a cost difference was
that from the SS10?  If it wasn't that much, maybe people were being very
far sighted.  They purchased them as High End workstations for whatever
their network admins (what's sun's target audience for Workstations anyway?)
and then expected that they'd be trickled down to other people in a couple
of years.  Maybe that's a little far fetched, but the only reason that we're
not doing that at work is because I'm not in charge of purchasing.  We get
medium quality systems, instead of ones that will actually WORK 5 years from
now.  I would expect SS20s to be still selling well, since if you but either
4 SM81s (that's the fastest supersparc, right?) or 4 HS 150s in it it would
scream for most things.  And with half a gig of ram, an 8 MB vsimm, that
would be right up there for a FAST workstation, right?  
	Greg
> 
> -James
> 
> 
> _______________________________________________
> Rescue maillist  -  Rescue at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/rescue
>