With the exception of the Galaxy machines, where the bottleneck was at AMD, Sun are now pretty good about having product available in reasonable volumes at launch. As Ash mentions, early versions of these machines are already in the key customers for evaluation.

Those with old fart credentials as good as mine will remember the debacle when the SPARCstation was launched in (I think) 1990 - customers were literally waiting 6 months for their orders to ship, and it nearly broke the company. I reckon there are still scars from this within Sun.

As for these machines, filling them is going to be the challenge. For large, web facing and horizontally scaled workloads they will be simply awesome. For databases with very heavy OLTP traffic they will be ideal. For single threaded workloads they will be as unsuitable as the existing CMT machines. And for virtualised datacentres, they are a logical next step.

What Sun don't tell you is that Ubuntu runs really well on their uberthread boxes. Which is lucky coz a LOT of people prefer it to Solaris.

Depends on the database, of course; many databases really don't like running on systems with lots of processors...

But yes, bloody amazing for application servers, no doubt. The T1 gave particularly impressive performance for Erlang messaging applications; it scaled more or less perfectly up to 32 processes, showing that the SMT thing does work.

The chip in the Maramba (2 socket box) is not the same as in the T5220. It only has two memory controllers for the eight sockets vs. the four memory controllers in the T5220. This cuts the memory in half and is a huge bottleneck for bandwidth.

They also dumped the integrated ethernet. The Coherency units to try to get this chip to support SMP pushed off even more function.

As far as Batoka (4 socket) Sun is trying to position it as a database box, but the "light thread" problem is not solved with more chips.

It will have 1.2 and 1.4GHz processors 6 or 8 cores

8 PCI-E slots (all 8x) two inteded for graphics and two shared with XAUI

up to 28 pci-e slots with 2 i/o boxes

up to 64 DIMM slots, 256GB with ultra expensive 4GB DIMMS.

128 partitions with the thread based partitioning

4U''s, FB-DIMM,

Four 1.1KW power supplies - WOW

Beware of this niche box which only looks good compared to SPARCIII.

From Denis:

Yes we went from 4 MCU to 2 MCU but redesigned the MCU at the time for Optimal

VF performance

The T2 was provisioned with 60GB of raw bandwidth but anyone that knows FBDIMM knows that higher bandwidth can be achieved by having multiple DIMMs on the same channel

The N2 only has 2 DIMMs per channel whereas the VF has up to 4 DIMMs per channel We can achieve over 30GB/s of STREAM memory bandwidth across 2 VF that blows away ALL Intel , AMD and Power servers

Added to his is extremely low latency to remote memory.

From Mat:

In terms of database, it is a proven, great OLTP server with orgs such as eBay satandarising on it for Oracle. There are some database workloads where it is not optimal, ie single thread batch, but for that Sun has M-Series and x64

"Satan" darising....Wow now it that is not a slip of the keyboard on your "reference".

I just found this on realworldtech

http://www.geocities.com/sunsrockchip/

Why does Sun have so many leaks? on purpose? Layoffs? Delays? Vaporware?

Why would anyone buy NIagra/Victoria Sun boxes when the price-perofrmance of Intel is so much more compelling?

Locked into Solaris from an app perspective? More fool you - or better still migrate yourself off your father's hardware and get with the programme: run Solaris X86. Better still Ubuntu/RedHat on X86 is a whizz

"...customers were literally waiting 6 months for their orders to ship, and it nearly broke the company. I reckon there are still scars from this within Sun."

I doubt there would be anyone left from those days - they've all been RIF'ed!

I don't think I understand why there are so many people religiously bashing Sun or bashing non-Sun solutions for that matter. I think the compelling reasons for choosing the Niagara platform is the scalability for the application workloads that does really well on. It also runs rather efficiently from a power and cooling perspective. So at that point the price/performance discussion becomes very interesting. Do you use a box with cheap initial acquisition costs that hits the wall sooner or a slightly more expensive box that scales pretty well and offers a compelling argument in the operational costs. It all depends on what you want to do with it. We as customers have a choice, right? To continue a bit on choices, you also have the choice of Solaris, Ubuntu and Gentoo on the T2K and Solaris and Ubuntu on the newer Niagara server. People also often bash SPARC as an expensive, proprietary architecture. I'm not sure I understand that. SPARC has been kind of a consortium based standard long before x86 became a defacto standard in the server space. Check out http://en.wikipedia.org/wiki/SPARC for details. Now, Sun has even open sourced (http://www.opensparc.net/) the architectures for the Niagara chips. A lot of cool stuff came out of SPARC so to simply dismiss it is to take a very parochial view on computer architecture.

