Sun's Rock is barefoot on Abbey Road

Rumors of its death not greatly exaggerated?

By Timothy Prickett Morgan, 10th August 2009

SaaS data loss: The problem you didn’t know you had

More rumors and some evidence has surfaced suggesting that Sun Microsystems has indeed killed off its "Rock" UltraSparc-RK, sometimes called the UltraSparc-AT10, high-end server processor.

Sources at Sun familiar with the Rock project and its related "Supernova" servers told El Reg on June 15 that Sun had killed off the 16-core Rock Sparc chip that day. Sun would not confirm that these rumors of the Rock's demise were true - all that Sun said officially was "no comment re: Rock" - and indeed it would not even talk about its Sparc roadmaps at all. And since Oracle started its $5.6bn acquisition dance in April, Sun has been increasingly quiet, first not hosting conference calls to go over its financials for its third and fourth quarters and has has even gone so far as to upgrade its "Niagara" Sparc T2+ processors and not even make an announcement that faster chips, which came out on July 22, were available for its systems. (El Reg did catch the announcement and told you all about the new chips.)

According another source who is high up in the IT offices at a major financial services firm in Europe, Sun told its biggest customers in Europe in the third week of June that Sun had "axed the Rock completely." This source added that the 16-core Niagara-III was performing better than expected and that Rock, with its funky architecture (which includes special scout threads and transactional main memory, both new technologies) delivered less bang for the buck than Sun expected and, more importantly, had "severe performance issues" when more than one processor was hitting the Supernova server backplane. These performance issues, this source said, are what forced Sun to delay the launch of the Rock chips and Supernova servers in the second half of 2008 and push them out to the second half of 2009. It is not clear when the revved Rock chip was taped out, or if it ever made it that far. If the chip is dead - and it is hard to believe that it is not, with Sun not even trying to dispel the rumors - this is all academic.

Here's a more concrete piece of information that suggests Rock is dead. It comes from the OpenSolaris project's own mailing lists, and an except of the relevant bit is shown below:

Repository: /hg/onnv/onnv-gate Latest revision:

7c80b70bb8dea7210885abc597def087dbecdbba

Total changesets: 1 Log message: 6858457

Remove Solaris support for UltraSPARC-AT10 processor

Files: delete: usr/src/lib/libc/sparc_hwcap1/common/gen/memcpy.s

delete: usr/src/lib/libc/sparc_hwcap1/common/gen/memset.s

delete: usr/src/lib/libc/sparc_hwcap1/common/gen/misc.s

delete: usr/src/lib/libc/sparc_hwcap1/common/gen/strcpy.s

delete: usr/src/lib/libc/sparc_hwcap1/common/gen/strlen.s

delete: usr/src/pkgdefs/SUNWusat10.v/Makefile

delete: usr/src/pkgdefs/SUNWusat10.v/pkginfo.tmpl

delete: usr/src/pkgdefs/SUNWusat10.v/prototype_com

delete: usr/src/pkgdefs/SUNWusat10.v/prototype_sparc

delete: usr/src/uts/sun4v/cpu/rock.c

delete: usr/src/uts/sun4v/cpu/rock_asm.s

delete: usr/src/uts/sun4v/cpu/rock_copy.s

delete: usr/src/uts/sun4v/pcbe/rock_pcbe.c

delete: usr/src/uts/sun4v/rock/Makefile

delete: usr/src/uts/sun4v/rock_pcbe/Makefile

delete: usr/src/uts/sun4v/sys/rock_hypervisor_api.h

delete: usr/src/uts/sun4v/sys/rockasi.h

. . . .

_______________________________________________

onnv-notify mailing list onnv-notify@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/onnv-notify

That seems pretty clear.

There has been some mumbling about the 16-core the Niagara-3 chip, also known as the UltraSparc-KT, has still not taped out (it was expected to around the end of 2008 or so) and that it was removed from the OpenSolaris repository as well. I have not been able to find any references in the OpenSolaris forums about the Niagara-3 or KT chip having its OpenSolaris support removed. And as for Sun's plans for the 16-core, 256-thread UltraSparc-KT chip and its related servers, the company is as quiet as the grass growing about the entire Sparc lineup (including machines made by Fujitsu), and will stay that way until Oracle closes the Sun acquisition once government regulators in Europe and the United States give it the nod. ®

Steps to Take Before Choosing a Business Continuity Partner

