Oracle: Mine is bigger and, um, more integrated

Ellison flaunts Sun unit

Comment With the European Union finally giving approval of the $7.4bn acquisition of Sun Microsystems by Oracle, the players in the IT industry can finally don their armor - made of iron, of course, and polished with software - to prepare for battle in the field of integrated systems.

Oracle and its Sun division, which could retain its name and at least some of its identity after the acquisition closes once antitrust regulators in China and Russia give the deal the nod, have a lot of work to do to knock Sun's processor, server, storage, networking, operating system, server virtualization, software development, database, and middleware roadmaps into shape and mesh them with Oracle's own operating system, virtualization, database, middleware, development tool, and application software stacks.

Oracle has - in the application space at least - been forced to let separate application stacks and their customers go on about their business and continue to run those apps and get Oracle support for those apps. It might be tempting to think that Oracle will do the same thing with Sun products, allowing Sun and Oracle variants to be supported and sold side-by-side with equal blessing. But if Oracle wants to wring profits out of Sun, as it has promised it can, this cannot happen with integrated systems. Oracle is going to have to either use or kill certain Sun products.

The first thing Oracle needs to do is decide if it wants to continue to design Sparc processors and manufacture servers. While Larry Ellison, Oracle's chief executive officer, has said repeatedly since last April, when the Sun deal was announced, that Oracle would not only remain committed to both the Sparc chip and the Solaris operating system, but also spend more on research, development, marketing, and sales than Sun did for the same products, what Ellison did not say is Oracle would expend budget on the Sparc T family of multicore/multithreaded chips designed by Sun itself.

<pFor all we know, Oracle and Fujitsu have been cooking up a new partnership whereby Fujitsu will be the designated Sparc hardware designer and Oracle will put Sun's engineers on a joint development effort. If I was Oracle, that's what I would be tempted to do. But then again, Fujitsu's Sparc64 roadmap is not particularly aggressive - we may see an eight-core "Venus" Sparc64-VIII processor in 2011 or 2012 in commercial servers - and it is just possible that Oracle has looked at the Fujitsu roadmap and the Sun Sparc roadmap from June 2009 (which El Reg outted last September when we got our hands on it) and found them both lacking. For the sake of Sun's Sparc server customers, I certainly hope that is the reaction Ellison and his team had.

In the wake of the announcement of the Oracle acquisition, Sun quietly killed off its 16-core "Rock" UltraSparc-RK processor and its related "Supernova" line of midrange and high-end servers, which were removed from the Sun roadmap last June. Sun had made no commitments to the Sparc64 lineup from Fujitsu beyond a goosed quad-core Sparc64-VII+ chip running at 2.88 GHz to be used in machines in 2009 and 2010 and a 3 GHz version used at the end of 2010 or in early 2011. That 2.88 GHz chip that was plunked into high-end boxes last October with slower variants in smaller machines, including the 2.75 GHz version announced in the single-socket M3000 last week.

Hitching its star to the Sparc64 chip line from Fujitsu is fraught with its own woes for Oracle. Fujitsu has been chronically late in deliveries and overzealous in its specs with the Sparc64 machines; the Sparc Enterprise M machines were a year late coming to market, and Fujitsu had planned to have quad-core chips to market years ahead of when they finally debuted.

More importantly, Fujitsu is in the process of outsourcing its chip manufacturing to Taiwan Semiconductor Manufacturing Corp, which adds another kink to the process and which possibly accounts for the large gap between the quad-core 3 GHz Jupiter-E chips due at the end of 2010 or so and the Venus octocore Sparc64-VIII expected in a year later. Fujitsu needs that Venus chip now, and the 3 GHz quad-core chip should have been here two years ago to meet competition in the market. Even more ominously, the Venus chips were part of a massive $1.2bn, 10 petaflops supercomputer project funded by the Japanese government that is at risk of being defunded.

Oracle might be tempted to drop modified "Niagara" Sparc T family processors into tweaked Supernova boxes and create what Sun should have made years ago: a line of SMP-capable Sparc T servers that go up to maybe 16 or 32 sockets. The problem is, Sun's own Sparc T roadmap from June 2009 was not particularly impressive. Back in August 2009, at the Hot Chips 21 conference, Sun gave out some feeds and speeds for the future the 16-core "Rainbow Falls" Sparc T processor, known variously as the Niagara-3 and the KT chip.

This chip will have eight threads per core and will be used in machines that have from one to four cores, for a maximum of 512 threads. And instead of hitting something close to 2 GHz, as Sun and its fab partner, Texas Instruments, should be able to do as they shift from a 65 nanometer to a 45 nanometer process in the middle of this year, Sun told customers last June that it could only hit 1.67 GHz with the Rainbow Falls chips. The current chips run at 1.6 GHz, so - basically - this will only be a 2X improvement in performance.

The Sun roadmap called for the "Yosemite Falls" kicker to the T3 chip, presumably to be sold as the T4, to have a new core and to revert to eight cores with eight threads per core in the design, running at 2.5 GHz and to be available in machine with one to four sockets. It is hard to imagine this chip having more performance than Rainbow Falls on database and Java workloads, which makes it peculiar, but the single-thread performance is interesting.

The "Yellowstone Falls" chip scheduled by Sun for the middle of 2012, which has only four cores and eight threads per core that runs at 3 GHz, is more interesting in that it will be used in servers with from 4 to 192 sockets. That same year, Sun was planning a related chip called "Cascade Falls," which runs at the same 3 GHz and with 16 cores and eight threads but which can be used in machines with anywhere from 1 to 8 processor sockets.

Basically, Oracle needs to pick either Yellowstone Falls or Cascade Falls and then get whichever one it picks to market in a server a lot faster than late 2012. Given these chips are implementing a new core and using 28 nanometer processes at a new fab partner, this seems unlikely.

The Sparc roadmap has traffic jams all over the place.

Which is why you can expect Oracle to continue to take the easy way out: promoting x64 servers based on chips from Intel and Advanced Micro Devices running either Solaris or Linux. Sparc customers will get what Oracle can cobble together from Sun and Fujitsu and they will no doubt pay a hefty premium compared to Solaris running on x64 iron.