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 is dead....was told by Jonathan himself
You can't hold back information from you largest customers. ROCK is history along with RK40 and the YS-E converged chip. RF has been pushed out to 2011 at the earliest as it has to get retaped. All bets are off for YR40.
OpenSolaris support has been pulled for Niagara III because the Oracle will start charging for Solaris. Oracle does not give away software for free.
It all comes down to if Larry can convince Fujitsu to buy SPARC without Solaris. Fujitsu is not stupid and this will drag out forever as the products die.
We are going to Linux below sockets and Power for enterprise applications
re: ROCK is dead....was told by Jonathan himself
Though your conjecture that ROCK is dead is probably right on, I know your other statements are patently false. Go back to your hole with the MB troll. Though I can't repeat NDA information, just rest assured that most of what this moron has stated is false or misleading, except possibly the Rock stuff which includes RK40.
Remember, Sun and Oracle are required by law to work independently. If Jonathan were to make statements such as you have stated for future Solaris support, then the deal could be stopped by the government as well as fines and jail time... I doubt very much everything you say.
A long, drawn out death...
It looks like whatever development future there might be for SPARC, it will be with Fujitsu. Oracle will seek to eke out software revenue from what will be a steady loss of market share. Just whether Oracle will continue to develop Solaris (whether for SPARC, or x64) will be interesting to see. Maybe Oracle will seek to get Linux and Solaris on a converging course, or then again, maybe Larry will seek to steer Oracle customers towards Solaris and make it a premium product (perhaps by tailoring Solaris and Oracle together) - who knows.
The Fujitsu SPARC64 is actually not a bad chip. It's a bit on the hot side, but performance and (reputedly) reliability it is way above SUN's old SPARC IV+. Whilst the Niagara will beat it hands down on throughput per watt, when it comes to single thread performance (which matters for a large number of apps - including meaty databases) there is no contest. With an 8 core cpu on the way and decent single thread performance, a re-badged Fujitsu machines looks like a sensible way of avoiding lots of hardware investment. Bad news for SUN hardware engineers of course, although their machines have never quite made it as the best big-iron ones about.
@Rock is Dead
Oracle does give away software. Unbreakable Linux for one.
They have to give the software away as it is GPL'd. They (like RedHat) charge for support.
Otherwise, IMHO, Oracle Software is very expensive even for a SME.
Oracle has a decision to make when it absorbs SUN.
Do the continue with Unbreakable Linux and quietly ditch OpenSolaris
Do they put all their O/S eggs in one bag and go olny with Solaris.
Personally, I hope it is the latter. Unbreakable Linux AFAIK has hardly been a raging success.
Good luck getting support for that.
coward: 2009-08-10 16:09 GMT: fud, speculation, and matt bryant like style
sound like unemployed mattie bryant fantasizing & spreading the fud again - LOL!
maybe just another ibm marketing droid now. it was not that long ago when mattie-boy bragged on el reg about fantasizing on the web and not being employed by a bunch of companies
let's see what else el reg turns up on rock and niagra-iii!
Q and A with Larry
Q: "Your management team has no experience with delivering hardware. There is a lot of risk in going into an unfamiliar business."
LJE: "Obviously, we want to hold on to Sun’s experienced team of first-rate hardware engineers. For years, Sun has led the industry in building and delivering innovative systems. For example, Sun was the first company to deliver systems built on a multi-core processor—what Sun called the Niagara chip—and the industry followed. Oracle has a good track record of retaining the engineering talent from acquired companies; Sun will be no different."
Q: "Alright, Oracle’s done integrated hardware and software design with the Exadata database machine. But Exadata uses standard Intel chips. Are you going to discontinue the SPARC chip?"
LJE: "No. Once we own Sun we’re going to increase the investment in SPARC."
Anonymous: multiple levels of tiered speculation is poor footing for making a business decision
Anonymous Posted Monday 10th August 2009 16:09 GMT, "ROCK... RK40... YS-E... RF has been... YR40... OpenSolaris support has been pulled for Niagra III because the Oracle will..."
Suggesting what Oracle might do with future announced products and with products that have not been committed to, when Oracle's purchase has not been approved by regulatory bodies, is dubious, at best. Oracle announced they would "increase investment in SPARC."
Anonymous Posted Monday 10th August 2009 16:09 GMT, "It all comes down to if Larry can convince Fujitsu to buy SPARC without Solaris."
SPARC is an open architecture. Fujitsu and other companies have been creating SPARC CPU's and SPARC systems, without buying anything from anyone else, for years. Even OpenSPARC is open sourced, so Fujitsu can create their own CoolThreads "T" chips without buying anything from anyone! (Other vendors have already created version of the CoolThreads "T" chips, without buying anything from Sun.)
This is the benefit to multiple vendors, open standards and open source. Fujitsu does not need to buy anything from Sun, nor do they need to be coerced by Oracle to buy anything.
Anonymous Posted Monday 10th August 2009 16:09 GMT, "We are going to Linux below sockets and Power for enterprise applications"
Moving to an architecture (i.e. POWER) where the CPU's are a single vendor source and the primary operating system (AIX) is a single vendor source is a pretty weak substitution Open Sourced Solaris, Open Sourced CoolThreads, Open Standard SPARC, multi-vendor sourced SPARC.
People moving from SPARC, after an acquiring vendor offers to purchase one [of a community of] SPARC vendors, and had committed to increasing investment in SPARC, is very poor basis for a business decision to displace SPARC now.
Yeah he had slanted views and was major HP Itanic fanboi but he was amusing. Oh well he was right in that a year from now HP will still be chugging along (long live being the worlds largest ink seller) and Sun will cease to exist. Too bad really as it is easy to cheer for any production OS ecosystem that is not Microshaft. IHMO Oracle would be stupid to not push ahead with Solaris at least in the medium term, as it has a large installed legacy base to milk and if my job depended on uptime of a mission critical database I would still trust Solaris over Linux (although would prefer AIX over either but that is me, plus hey at least if the server crashed I would have a nice pretty error code on the front of the box :) Still Oracle is not a much better corporate citizen than M$ and has shown they know how to milk locked in customers hard so I am glad I don't have a business locked into Sun technology. If I did I guarantee migration would have started long before Oracle announced Suns demise (writings been on the wall for awhile).
The Reg keeps reporting Rock has been canceled... Can we continue to even call it news at this point? Regarding next generation SPARC CMT processors, the information in earlier comments is way off - I've heard that KT is already up and running and the Rainbow Falls program is not 2011, its much earlier.
Also, why is it so hard to believe Oracle is interested in capturing software *and hardware* revenues? Larry wants a $100B USD sized company, the most expedient way to get there is to capture the several billion in revenue from SPARC and x86 that will land in their lap with this acquisition., and to keep growing all of it. Hardware has always been wildly profitable for Sun; it's insanely flawed software business strategies from intellectual giants like Jonathan Schwartz that have obfuscated that fact.
Let's get our facts straight.
1) Sun is dead
2) SPARC from Sun is will never go past four sockets....so much for the E10K hay days
3) CMT is interesting technology but sucks for databases...even Oracle
4) Yes Oracle does a great job of milking locked in customers, but does a better job making high margins.
5) Oracle will not have the patience for Sun hardware as they "move Sun to a $1.5B profit engine in year one" LJE may want $100B of rev but is more interested in the bottom line
6) Of course Oracle wants people to think they will continue SPARC, why kill something openly they want to sell or milk...either way innovation is gone from SPARC....questionable where it has been anyways.
7) The Q&A from LJE was a joke. A PR FAQ sheet some lame reporter pretended was an interview...then Oracle puts it up on their website as a Q&A doc
Anonymous: Facts #
1) Sun is in the process of being acquired, not filing chapter 7, and the acquisition is not final
2) A fact can be proven, and speculating what a company will NEVER do in the future is not a fact
3) CMT has demonstrated excellent database throughput, socket per socket against competitors
5) Speculating about what Oracle will or will not do, if the acquisition is approved, is not a fact
6) A question is not a fact
7) Answers to questions from an interview with a reporter and very publicly displayed on a corporate web site is not a joke, speculation being suggested as facts from an anonymous source is a joke.
RE: Anonymous: Facts #
"1) Sun is in the process of being acquired, not filing chapter 7, and the acquisition is not final...." Sun was well on the way to chapter 11 with continual losses, and Sun stock holders better pray the acquisition gets final real soon as there are precious few other options. Not one of the other top-line vendors was interested, which means the only other option would be a break-up and garage sale.
"...2) A fact can be proven, and speculating what a company will NEVER do in the future is not a fact....." Agreed. Seeing as Sun won't come out and say whether they have or haven't cancelled Rock, we'll just have to surmise that from the evidence that there is a 99.999% chance Rock is dead. And that's the first time I've seen any Sun product hit five nines!
"...3) CMT has demonstrated excellent database throughput, socket per socket against competitors...." ....in carefully crafted comparisons that just aren't representative of how businesses want to use their databases.
What, no answer to 4?
"....5) Speculating about what Oracle will or will not do, if the acquisition is approved, is not a fact" And wishful thinking by Sunshiners isn't either.
".....6) A question is not a fact....." Yes, but Sun's attempt at "innovation" (Rock's scout threads and transactional memory implementation) has failed, and no-one but you Sunshiners seriously believes Niagara in any form will be enough to flll the gap.
"....7) Answers to questions from an interview with a reporter and very publicly displayed on a corporate web site is not a joke, speculation being suggested as facts from an anonymous source is a joke.,,,," Well, personally I prefer those jokes that start something like a fool, a goat and a Sunshiner walk into a stripjoint....
@Matt Bryant: RE: Anonymous: Facts # #
1) "Sun was well on the way to chapter 11 with continual losses" - Non-GAAP Net Income of $409M Q208, $132 Q308, $275 Q408, loss of ($65M) Q109, $119M Q209 was hardly "on the way to Chapter 11". The market performance since the acquisition rumors concerning IBM and later Oracle bid drastically changed the product consumption rates by customers, but this is a problem with FUD in the market.
2) "99.999% chance Rock is dead." was not the "fact" in doubt to the original #2.
4) "What, no answer to 4?" - even if the Anonymous Coward made a statement in a jaded way, I agree that Oracle does a very good job at earning revenue and profit for products that customers deem as more unique and more valuable than market competitors. Too bad all those "locked in" customers can't find a cheaper competitive product to move to - someone better get programming!
We both agreed that nearly all Anonymous "facts" were not "facts"!
I hope some of the Sun financials will help you understand the odd conclusions by you and the Anonymous Coward were not factual or even realistic.
Nice to see the concurrence from both of us once in awhile!
Have a great day!
GAAP or non-GAAP
No matter how you count your chickens, Ponytail gave up and waved the white flag of defeat.
It was embarrassing how they shopped Sun around knowing there is no future.
Failures: ROCK, SPARCV, All software (JAVA from a ROI view), anything past 8 sockets.
Only success was the maintenance stream which Oracle will increase the costs by at least 50%.
Dear Mr Moron
Do you still believe that Niagara SPARC suffers from a too small cache? Do you still believe that the sloooooooow IBM Power CPU is a server CPU? Do you still believe that any CPU can fit in a server-client workload into it's cache?
GAAP or non-GAAP
Dont you know that many companies have several failed projects? It is normal to have failed projects.
Also, there are SPARC machines with many sockets. And also, the Fujitsu 8 core "VENUS" CPU has quite decent performance. Someone said it is the fastest CPU, I think.
Geez, someone switch this kiddie to the sugar-free coke, fast!
"Do you still believe that Niagara SPARC suffers from a too small cache?...." Yes. You provided nothing of note to convince me otherwise.
".....Do you still believe that the sloooooooow IBM Power CPU is a server CPU?...." No, I believe the Power CPU is actually a fast server CPU, from the empirical evidence of seeing it run real world applications.
".....Do you still believe that any CPU can fit in a server-client workload into it's cache?...." As I explained before, you didn't specify what load, so in theory a CPU with a large cache such as Power6 or Itanium2 could do just that. Unrealistic, maybe, but still possible. And totally irrellevant to the current thread, which is about the new evidence that Rock has been quietly axed.
".....Dont you know that many companies have several failed projects? It is normal to have failed projects....." Failed projects are fine as long as the market believes you can carry on making money. The problem for Sun was the market stopped believing and - worse - the customers stopped believing that Sun had a future either. Without current profits or probable future profits, and with a mountainous costs, Sun had little option but to put itself up for sale before the cash ran out.
"....Also, there are SPARC machines with many sockets. And also, the Fujitsu 8 core "VENUS" CPU has quite decent performance. Someone said it is the fastest CPU, I think." Which has nothing to do with the article, which regards the new evidence that development for Rock has stopped and thererfore - logically - Sun must have dropped Rock.
Mattie Pattie, Laddie
Look, if a 1.4GHz Niagara suffers from a small cache, how come it is several times faster than a 5GHz IBM Power6 CPU on certain benchmarks? The Power6 has larger cache and 3 times the clock frequency and STILL it looses big to a Niagara. Can you explain this fact? No? Maybe Niagara doesnt suffer from a small cache - as it is faster than the slow Power6?
The Niagara doesnt suffer, as it is several times faster than CPUs with a large cache. The larger cache CPU suffers, as it is slower. Try to dis-explain that! :oP
".....No, I believe the Power CPU is actually a fast server CPU, from the empirical evidence of seeing it run real world applications....."
A server CPU should be suited to handle many clients. And a legacy CPU that depends on a large cache and high clock speeds - will never be able to handle many clients well. Because the cache will never be able to fit in several thousands clients workload into it's cache. The result is that the cache will thrash, swapping data in and out all the time, never reusing the data.
Only a CPU that does not depend upon the ability to fit in the work load into it's cache (like the Niagara) will be able to handle many clients well. And THAT is the reason one Niagara box is twice as fast as three IBM P570 servers together, on SAP benchmarks. This result tells me that Power6 actually sucks on server client workload. How can you need 6 of the P570 to match ONE Niagara box? How slow can the Power6 CPU be? It's a catastroph.
".....As I explained before, you didn't specify what load, so in theory a CPU with a large cache such as Power6 or Itanium2 could do just that. Unrealistic, maybe, but still possible...."
Are you ignorant? How can you believe that a large cache can fit in a true server - client workload??? And then you have the OS to fit in also! The kernel will occupy large portions of the cache. You should go home and do some studying. Begone. Go home! You are not allowed to utter a syllabus until you know what's the purpose of a cache! (It is funny you accused me of being to theoretical)
".......And totally irrellevant to the current thread, which is about the new evidence that Rock has been quietly axed....."
But you never answered to me lastly. "Do you really believe that a server CPU can fit in many thousands clients workload into it's cache?" You just came with some bad explanations. The point is Mattie Pattie, YOU ARE WRONG. I suggest you think over if you might be wrong on other things, as well.
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. If you need single threaded performance (servers are mostly not dependent on single threaded performance) you use Venus. For massive throughput, you use Niagara. IBM can only offer single threaded performance.
RE: Mattie Pattie, Laddie
And, what a surprise, Kebabbert just repeats the same drivel as he did the last Sun thread. He is really desperate to drag the discussion away from Rock's demise!
"....Look, if a 1.4GHz Niagara suffers from a small cache, how come it is several times faster than a 5GHz IBM Power6 CPU on certain benchmarks? The Power6 has larger cache and 3 times the clock frequency and STILL it looses big to a Niagara. Can you explain this fact? No? Maybe Niagara doesnt suffer from a small cache - as it is faster than the slow Power6?...." That's easy - it only happens on certain benchmarks where threads are small and in multiple, which suits the CMT design, but give it a real workload similar to those of genuine business applications and the Niagaras chokes becasue it can't deal with heavy threads. I've explained this to you again and again, I can only surmise your obtuseness is deliberate.
Let's just skip through your amusingly desperate attempts to retread old rubber and get to the fun bit.
".....Regarding SUN dropping Rock, yes I suspect that is true. So what? There IS a high performant SPARC cpu in the Fujitsu Venus CPU....." And no Sun server to use them. And no confirmed Oracle server either. And no guarantee from Larry there will be. Which is why customers are deserting Sun and switching to Power and Itanium.
Mattie Pattie Laddie
No, you are wrong again. As I TOLD YOU, the Niagara never "chokes", it merely slowes down. A desktop CPU will reach a point when it's cache will start to trash and swap in and out all thousands of clients data. That is the point where a desktop CPU will start to choke.
Whereas a server CPU should not be constructed to fit in all clients data into it's cache - because that is impossible to do if there are many thousands of clients. And the Niagara is differently constructed and doesnt need a large cache - hence it is not vulnerable to cache misses. Just as a desktop CPU.
Whereas the sloooow Power6 is very very vulnerable to a cache miss. Which is typical for a desktop. Power6 is constructed for Desktop work, it can handle few threads. Niagara can handle many many threads. It never chokes. Power6 chokes.
You havent understood nothing. DO YOU STILL REALLY BELIEVE ANY CPU CAN FIT IN SEVERAL THOUSANDS CLIENTS DATA INTO A CACHE? Ive tried to explain that it is impossible, but have you understood yet how a cache works? That a cache is smaller than RAM, and can NOT hold several thousands clients data. Doesnt it sound reasonable? No? You still believe a cache can hold the entire RAM? Yes?
(BTW your statement about 99.999% was really funny. I laughed a lot :o)
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. No - just more waffle about Niagara, and more retread of the same old male bovine manure. I know maths isn't a subject exactly reknowned for individualism or creativity, but surely you can try something new?
Apart from the fact that has nothing to do with the Rock, are you STILL going on about cache? So you're convinced there is no way ever that a client-server app could be fitted into cache? 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 (remember, cache can be stacked with prefetch instructions, so it would be a trivial task to write a prefetch routine that stuffed the cache with the data required). Then, just to really underline your ignorance, you may want to consider that Power6 can share cache between cores on different CPUs (which is why it gets such good single-thread benchmark results, because one core is using all the 32MB L3 caches from all the CPUs in the server), so even if the old program and data can't quite be squashed into the 32MB of cache available to a single core then it can be spread out along the bus, and still respond faster than memory or disk. Niagara can't do this, Niagara is stuck sharing out its tiny cache with all the running threads, so as it starts up more threads the situation gets worse, and more and more threads are stalled waiting on memory or disk, and average response time goes throught the ceiling. I have seen this, so don't try and pretend you know better when your experience is so obviously limited to drooling over Ponytail's press releases.
Surely there's a Sunshiner out there not too busy looking for a new job that can mount a better defence than this moron? He's too sad even for comic value, you just end up pitying him!
massive dead on arrivals of Sun gear
Apparently because the T processors are made by the Chinese now and the systems are assembled in Mexico there are massive DOA's.
If you have experienced this and were told you are unique...post your experience here.
IBM's demo trick of shutting down some of the cores to make more cache available to the remaining is surely old news by now :) Or do you mean to say that one core can hog all the cache so that none of the other cores can use any? This kind of basic difference in requirements is why single-threaded application servers are used in a different tier from back-end servers and web front-end servers.
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?
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
<Skip through usual and repeated Kebabbert waffle....>
"....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)!
<Skip through more of the usual and repeated Kebabbert waffle....>
"......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.
- Boffins attempt to prove the UNIVERSE IS JUST A HOLOGRAM
- China building SUPERSONIC SUBMARINE that travels in a BUBBLE
- Review Raspberry Pi B+: PHWOAR, get a load of those pins
- Review Reg man looks through a Glass, darkly: Google's toy ploy or killer tech specs?
- MEN WANTED to satisfy town full of yearning BRAZILIAN HOTNESS