Cost comparison: Solaris/SPARC vs Linux/x86
Summary: Compare the cost of "Linux" -meaning gnu/linux on x86 - to the cost of Unix -meaning Solaris on ultraSPARC- and you get a surprise: "Unix" is cheaper provided you need enough capacity to get to the UltraSPARC entry point.
I ran into a little story on siliconrepblic.com last week which started like this:
Cost drives firms from UNIX to Linux28.11.2007 - Almost two thirds of Irish IT experts say the main motivation for migrating to the Linux operating system from UNIX for use in servers is cost, according to a recent survey from Novel's Open Enterprise Summit in Dublin.
While cost may be a key driver, 48pc of those surveyed felt that hardware obsolescence and modernization issues were contributory factors, while 39pc felt that support issues relating to UNIX was a concern.
Now, in reality, Linux is exactly what it set out to be: "a free Unix for the 386" - the distinctions this story appeals to got started as a cynical Red Hat strategy aimed at exploiting the ease with which people could port from one Unix to another to make sales against Sun instead of Microsoft, and have no basis in reality.
In reality, the cost/performance balance for Linux and Solaris on x86 today is exactly what it was in 1995: they're both free and if you run them on the same hardware there's no cost difference.
Still, perception can become reality and everyone knows what Novel means here: that Linux on Intel is cheaper than Solaris on SPARC - and that raises a question: is what they mean any closer to being true than what they say?
There are four main cost groups to look at: OS licensing, hardware, application licensing, and long term operating costs.
Here's what Sun blogger Jim Laurent had to say about the OS licensing side of this:
Those who have seen me speak to customers, know that I have a "mantra" when asked to compare Solaris to various Linux distributions. It goes like this:
- Solaris does more than Red Hat
- Solaris costs less than Red Hat
- Solaris is open source like Red Hat
- Solaris runs on more Intel, AMD and SPARC platforms than Red Hat.
As a result, one FAQ I get is, "How much less does Solaris 10 cost?" According to our Sun subscription site and the Red Hat site list price comparisons for support and licenses are:
| Standard service 1 year (5 x 12) | Premium service 1 year (7 x 24) | ||
| Solaris 10 (up to 2 sockets) | $720 | $1080 | |
| Solaris 10 (unlimited sockets) |
$1320 | $1980 | |
Red Hat Enterprise Linux 5 (up to 2
sockets) | $799 | $1299 | 11-20% more than Solaris |
|
Red Hat Enterprise Linux 5 (unlimited sockets) | $1,499 | $2,499 | 13-26% more than
Solaris |
He's talking about Red Hat, but what he says is broadly true for other Linux releases, including SuSe: you can run either Linux or Solaris for free, but if you choose to pay for support, Linux costs more.
The hardware side of this isn't much harder to figure out. First, there's obviously no cost difference in the x86 world - your hardware costs don't change whether you choose to run Solaris or Linux because you can choose your OS after you get the hardware.
Compare x86 costs to RISC costs and you run into a scaling problem - but in the specific case of current generation UltraSPARC versus x86, the entry point for x86 is considerably below that for UltraSPARC, but get into the UltraSPARC performance range and it's significantly cheaper than x86.
Check out Sun's benchmark page for their coolthreads line and you'll see they own every price/performance comparison in their weight class - usually by margins comparable to that achieved in the notesbench test I mentioned yesterday.
So the bottom line on hardware is comparable to that on software licensing: for comparable performance levels, UltraSPARC is cheaper than x86.
The software licensing comparison is somewhat similar. First, if you're dealing with open source software the costs are the same - so the question comes down to cost comparisons across licensed products ranging from little known stuff like Maple and FrameMaker to widely licensed products like Oracle's database and applications.
Most specialty product makers, including Maplesoft, are retreating from OS based pricing - meaning that the base cost is the same regardless of run-time environment. Others, like Adobe, continue to support their Solaris customer base but don't yet have a Linux release.
In both cases, however, a Solaris network license delivered via Sun Rays costs significantly less per user than wintel per client licensing (for Adobe) or Lintel per client licensing (for Maplesoft).
Something similar is going on with enterprise class software. Look at Oracle, and the UltraSPARC has a significant pricing advantage over Lintel. There are two components to this: first, for standard edition products both the T1/T2 and Intel multi-core chips count as one processor and so pricing is the same - but since the CMT/SMP machines rather handily outperform the Xeons you get more bang for the same bucks with UltraSPARC.
Secondly, for enterprise and related products Oracle charges per core - but CMT cores count for 0.25 processors while x86 cores count as 0.5 each. As a result a four core x86 license costs the same as an eight core CMT license - and, again, the performance advantage makes the UltraSPARC cheaper - provided your performance needs put you into the hardware range where the benefit applies.
Long term costs generally come in three forms: staffing, space, and power. On the SWaP metric (Space, watts, and performance) the UltraSPARC CMT machines typically beat x86 servers by factors of two to eight (depending on your cost mix) - meaning that as long as your performance needs get you into the low end of the CMT/SMP range, your space and power costs for UltraSPARC will be significantly below those for comparable Lintel capacity.
The staffing issue is the hardest to settle. Workloads are significantly affected by user desktop choices - companies using Sun Rays don't need help desks and and get improved user productivity by shifting application help to key users - but not by Unix server OS choices.
Notice, however, that the issue here is bottom line significance, not FTEs. A Solaris/CMT data center will unambiguously need fewer FTEs than one running Linux on x86 simply because there are fewer machines to administer and Solaris includes a range of powerful administrative tools - from ZFS to the systems management framework and hardware predictive self-healing - that are not available on Lintel. However, the numbers involved are small and many people believe that competent Linux staff can be had for less than comparably competent Solaris staff. We don't know, therefore, which is really cheaper: staffing for Lintel or staffing for Solaris on UltraSPARC - all we can say with reasonable certainty is that for data centers needing at least two sysadmins, the Solaris/CMT choice will require fewer FTEs.
So what's the bottom line? That Unix vs. Linux thing is a lie on its own but investigate what's really meant and you find that Solaris on UltraSPARC is generally cheaper than Linux on x86 on licensing and support, on tools and applications licensing, on hardware, and on SWaP while requiring fewer FTEs in the data center - but because those FTEs may, or may not, cost more money individually we don't know if staffing costs are higher, comparable, or lower.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Coolthreads
problem is the performance boost seems to assume that you have a very
parallelizable problem. In practice, this means you either have code that has been
intentionally written to execute in parallel, or you have something that is inherently
parallel like serving web requests (or other client/server type requests) under load.
I say under load because you need enough requests coming in to keep all those
coolthreads busy. If you only receive a couple concurrent requests at a time, it
doesn't help.
I direct you here:
http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
The results for non-parallelized code are on par with 5 or 6 year old x86
technology. The results for parallelized code are pretty good. What I'd like to see is
the same table for an x86 box at the same price point as the T2.
Some of my thoughts on the parallelization part:
http://erikengbrecht.blogspot.com/2007/11/adventures-in-widefinding.html
http://erikengbrecht.blogspot.com/2007/12/adventures-in-widefinding-
complexity.html
http://erikengbrecht.blogspot.com/2007/10/why-test-parallelism-on-simple-
function.html
The challenge is a lot of computing out there is done with code that wasn't written
to run in parallel, and currently there is no really good way to enable someone to
write serial-esque code and have it be spread over multiple cores.
That's right - but not terribly on point
However.. most corporate workloads don't fit either model - you don't usually see one user request taking a long time, you see many concurrent user requests, each requiring relatively few resources and (often) each dependent more on storage response than cpu response.
I know
Coolthreads is tomorrow's technology (well, today's as well, since it is here) and it is optimized for today's workloads. Existing parallel software will run very well on it, especially all those IO bound enterprise applications.
But 20 years from now will we still be primarily providing applications that simply shuttle data from one place to another?
I certainly hope not. I'm rather bored with watching every advancing technology be used to do more of the same thing it was used for 40 years ago, just in a substantially less efficient manner.
Anyway, I guess I am a little off topic.
Actually, yes it is on point
You're drawing overly general conclusions from specific data. I can think of a couple web applications we have that contain analytical functionality that would perform extremely poorly on Coolthreads. I know of tons of things that people do on their desktops involving scripting or other "lightweight" programming that would perform extremely poorly if you moved them to a SunRay hooked up to the Coolthreads based server.
Your specific facts are true but the general conclusions you draw from them are false.
No - and I'll bet a beer on that
1 - you'd be surprised how well "scripting" apps run on the T2. Remember your Xeons spend most of their time waiting for memory - run multiple users doing those same tasks on a T2 and average completion times won't be much different than if you had them all on personal xeons.
2 - general conclusions require generality. Your argument that my conclusions are overally general assume that true cpu dependent single threaded tasks constitute a majority. That's not true - so your contrary conclusions falsely claim generality....
-- as for your earlier comment about code twenty years from now: I sure hope you're right, but don't see how that mitigates against coolthreads now.
Ok, you're on
We, and of course other contributors here, can dream up a small suite of tests representing different types of workloads. Then we can compare x86 desktop-type configurations and T2 based configurations.
Until Tim Bray started his Widefinder discussions I was a big believer in Coolthreads. The principles behind the technology just make sense. But then I noticed how badly my Intel based laptop beat the T2 when running serial code. I knew it would - but the magnitude was rather shocking.
So now I'm a skeptic. Don't get me wrong, I would probably buy one for most general enterprise computing workloads. I still think it's a cool technology, and in the future I'm sure those cores will get faster while Intel will just keep on growing more cores. In the end I think Sun has it right, and I think for the most part Sun has it right right now. But at this point the performance characteristics of T2 seem to be somewhat enignmatic.
I'll work something out
I have access, FYI, to a T2000 - but not a T2 based machine.
--
I looked briefly at Tim Bray's stuff. Note the disk limits and special software on the tests he reports. Don't take them as indicative of much. For better numbers check out the coolthreads benchmark pages and reports.
Disk stuff
So he's running a memory bounded benchmark, which is something something that the T2 should really good at assuming it is given parallelized code. I think the results largely show that.
His little Ruby program also falls into a relatively common pattern. Read in a bunch of data, filter it, find relations, and then tabulate the results. Sure, it's boring, but much more interesting applications fall into the exact same pattern. They just use more CPU.
Persuading
The primary answer given is to reduce costs. The secondary reasons include modernizing the hardware and issues with support.
So let's assume that those switching to Linux believe that it's cheaper, and they also believe that use on new hardware and obtaining support are easier.
Vendor issues.
Murph, considering Sun specifically, you're actually again making the point that upper management does not care to make a case for the company's products.
Your solution is to provide a more detailed documentation of the hardware/software superiority, perhaps making the already-existing pages of documentation more compelling to the few who would pay attention and the fewer still who might be persuaded by necessarily generalized performance numbers alone.
That's reinforcing an irrelevant case.
Whatever the actual issues, the impression has apparently grown that Unix is obsolete software running on ancient hardware, with support as obsolescent. A successful response must emphasize considerations other than cost and performance, no?
Quoting the quote:
Cost drives firms from UNIX to Linux
28.11.2007 - Almost two thirds of Irish IT experts say the main motivation for migrating to the Linux operating system from UNIX for use in servers is cost, according to a recent survey from Novel???s Open Enterprise Summit in Dublin.
While cost may be a key driver, 48pc of those surveyed felt that hardware obsolescence and modernization issues were contributory factors, while 39pc felt that support issues relating to UNIX was a concern.
The most brilliant move by Linux
Several Unices have fallen to Linux, or are at least the living dead - Tru64, Irix, and HP-UX.
So Linux has convinced the "business people" and lawyers that it is not Unix - because it does not contain any Unix intellectual property and doesn't pay to use the Unix trademark, and convinced techinical folks that it is (even if they have been trained to insist that it's not).
So you're a business faced with replacing an obsolete Unix. You don't understand the differences between all the Unices, so when someone suggests replacing the current Unix with another Unix you don't understand how that could possibly solve the problem. But Linux is not Unix, so it solves the problem.
The result is Sun and IBM customers get screwed. Sun because people think their alive and kicking Unix is obsolete, and IBM customers because they get to buy an IBM linux box because it's cheap and then an IBM AIX box because they really need something more robust.
As usual, IBM wins.
"... because people think ..."
I'll add that the issue of whether Linux is or is not Unix is of interest only to those who care about such technical distinctions. That's not the same group as the one forming impressions, attitudes, even judgments to make a product choice.
That Linux can be identified is sufficient to distinguish it from Unix.
...and people think...
distro>...
Why are there some many? Because none of them are perfect.
Some people change their favorite distro more often than their underwear. Some are
even forced to, because the lack of certified applications (not talking about underwear
anymore).
no unix has fallen to Linux
>Several Unices have fallen to Linux, or are at least the living dead - Tru64, Irix, and HP-UX.
but all of these died because "business people" in the companies responsible opted to work with Microsoft.
What's the difference?
You're right - business people killed those Unices. They did it because maintaining your own processor architecture and your own OS are expensive - and Linux on x86 makes it seem redundant.
Windows certainly played a part. They need hardware to run Unix and the need hardware to run Windows. Linux lets them use the same hardware for both.
Why spend all that money on R&D when your suppliers will do it for you?
Check the time lines
Conspiracy Theory
support Windows, economics made maintaining their proprietary products unpalatable, and Linux enabled them to kill of their proprietary Unix offerings while
still offering something very Unix-like.
I think you're tilting at windmills.
T2000
60-70MB/s per thread. iostat showed 0 busy% for the LUN.
On a current V490 I remember we were getting around 120MB/s /per thread.
On the T2000, running two dd's in parallel showed a throughput of around
120MB/s while busy% was around 20%.
When running three dd's in parallel toward the same LUN, we were at 160MB/s with
disk busy% at 100%.
I didn't investigate further if this was a limitation of the storage array or the 2Gb FC
link.
But it showed that a single HW thread was capable to throughput 60-70MB/s.
Another test with Sybase on T2000 vs. V490, showed a good scalability with DB
connections > number of available HW threads on the T2000. Avg. response times
stayed almost constant.
On the V490 the avg. response time when running only one connection (single-
thread performance) was 3x better than on the T2000. The more concurrent
connections, the worse the response-time on the V490.
Unfortunately, for this application, the amount of concurrent users seldom exceeds
a handful.
RE: Cost comparison: Solaris/SPARC vs Linux/x86
http://www.altiuscompare.com/