A lot of really smart engineers designed these systems and a lot of sophisticated customers buy these systems after doing extended evaluations. If you say that these systems are stupid and not price/performant, doesn't that mean that you're calling everyone who designed as well as those who purchased these systems stupid or ill-advised? That seems a little arrogant, no?

I also don't get why there tends to be this anger towards Solaris. There have been a lot of cool things to come from Solaris with respect to Containers, resource management, ZFS, NFSv4, DTrace, SMF, FMA, etc. How can you just dismiss it as inferior to other operating systems? Seems rather biased, unfair and uninformed. If you look at a recent European Union report, Sun actually contributes the most to the open source community, so how can people continually bash them for being closed and proprietary? The actual report can be found here: http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf.

To be fair don't get why many Sun bigots have historically bashed the different flavors of Linux. Frankly, I think it is silly on their part to dismiss the contributions that Linux and the Linux community have made to operating system design and overall growth in computing and computer science. Both Solaris and Linux have their strengths, which can be exploited by matching the right OS/Hardware combination for the right job.

As far as app lock-in, I think that's an inaccurate statement because if you develop in Java or C++ and you develop your code for portability, you should generally be OK. If you use an application server, as long as the application server runs on whatever flavor of OS/hardware combination, you're fine. The same goes for ISV applications that are supported on different OS/hardware combinations.

I really don't understand the religious alignment toward one vendor or another because all these innovations just mean more choice for customers. If IBM, Sun, Intel, AMD, Fujitsu, HP or someone else come up with a cool processor, server, or technology, it benefits everyone because you have another choice. If I test something on these platforms and I find that one works best, great. I don't necessarily have to hate the others.

I think there is also a lot of hate from many old ex-Sun farts who go out of their way to bash their former employer. This isn't to say that all ex-Sun employees are like that. However, I've heard that Sun has historically been a good company to work for. Many people probably got used to the good life during the dot com boom. When it went bust, and these guys got RIF'd they got sour. Get over it. Lots of companies lay off people. That's the way the world works these days. Lots of organizations have high turnover depending on the industry. I guess these guys stayed bitter because they were way too comfortable and were thrown out into the real world.

Match the application workload to the right OS/Platform combination for the best return is all I'm saying. Stay away from the dogmatic religious stances.

"....We can achieve over 30GB/s of STREAM memory bandwidth across 2 VF that blows away ALL Intel , AMD and Power servers...." Really? I think you might have meant 30Gbps, and then I'd be curious to see how you can get that figure seeing as the figures I have seen for these servers doesn't come close to that, but I'll assume you have been quoted them by Sun. However, the sx2000 chipset on the Integrity server celboards has 17.1Gbps, and as I can address all the memory in all the cellboards in a system in parallel, that means a two-cell system has 34.2Gbps of memory bandwidth - oops, I think that just topped your 30Gbps! So much for "blows away ALL Intel". Actually, in a double-cab Superdome, I could run sixteen cellboards in a single system image, which would equate to 273.6Gbps, which kind of makes your statement lots of blowing but only the usual hot air. Wait, I hear you wailing that the Integrity cellboard systems are a different class, etc, etc, but then you should qualify your statements better, especially when you consider the likely pricetag of the African systems will force it to compete against mid-range Integrity and Power, and probably be many times more expensive than Xeon-based servers.

And, most importantly, you'll need lots of memory bandwidth to keep all the tiny caches topped up as they constantly flush and load data as each core switches between the one active and seven stalled threads. Whereas a Xeon, Itanium or Power will happily keep all threads concurrent, and use larger caches with far superior cache-hit ratios and better pre-fetch performance to ensure less time is wasted stalled. Which is why Xeon, Itanium and Power will thrash the African systems on real enterprise workloads which don't parallise easily into small, light threads, as found out with the niche T1 and T2.

