I'm just fooling around with some of the Sun gear amassed during recent years. Currently I slapped four ROSS HyperSPARC CPUs into one Sparcstation 20. These are two wide 142 MHz modules, each containing two CPUs. Works nicely at PROM level, but produces quite a lot of heat. Does anyone know if that is still a safe configuration in regard to overheating?

I posted wondering similarly about the heat... from the ross datasheets those 4 probably exceed the wattage of the PSU so I was thinking about buying a pair off ebay (looks like there aren't anymore of those 142Mhz ones pity)... I'll probably just end up getting a pair of sm-71s or sm-81s .... as the sm-91 are probably too hot themselves and probably wouldn't even run in a sparcstation if they weren't.

From what I've read the FPU performance on Hypersparcs is rather low I expect that is what hurts desktop performance... more than anything. Although they probably run integer applications like gcc alot faster.

I bought that last quad 142MHz set on eBay. Since they're double wide, I expect heat will be manageable. The MBUS guide doesn't have any notes on the heat for them. Power will be a bit more tricky, I'll stick to a single 7200rpm disk and one SBUS card for 100mbit Ethernet.

A lot of the SS vs HS comparisons aren't so good. For instance most SS have larger L2 caches and L1 D-cache, and more ILP superscalar chance (3x vs 2x). But you can get quad setups with HS, the 142MHz quad has 1MB L2 per CPU too, and the 180MHz+ ones have even fewer downsides with 16I/16D L1 and fast clocks. I expect a pretty good speedup with the quad 142MHz 1MB setup, and it should match SM81 on most single threaded tasks. Will be fun for NetBSD -current dev.

Desktop use is primarily integer, at least a small reason why Intel chips fared so well in that era and this. FP is exercised by engineering workloads, games and multimedia are the only FP heavy desktop things.

Overall, I think IBM (still) and HP (for a while) were doing a much better job in silicon though. SPARC ain't too great :p.

As far as I recall the CPU guide has only a single module in the list without any special remark, so that should be safe. Unfortunately there is no mention of a quad 142 MHz setup, but as there are are notes about the dangers of other higher end confiurations I'm a little bit concerned.

Yesterday I had the SS20 up and running with a few sbus covers missing. The heat coming out there was quite significant, similar to what I'd expect from a larger IRIS 4D. I'll need to try that with all covers on, the airflow in the chassis will be a little bit better then.

Power is another concern, the 150W continuous delivered by the PSU is not much. Currently the system has a TGX card, 256MB RAM and one Seagate Cheetah. I could also use it headless and find a lighter replacement for the HDD.

Got her all zipped up with the quad 142s. It does run pretty damn hot but I don't think dangerously so. The heatsinks aren't a particularly good design.. I think they retain a bit more heat than necessary. Copper would've been a better choice since the profile is so low. For full time operation some 60mm fans taped to the side wouldn't be a bad idea.

What really caught me off guard is how hot the SunSwift card (100mbit/FW SCSI) gets. I may add some metal to that chipset to be safe.

<insert computer company named after the day star jokes here>

I'm pleased with the performance thus far though. It feels a bit faster than the SS as a uniprocessor (haven't built SMP -current yet). All in all, neat and cute box. Fun to play on and that's what it's all about.

An idea I'm considering is sacrificing the last SBUS slot for an external 68-pin SCSI connector and routing that to a ribbon cable in place of the SCA backplane. Jumper that to the SunSwift on the outside and double I/O bandwidth while keeping it all in the pizzabox!

SCSI performance on my box is really bad, 1MB/s to a drive that should push 20x that. I would expect the bus to saturate somewhere around 9MB/s. Does the SCA backplane handle termination? I tried jumpering the drive but noticed no difference in speed.

kev009 wrote:SCSI performance on my box is really bad, 1MB/s to a drive that should push 20x that. I would expect the bus to saturate somewhere around 9MB/s. Does the SCA backplane handle termination? I tried jumpering the drive but noticed no difference in speed.

All SCA backplanes should handle termination. The one exception is external -> SCA boxes, which may rely on an external terminator.

Sun backplanes should have active termination soldered onboard.

Damn the torpedoes, full speed ahead!

There are those who say I'm a bit of a curmudgeon. To them I reply: "GET OFF MY LAWN!"

Gerhard.Lenerz wrote:I'll try to install 2.6 later this afternoon, we'll see how that ends up.

Took me longer than expected. It required different RAM setups until I found one that did work. Now it's time to put the parts removed back in, including the second dual CPU module.

Performance is similar to R4400 Indigo 2 systems. Integer seems to be more comparable to the 250 MHz end, while floating point is more or less in the 100-150 MHz area. Edit: Of course the Indigo 2 has only one CPU while this SS20 has four. So I presume the SS20 will be noticably faster under load if memory or SCSI bandwidth is not the issue.

I bought a set of quad ross 142's for my SS20 when I was building it out. It ran slower than dual SM81s for practically everything I used it for (mostly desktop workstation/heavily threaded stuff). Also, contrary to pretty much everything I read on the web, the SM81s ran cooler than either the ROSS (dual 200 or quad) or the older SM61s and below. SUPERSparc was an awesome processor for the day.

sbarton wrote:I bought a set of quad ross 142's for my SS20 when I was building it out. It ran slower than dual SM81s for practically everything I used it for (mostly desktop workstation/heavily threaded stuff). Also, contrary to pretty much everything I read on the web, the SM81s ran cooler than either the ROSS (dual 200 or quad) or the older SM61s and below. SUPERSparc was an awesome processor for the day.

I wonder if it's the cache controller flushing a lot.. at least on artificial benchmarks the 142s (how much cache?) should be noticeably faster.

I think the biggest factor is that supersparc can issue 3 instructions vs 2 for the hypersparc. Also the cache (I think) on the ross setup shares 1M for each module but at 2:1, where as supersparcs have a 1:1 cache ratio.

Probably on single threaded tasks like compiling or setting up a box for some paticular service (ftp/mail gateway/etc) the ROSS configuration makes sense. I use my SS20 more for just piddling around with the typical desktop setup, so X11, blackbox/CDE, xmms, a few glib programs (which really stress the platform), etc...so again, heavily threaded and lots of context switching.