Surely something called an M3000 would be a dual socket machine, not a single socket as an M5000 is 8 socket and an M4000 is 4 socket. A dual socket machine would a gap in the product line - that is an entry level SPARC server with half decent single-thread performance.

If there is to be a single socket machine then M2000 would make more sense, but an M3000 with dual socket capability would also suffice for the single socket market.

I hear that not only transactional memory does not work, but it will be of no value to Oracle and customers will need to rewrite their applications.

And where did you "hear" this?

http://www.c0t0d0s0.org/archives/4774-Presentation-about-Rock.html

An AC with hear-say FUD. Don't think your rumor is gonna fly friend.

....they used for UltraSPARCV just before they canned it?

The more you troll, the less credible you are. Shame you can't see that.

On second thoughts though, it's actually quite useful - as it tends to bring out users who actually know/appreciate/use Sun solutions, and in turn often leads to some rather interesting reads and case studies for those folk such as myself wanting to become familiar with this stuff.

The SUN "roadmap" is for slower and less powerful chips than IBM has currently in producion. You can order a 64 core machine running at 5 gigahertz now and have it up and running in your datacentre in about six weeks.

Sadly the current SUN story seems like a made for TV version of the "Decline and Fall of the Digital Equipment Company", same delays, same market misjudgments, same fanatical band of loyal supporters.

Mines the asbestos one!

I think a quick spot check on posts will show that for this and most of the Sun articles there are more anti-Sun views posted than pro-Sun (and they even post real names!). Are you denying Sun dragged out UltraSPANKED V until it was patently obvious it was just too little too late, then killed it, and that sounds spookily like what is happening with Rock? I remember at least one Sun exec telling me it was "taped out" only weeks before they canned it, but then I'm not sure where that comes in the Sun design process in relation to "in silicon analysis" (probably somewhere between "fantasy vapourware design phase" and "create cancellation excuses for the market analysts").

It looks like SPARC64 has a healthy future and will be a lot more interesting, so I struggle to see why Sun just don't can Rock now and go with the SPARC64. At least it would let them put out a credible roadmap.

First, let me tell you why I post anonymously. Too many people in the hardware areas know

me, and some of them will be able to deduce who I am just from what I write below. Don't get me wrong, I loved working at SUN, but there are huge problems that layoffs and yet another reorganization aren't going to fix until the people in charge recognize that they are the actual problem.

Let's review shall we, a bit of history first.

UltraSPARC-V (code name - Millenium) was indeed too little, too late. The 1.0 tapeout mask set was indeed sent to TI, when the cancellation came down from on-high, and the layoffs began.

Gutted the processor hardware engineering department.

Let's buy Afara (good move), as the Afara people mainly stayed, and out popped

Niagara I and Niagara II and VF on-time.

Moving to 2008:

UltraSPARC-T2+ (Victoria Falls) - There is still a sneaky little bug with a CSR (control status register) i.e. the NCX timeout register, but luckily another CSR has a bit that when turned on actually managed to correct the problem. Slight performance degradation (See earlier reg article, now you know why). The Zambezi chip was late (used in the 4-way systems), or this problem might have been caught during pre-silicon verification.

New philosophies began to creep into the picture (verification began to be performed by pure random coverage, and directed functional diagnostics were left to rot, even though they had huge numbers of pre-canned diagnostics already written)

UltraSPARC-T3 (KT) - Tapeout was scheduled for early September, and the project was nowhere close to being on track. Yes, 16 cores with 16 threads per core, with provisions to make an 8-way system. Reasons for delay: The 0-in coverage and assertions weren't written, and 16 core model builds weren't working two months before the supposed tape-out date.

Now, if SUN had a lick of sense, they would have moved the project manager from UltraSPARC-T2+ to UltraSPARC-T3. (UltraSPARC-T2+ did tapeout on time.) I won't go into too many details at this time, but it was more office politics, clashing egos, and the SUN culture than anything else.

Which only leaves ROCK. Rick Hetherington states "post-silicon analysis". This is normally known as the validation phase, although it's highly questionable if SUN knows the difference between verification and validation. Post-Silicon analysis in this case means looking at actual silicon. Tapeout 1.0 yielded actual silicon. Transactional memory did not work. They even had a problem with a legacy register, the "Y" register. There were a huge number of 1.0 bugs. They had new silicon about the time the July 2008 layoffs began. So let's do a bit of post-mortem on ROCK. First, ROCK underwent pre-silicon verification using only random test generation. (This would be ok, as long as your random code generators are top-notch) SUN's simply aren't and many of them are still being tweaked on. There are only a few people that really know how to use them to their maximum potential and the documentation on how to use them is horrible. Generally speaking, SUN's technical documentation for their processors is horrible. Anyone who has actually sat down and read a Programmer's Reference Manual for SUN knows this.

My post-mortem fixes:

Hire a large number of technical writers. All employees must document and formalize procedures fully so anyone can do your job. Demonstrate the correctness of your documentation through independent verification. Switching to fully-randomized testing has

already proven itself to be a failure. Hire people that can actually write SPARC assembly code.

Create a huge bank of directed code diagnostics. (To test the chips on the actual chip tester)

Random testing is great for catching a lot of bugs in the pre-silicon verification phase, but

it is horrible to take these same diags and use them on chip testers to screen actual parts. This

is where well thought out directed diags can make a world of difference in terms of coverage.

Organize a team that is truly in charge of the tester diagnostics. Switch to industry-standard

verification procedures. Send the design and verification engineers back to school on the company dime.

Finally, management must change it's thinking, and using the principles of Lean and Kaizen wouldn't hurt SUN in the least, starting with open and honest communication.

AC, thanks for the info. It will help investors to make better decisions for 2009. I hope JS reads your post and considers your "lean" and "kaizen" recommendations. Best of luck for the future.