Hehehe. I love how Matt assumes that the units of measurement are wrong, changes them, and then compares it to the Mad Max beyond Thunderdome platform and then claims victory a la Stewie Griffin (Family Guy).

He said "seeing as the figures I have seen for these servers doesn't come close to that?" Does that mean he hasn't actually run real application workloads on the platform?

Of course benchmarks must mean nothing then:

http://www.sun.com/servers/coolthreads/t5220/benchmarks.jsp

http://www.sun.com/servers/coolthreads/t5120/benchmarks.jsp

And now of course having about 2x the processor count with these new systems won't be a huge improvement cuz Matt says so ;-).

Interesting seeing all the blathering about the death of Sun and how Solaris/SPARC sucks, etc. Every few years this reaches fever pitch as Sun comes out with yet another nice box that addresses customer needs in some new way.

Is VF the right tool for every workload? No. Is X86 the right architecture for every workload? No. Certain workloads will simply run better elsewhere. No one's forcing or even suggesting that Niagara family machines are best in all cases.

The Niagara 1 boxes were a real eye opener for lots of Sun customers in that they gave many applications incredible throughput and at a reduced size and power footprint. The Niagara 2 boxes were even more performance in the same size box.

Nice to see Sun trying something different from the other lemming box makers.

Let's see when they ship, and compare it with their real competitors in the same weight.

When it comes to single thread or not-so-many-threads, any of them will suck to a x86 box both Intel or AMD, with their 1,2 ghz. They will of course suck even harder to Power6.