COMMENTS

House Rules Send Corrections

All Reader Comments (25)

Latest Comments

Posted Friday 21st August 2009 11:42 GMT

Matt Bryant

RE: Come Now & Kebabbert the Confused

RE: Come Now

I agree, probably not of great practical use, but it was fun when one of our AIX consultants showed us how to run the SPEC benchs with just one core but shedloads of cache! Some screaming figures, no relevance to our actual applications, but fascinating tech nonetheless. But having said that, the Power chips don't NEED to do tricks like that to still be good performers with the apps we have, whereas Niagara NEEDS the application to be completely rewritten (if possible) to suit its CMT design. Previosuly we've had porting issues between different Power generations, but if Power7 is really compatible with the current crop of Power6/6+ apps then it will be an attractive upgrade path for us.

RE: Mattie Pattie Laddie

"....Ergo, I dont pretend Rock is alive. I also talk about another Enterprise SPARC CPU, than Niagara, which is called Venus....." And where is Venus on the Sun roadmap? Oh, it isn't. How about the Soreacle roadmap? Oh, they haven't made one yet as they're still waiting to complete the takeover. And even when they do they be much busier swinging the axe to clear all the Sun deadwood to be producing anything for a while. There isn't even any hard guarantee there wll be the KT Niagara3 chips. So, basically, you just sprouted more unsubstantiated male bovine manure from the Sunshiner whimsy file. Even if we give you the benefit of the doubt and look at what Fujitsu are doing with Venus you still get a big fail - Fuijtsu are only using it for specialised HPC, they haven't released any roadmap showing a general Slowaris server with Venus chips. Back to the drawingboard for you (or, more likely, back to the crayola box)!

"......Can you answer me how one Sun T5540 server is twice as fast as three IBM P570 servers on SAP benches?...." I already have - stacked benchmarks. I'm assuming you have suffered a head injury that has left you with the memoryspan of a goldfish. But here's the question you completely avoid - how come Power and Itanium are outselling Niagara into the high end enterprise where all those SAP installations are? How come Niagara is considered just a niche webserving CPU, even by Sun (remember, the Sun website even describes it as suitable for edge applications, not core enterprise apps) - are you saying Sun are just stupid too? Get a grip, get a clue, go back to school and leave the discussion to the adults, child.

/SP&L

Posted Thursday 20th August 2009 15:20 GMT

Kebabbert

Mattie Pattie Laddie

"....Still looking for any part of your comment where you even pretend Rock isn't dead, or try and present some argument as to how Oracle can retain any enterprise customers without a proper enterprise CPU...."

What are you talking about? I answered to this. Do you have a hard time understanding what others write? I wrote: "Regarding SUN dropping Rock, yes I suspect that is true. So what? There IS a high performant SPARC cpu in the Fujitsu Venus CPU. That octocore SPARC will reach 128 GFlops". Ergo, I dont pretend Rock is alive. I also talk about another Enterprise SPARC CPU, than Niagara, which is called Venus.

"....Take a quick look through history and you'll find plenty of old C UNIX apps that ran on a lot less than 32MB of memory, they are all candidates to run in cache on a modern CPU..." I dont understand how you can write such really uneducated things? Did you ever think before writing that? You know, a cache mustnt only hold the server application, it will also try to fit in the OS, kernel, and all the clients data sets. I explained this many a times. And still you dont understand? Look, a cache tries to hold everything recently accessed. Not only a selected pieces from the software. The cache doesnt know if it should fit in the server app into it's cache. Which it should NOT try to do. Why? The problem is localization. A small part of the code will use almost all computations. Hence, of that server application, only a small part of the code will be accessed frequently. It is a DUMB thing to try to fit in the whole server application. Therefore the cache will never try to fit in the whole server app. It will fit in things that accessed frequently, such as parts of the Kernel, server app, client data sets, etc - which can never fit into a cache.

Dont you get it? How many times must I explain? A cache can never fit in a server workload! Read this again, but slooooooowly (like the Power6) and maybe you will understand! Jesus man, you must have had a hard time in school when a teacher tried to explain things to you.

Can you answer me how one Sun T5540 server is twice as fast as three IBM P570 servers on SAP benches? How is that possible if the Niagara cache is too small? Can you give a good explanation, or can you not?

Posted Thursday 20th August 2009 08:54 GMT

Anonymous Coward