Cost comparison: Solaris/SPARC vs Linux/x86

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.

SHARE:
18

I ran into a little story on siliconrepblic.com last week which started like this:

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.

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:

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,49913-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.

Topics: Hardware, Linux, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

18 comments
Log in or register to join the discussion
  • Coolthreads

    I'm beginning to doubt whether Coolthreads is really all it's cracked up to be. The
    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.
    Erik Engbrecht
    • That's right - but not terribly on point

      If your workload is light enough x86 is cheaper because the entry point is lower. Somewhat similarly, if your workload is single threaded and non concurrent the lintel box will usually be faster than the cmt/smp one.

      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.
      murph_z
      • I know

        But the question isn't really what we see today, but what we want to see in the future. Or at least that's the question that I'm interested in.

        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.
        Erik Engbrecht
      • Actually, yes it is on point

        You are making very sweeping claims about the cost effectiveness and performance of Coolthreads based systems without making any qualifications regarding the types of loads, when the performance of a Coolthreads based system is highly dependent on the type load that the system has to handle.

        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.
        Erik Engbrecht
        • No - and I'll bet a beer on that

          Specifically -
          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.
          murph_z
          • Ok, you're on

            Now go find a T2 so that we can conduct an experiment. I personally think Sun should sponsor it but I don't know if they would.

            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.
            Erik Engbrecht
          • I'll work something out

            I've been thinking that it would be fun to design a T2/Sun Ray demonstration project. Lets roll this idea into that: I'll do a blog on this sometime soon and see if we can't put something together somebody will fund.

            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.
            murph_z
          • Disk stuff

            He's got a 64GB machine that I don't think is under load reading a 1 GB file that is sitting in the cache. Performance plummets when you make the file much bigger than the cache, because the task becomes completely IO bound.

            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.
            Erik Engbrecht
  • Persuading

    The question answered by the quote that begins the Comment is: Why have customers switched from Unix to Linux?

    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.
    Anton Philidor
    • The most brilliant move by Linux

      There really is no such thing as Unix. It's an idea and a trademark.

      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.
      Erik Engbrecht
      • "... because people think ..."

        Good post.

        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.
        Anton Philidor
        • ...and people think...

          Linux is Linux. It's not. It's either Red Hat, SuSE, Ubuntu, <fill in your favorite
          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).
          Burana
      • no unix has fallen to Linux

        you say:
        >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.
        murph_z
        • What's the difference?

          Goto SGI's website and you see Linux, Linux, Linux. HP pushes x86 servers running Windows or Linux.

          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?
          Erik Engbrecht
          • Check the time lines

            All three companies went 100% windows.. then retreated from that (in DEC"s case after death) to offer Linux as a palliative.
            murph_z
          • Conspiracy Theory

            I think your seeing conspiracy where there isn't any. Demand forced the vendors to
            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.
            Erik Engbrecht
  • T2000

    On the T2000 running a simple dd read from an external storage array gives about
    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.
    Burana
  • RE: Cost comparison: Solaris/SPARC vs Linux/x86

    Cost comparison is a most important in our life because it can save our money with the price comparison. This is available in "AltiusCompare.com".

    http://www.altiuscompare.com/
    kishoreseo