When it comes to multi-threaded workloads, let`s see how they can handle against, say, dual-case 3950M2 or 8-socket Opteron HP's 700 series that should be introduced in April. It might happen that you can get twice as many sockets and more or less the same multithread perf, with manyfold in single threaded workloads - and for a fraction of price

Sun ROCKs ;-)

Sorry, I couldn't help it.

Running at 1.2 GHz these things are obviously not very fast in a straight line (says the guy whose main DB is still running on a 900MHz Sparc III), but for certain types of database and web/apps server I'm guessing they are probably quite good.

I will have to recommend them to my firms IT architect - the same Guy who has insisted on J2EE as it is obvious that our system needs to be massively scalable - although I am still wondering if this means going from 2 to 4 users, or perhaps even 8 !

So are you saying the 30GB/s figure is correct? Not from the data I've seen, which I admit is not from my own benchmarking. I do have an opportunity to do some Slowaris benching soon, though, but that's going to be Slowaris on Transitive on - wait for it - a Superdome! And that's only 'cos even our Sunshiners have admitted that trying to port the messy app is just so daunting that they'd accept it on Superdome if it gives the performance advantage expected. Unfortunately, as the Sun salesgrunt put it, the app "isn't suited to the T5x20 systems" (strange, I thought it was the other way round), so no hope of doing a comparison. The only annoyance is we need the solution now and I couldn't get them to wait for a Tukzilla Superdome.

Gennadiy,

If you wanted to compare multi-threaded performance with a Niagara 2 system with an 8 socket AMD, why not make use of Sun's 60 day try and buy program and get a T5220 and a x4600 (8 socket dual-core, which is quad-core ready) and compare real application workloads? That way you can really test the strengths of the different architectures today.

One thing to keep in mind is, say you have an 8 socket AMD platform from Sun or the future HP. How much power will that consume with respect to a T5220? Also, how much heat will that generate that you have to pay to cool? Also, compare the rack unit footprint in the data center. Now, multiply that by a few hundred or even a couple thousand. Imagine having to pay for all that operational cost for an enterprise customer. Doesn't it really seem outlandish to consider a Niagara 2 platform?

Weird. Transitive? You're going to do app virtualization for a "messy app." Aren't all those system call translations going to minimize the performance gains? How are you going to debug any bugs that result between HW, OS, App virtualization, App, DB, and other Apps? I'm guessing throw faster clock rates at it from the aging Solaris box your currently running it on? If the app isn't suited to run on T5x20s, wouldn't it be easier to throw it onto a V445 or an M4/5000 without any messy app virtualization and call it a day? Solaris does have binary compatability from older versions of Solaris to newer ones, so that might alleviate many issues. You also have appcert to test app compatibility and the Solaris 8 Migration Assistant to migrate apps from Solaris 8 to Solaris 10 on SPARC.

You might even be able to throw it in containers with any apps/db that call on it and make use of low latencies and high bandwidth of intercontainer communication via the loopback network adapters that communicate at wire speed. At least with containers on Solaris 10, you can use DTrace to debug issues. To be honest, I've not seem many people running Superdomes or investing in Itanium. So what OS are you running? Is it HP-UX? I may be wrong, but this sounds like a home grown app that ballooned beyond manageability.

Most of the people I've seen who call Solaris Slowaris are usually playing with Solaris 8 and haven't played with Solaris 10. They usually play with Linux on recent x86 and say Solaris is slow by comparing it to Solaris 8 on old hardware. I've seen weird benchmark tests too where they make comparisons and say Solaris is slow, but don't peel the onion to look at things like:

1. Flavors of Linux enable write caching on disks. Solaris doesn't because it is meant for enterprise class and doesn't risk data loss upon power loss.

2. Don't compare Solaris to Linux on the same hardware with the same configuration.

3. Don't test a variety of application workloads or scalability of the application workloads. They often run a load generator that is in reality testing the capabilities of the client load generator, which can even be a simple workstation, rather than exhausting the limits of the server's HW/OS/App combo.

"....Solaris does have binary compatability from older versions of Solaris to newer ones...." You know, that's exactly what the Sunshiners were saying a few months back! This is one of those nasty projects through acquisition where half the original coders jumped ship and we're left holding the baby. The code was on Solaris 8 on SPARC and admittedly it's very stable on an E25k, but the E25k hasn't got enough stretch to cope with anticipated demand so we need an upgrade. The problem for the Sunshiners is that testing on Solaris 10 on an M5000 was not going smoothly, whereas as it runs as smooth as it did on the E15k on Solaris 8 on Transitive on Integrity, and the performance is better than what the Sunshiners projected for an M9000. So, given the options - messy and time-consuming code port and a new M9000 system to home, or just get another Superdome and run the same code - management went for the SD! Call me what you like, but if the code had run up to spec on an M9000 I would've agreed with getting the M9000 just to get this nightmare out of the way, but it hasn't worked out like that.

As for Transitive, one of our evil little games during testing was to put Sunshiners on the console and tell them they were patched into a loan M9000! It was hilarious hearing them happily saying how wonderful the M9000 was up to the point they twigged they were still on Solaris 8! I'm not kidding, some of them got up without realising they'd been checking code on an Itanium system.

Glad to hear that worked out for you. If it works for you, great. But I still think you're putting yourself at risk by adding the layer of application virtualization. While you have some observability into the application, if you hit a bug with the application virtualization layer, how will you confirm it without getting into a finger pointing match? It's hard to say why you're seeing what you're seeing. I just think you're exposing yourself to a situation in production where if you run into a problem, you won't get any help from any of the vendors and possibly few consultants because it would seem like one big mess that no one would want to touch. If you have the expertise in house, then great. I guess we can just agree to disagree on this point.

Just to clarify how binary compatibity works if your programmers programmed to the Solaris ABI (http://www.sun.com/software/solaris/programs/abi/). There are some constraints to ensure that the compatibilty works. That's why you have appcert and apptrace as tools to check whether it complies or not. Perhaps when the app was originally coded it wasn't compliant. I'm surprised Sun didn't help you with the binary compatibility. They kind of stake their name on it with the guarantee: http://www.sun.com/software/solaris/programs/binary_guarantee_terms.xml

In any case, the Solaris 8 Migration Assistant (http://www.sun.com/software/solaris/faq.jsp#q_7_1) is a P2V tool that packages up the Solaris 8 environment, migrates it to a branded Solaris 8 container and runs the app in a Solaris 8 container (i.e. if you do uname -a, you'll see Solaris 8). You still have Solaris 10 as the global zone and therefore can run DTrace, ZFS, etc. So in some ways, it basically does what the application virtualization offerings such as Transitive do. However, I think it is better in that you have all the observability tools of Solaris, which includes DTrace. If there's a problem and you have individuals in your staff who are competent staff with DTrace, you might be able to isolate the problem and recommend a solution in as little as 30-60 minutes (not exaggerating).

I do find it a little unusual that the E25K with the ability to scale to 144 cores and 1.15 TB of memory isn't enough. I can, however, see I/O or backplane being a bottleneck because the 25K has an older I/O architecture. I think it was released back in something like 2002? I find it unusual that an M9000 wasn't enough given 128 cores, about 2 TB of memory and its very fast memory and I/O bandwidth. Perhaps, it would have been a possibility to try out the Solaris 8 migration assistant and port the app on to your test M-Series platform and run it in a Solaris 8 branded zone. But then again, this isn't a forum where you can figure out exactly why there was problem.

I guess the decision to go your route was made because it wasn't worthwhile to do any more troubleshooting. But if you were considering these large systems, why were you considering a T5x20, a throughput oriented volume server, to replace these large configurations? They have guidlines on their website:

http://www.sun.com/servers/coolthreads/tnb/t2.jsp and recommended application workloads:

http://www.sun.com/servers/coolthreads/tnb/applications.jsp

Anyway, good luck with that and thanks for the conversation.

Wow, thanks for that big advertisment for Sun porting tools (which in this case were chocolate teapots). Of course, you're completely right, introducing a mixed-vendor solution, what were we thinking doing a six-month data burn-in parallel to the live system before switching over? And all that work locking all parties into a comprehensive support structure was just a waste of time, no? After all, Transitive are just such a bunch of half-arsed noobs without a clue about how their product works - NOT! That rubbish is straight out of the Sun FUD book and doesn't wash. The minute you add ANYTHING third party to a server - software, storage or networking - you can get yourself into finger-pointing exercises, regardless of whom the server vendor is. But if you limit yourself to the Sun-only world then your options are tiny to non-existant. In our case, the Sun options were more pricey and not assured success, whereas the Transitive solution worked out-of-the-box, plugged into our existing structure, was cheaper, and fitted with our strategy of moving away from a dying platform (SPARC).

You refer to SPARC as a dying platform but have chosen HP / Itanium. I don't know about SPARC but do you really think Hurd will keep the barely alive Integrity around much longer? He's there to make money and Integrity isn't doing it for him.

Oh yes, I'm sure Intel and HP will kill a bizz hat makes both of them money. Actually, you need to check the Reg article on 2007 Q4 server shipments, Integrity was the only line IA64/RISC line that grew in shipments, whilst Sun's SPARC (including APL) and T1/T2 kit dropped 10%. Overall, Integrity grew over 2007, whilst SPARC declined. Yes, I think that's quite clear evidence of which vendor's product line is dying, but since you seem blinded by the Sunshine I'll give you a clue - it's not the ones with the HP badges....

http://www.itjungle.com/tug/tug031308-story06.html

The reality speaks otherwise. HP shipped only 15,828 boxes with HP-UX boxes while Sun sold 56,339 SPARC boxes with solaris. While Sun's shipment is 10% down it's revenue is marginally up while HP's revenue is marginally down. It's clear most of the Integrity/itanics are shipping with Windows/Linux. With a shipment of only 15000 boxes, it's pretty clear which Unix is dying, HP-UX will die sooner than Itanic itself !! HP wouldn't care because it makes ton more money on x86.

...home of warehouse pricing...

(sorry.., jingle of a furniture store where I grew up)

Were I to move to Itanium, I'd have no assurance that another vendor could supply me with compatible systems should Intel/HP pull the plug on the architecture. They've done it before...PA, HP-3000,Alpha, i960,i860...the list goes on. Good luck finding a semiconductor firm willing to supply the market with work-alike IA64 clones-you'd have to sue Intel first.

Should Sun abandon SPARC, the demand for new SPARC cpus could be met by different firms with no legal hurdles to overcome-shit, they'd even be able to hit the ground running w/ Sun's own GPL'd designs.