% fortune -ae paul murphy

Betting on the future: T2 vs. Nehalem

It's April, quite a lot of senior IT people in larger business and government organizations have signed-off on the typical third to half of the fiscal 2009/2010 IT capital budget they pre-committed during fiscal 2008/9, and are now looking at what changed, and what didn't change, since the assumptions underlying the other half to two thirds of that budget were made - particularly those with respect to purchases from Sun and the Wintel partners.

My advice? wait - wait until the change implications deriving from Intel's Nehalem server releases are made clear by others, and wait until the fat lady really does sing on IBM"s attempt to kill Sun's SPARC/Solaris combination.

One of the things to notice about the Sun mess, by the way, is that none of the assumptions and extrapolations being made by pundits trying to ingratiate themselves with IBM by describing what's going on as initiated by Sun's management and then interpreting that assumption as proof positive that Sun's own senior people think the company should be put out of its misery, are correct.

What's motivating IBM is precisely the opposite: they know they can't compete with Sun in the marketplace and are using the opportunities created by the moral meltdown in Washington to shut Sun down via the legal and financial systems.

Sun's salaried management believes fiercely in the strength of the company -but are employees ultimately responsible to the board. So when a major shareholder first forces that board to consider selling the assets and then "facilitates" that process, people like Jonathan Schwartz have no choice but to mutter "Aye Sir", saddle up, and march off to do their best at the opposite of what they know is right for the company.

As I've said before, the right answer for both IBM and Sun would be for Sun to sell its x86 businesses to IBM along with guarantees on Solaris support - followed immediately by a move to employee ownership, and then putting all the wood behind Solaris and the CMT revolution. That would be good for Sun, good for IBM, good for the OpenSolaris community, good for AMD - and good for the country and the industry because it would increase both technology and price competition in the market while not just letting about 25,000 Sun people keep their jobs, but making those jobs both more demanding, and more rewarding.

Sadly, it's not likely to happen - but the fat lady hasn't sung yet and, meanwhile, there are lots of technology planners with money to spend and no real clarity about what to spend it on.

Intel's Nehalem processors look pretty good in this context: an optimized Solaris (and matching compiler changes) for Nehalem is due out next week, the server processors are a manufacturing step ahead of AMD, and nearly all current x86-64 Linux and Windows software should work out of the box.

Overall, right now, the risks on Nehalem are lower than they are on SPARC - but that's entirely an artifact of legal and financial manipulation, not the technologies. Thus people considering Nehalem as an alternative to SPARC need to think about three things:

  1. Nehalem does not appear to address any of the x86 security issues: from ring 0 vulnerabilities to BIOS based boot processes and the reality that you cannot know what software is hidden in various hardware components, Nehalem offers significant performance improvement on throughput and power use, but does nothing new on security.

    In other words, if you care about security, your choices remain SPARC or Power- and installed Power systems cost close to ten times what comparable SPARC systems do.

  2. Neither the Windows software environment nor that for Linux yet takes full advantage of Nehalem's multi-core structure. As a result, Intel's advance on its dynamic cache sharing facility in which one or two cores in a four or eight way chipset can speed up while others drop in frequency, can be very valuable in terms of getting some jobs done - but is more useful in workstations or intermittent duty servers than in heavy weight, continuous processing, applications.

    What you need to think about, therefore, is what your workload looks like - if you're doing file or mail serving to a small number of users Nehalem will be a winner for you, if you're serving Java pages to a large number of users both Sun's T2 line and AMD's latest products will give you more throughput for less money.

  3. You also have to think about the consequences of virtualization. Can Nehalem help you consolidate a dozen or more older x86 servers to one new one running many virtual servers? Yes - provided that you don't have performance killing network or storage bandwidth limits to contend with.

    If, like most people, you do, you'll find that the T2/super thumper combinations offer hardware support in all the right places, cost less than Nehalem to begin with, and could let you put off fixing your network and/or storage technologies for at least another year or two.

    Still, there are lots of variables here so the right answer is extensive testing - think of it as visible due diligence on the decision and chuckle quietly because it also buys you what you need most: time to see which way the dust settles on both Nehalem and Sun.

In summary:

So what should you do? Wait.


For those of you convinced that Nehalem thumps the T2, I'd suggest reading Anandtech's typically laudatory report on Nehalem performance. Written by Johan De Gelas, this is a nice piece of work (despite being on a dedicated Intel puff site :) ) but what I suggest you pay particular attention to is the benchmark results he cites - and not just the numbers he shows. Follow up on the public benchmarks cited, and you'll find many include other, rather less flattering, results relative to SPARC and AMD.

The first one he cites, for example, is the SAP SD2 "ERP benchmark". Follow that to the sap results site and you'll find that the dual 2.93Ghz Xeon 5570 (8 cores) Nehalem's score of 25,000 "saps" is about five times that obtained by a low end IBM Power 570 (2 Processors) but only about two thirds of the 37,650 reached by a Sun 5440 (4 T2+ processors) at 1.4Ghz.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.