[SunRescue] help with CPU ID
GLeblanc at cu-portland.edu
Fri Sep 17 15:15:03 CDT 1999
> -----Original Message-----
> From: James Lockwood [mailto:lockwood at ISI.EDU]
> Sent: Friday, September 17, 1999 12:15 AM
> To: 'rescue at sunhelp.org'
> Subject: RE: [SunRescue] help with CPU ID
> On Thu, 16 Sep 1999, Gregory Leblanc wrote:
> > Why not the SM51? Isn't that a 50Mhz CPU with 1 meg of cache?
> Yes, but the mbus must always run slower than the CPU speed
> when the CPU
> has e-cache. The SM41's escape this limit as they technically run at
> 40.3MHz, allowing a 40MHz mbus speed. SM51's run at exactly
> 50MHz so the
> 50MHz mbus speed in the SS20 can't be used, only the 40MHz mbus. A
> SS20/51 and a SS10/51 will both run with a 40MHz mbus and will perform
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.
> It boggles my mind that Sun ever sold the SS20/51[1,2,4], as
> it doesn't
> really buy you anything over a similar SS10. The SM50
> doesn't perform as
> well in MP applications due to memory contention, but it was
> a heck of a
> lot cheaper to build than the SM51 and performs about as well in a
> single-CPU configuration.
Memory Contention? What's that? I'd imagine that they did it so that there
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.
> Rescue maillist - Rescue at sunhelp.org
More information about the rescue