|
Oracle's Multicore Pricing: Right Direction, Not
Far Enough
by Timothy Prickett Morgan
As we all know, the processor industry has been in the middle of a transition, and one that has software vendors like Oracle in a quandary. Chip makers can add performance by shrinking chip transistors every 12 to 18 months and jacking up clock speeds and adding features such as cache. But chips are getting too hot, which burns users twice: once with the electric bill for running the chip and again for the air conditioning bill to get rid of the heat the chip creates as it runs.
The other problem is that the temperature of chips (particularly processors) is climbing at an exponential rate as clocks get cranked up, and this temperature curve is quite a bit steeper than the exponential rate of growth in clock speeds that should, in theory, lead to higher processor performance but, as it turns out, often does not. All that extra clock speed sometimes goes right up the chimney because processor speeds are outstripping memory speeds, leading to CPUs in servers having an average utilization of between 10 to 25 percent. You make a lot of heat with these chips, but you don't get a lot more for the money. Something had to give.
So in the past couple of years, as IBM blazed a path with its dual-core Power4 chips in 2001, the entire chip industry has moved away from cranking up clock speeds to boost performance to adding multiple processor cores to a single chip to boost performance. And this has caused the software industry tremendous grief.
No two vendors have the same way of pricing software, but after experimenting with all kinds of software pricing schemes, the consensus in the wake of dot-com boom was that perhaps the simplest way to charge for software was by counting processors and licensing software on a per-CPU basis. Some platforms in the industry, such as the IBM mainframe, OS/400, and AIX platforms, use a mix of tier-based or system-based pricing for software as well as per processor charges. But for IBM's zSeries, pSeries, and iSeries line, a core is equal to a processor--at least for now. When and if IBM moves beyond the two-core Power4 and Power5 chips to Power chips with more cores (and there are indications that IBM may not go beyond four cores in a single chip, and may not go beyond two cores per chip on big iron), the company may re-examine its pricing practices on multicore machines.
Since IBM put the first dual-core processors to market in October 2001, Hewlett-Packard and Sun Microsystems followed suit in 2003 and 2004 respectively, Advanced Micro Devices and Intel are doing so right now with their Opteron and Pentium D processors for servers, and Fujitsu will follow suit in 2006 with the dual-core Sparc64-VI. Intel is expected to roll out its dual-core "Montecito" Itaniums at the end of this year as well as various dual-core 64-bit Xeons, all of which should appear in systems in early 2006. While everyone on the hardware side agrees that multicore processor architectures are the only way we can boost server processor performance, there is considerable disagreement as to what constitutes a processor and what is not. Some vendors count chip sockets as a processor--Intel, AMD, Microsoft, and Sun Microsystems are in this camp. They think that whatever crazy things a chip maker does to boost performance inside a chip socket is their own business--whether it is using the extra transistors they can cram on the chip thanks to advanced chip-making processes to create large L1 and L2 caches, integrate memory and cache controllers, or replicating processor cores--is their own business. IBM behaves this way for its xSeries machines and for certain of its software that runs on Linux or Windows, but as I pointed out above, a processor core is a processor as far as IBM is concerned for its other server lines.
These vendors have been bringing considerable direct and indirect pressure to bear on Oracle, the leading database vendor on RISC and X86/X64 architectures and the second-largest application software provider, to see software pricing the way they do. IBM has split the difference. The direct pressure has come as Intel, Sun, and AMD have tried to convince Oracle to price its software on a per-socket basis. The indirect pressure, thanks to direct competition in the market of computer software and hardware buyers, is that Oracle has to compete with companies that are more generous by calling a socket a CPU, not a core.
Socket to Me
So last Friday, Oracle updated its software pricing for its Oracle 9i and Oracle 10g database software, and rather than completely move from its position in the core-price camp to the socket-price camp, Oracle split the difference. And, as was the case with a complex pricing scheme that Oracle had a number of years ago (which it ditched because of the complexity), the new database pricing will make customers do some math.
In a nutshell, Oracle's new pricing for databases says a core in a multicore processor is equal to 75 percent of a single-core, single socket processor. To reckon the price of the software for multicore platforms, you count up the cores, multiply by 0.75, round up to the nearest whole number, and the multiply the result by the per-processor charge for the Oracle database software. In effect, Oracle seems to be scaling its pricing very loosely to the performance boost that comes from the additional cores in multicore processors, and being a little generous at that since in many cases, moving from one to two cores can result in a near doubling in performance at the same clock speed on threaded applications (the extra core does nothing for a single threaded application). The 75 percent number might be Oracle's recognition that clock speeds are probably going to inch down a bit as cores are added, since a small downward change in clock speed can result in a big savings in electricity and heat.
Pricing for single-core, single-socket processors remain unchanged, by the way. And Oracle says further that for servers that have only one socket supporting a maximum of two cores, 10g Standard Edition One and Standard Edition, the entry and midrange database products, will be priced as single processors. Here's how it lays out:
| New Oracle 10g Database Pricing |
|
|
|
|
|
|
|
|
Standard One |
|
Standard |
|
Enterprise |
|
|
Old |
New |
Change |
Old |
New |
Change |
Old |
New |
Change |
| 1 socket, 1 core |
$5,000 |
$5,000 |
0% |
$15,000 |
$15,000 |
0% |
$40,000 |
$40,000 |
0% |
| 1 socket, 2 cores |
$10,000 |
$5,000 |
-50% |
$30,000 |
$15,000 |
-50% |
$80,000 |
$60,000 |
-25% |
| 2 socket, 2 cores |
$10,000 |
$10,000 |
0% |
$30,000 |
$30,000 |
0% |
$80,000 |
$80,000 |
0% |
| 2 socket, 4 cores |
$20,000 |
$15,000 |
-25% |
$60,000 |
$45,000 |
-25% |
$160,000 |
$60,000 |
-63% |
| 4 sockets, 4 cores |
|
|
|
$60,000 |
$60,000 |
0% |
$160,000 |
$160,000 |
0% |
| 4 sockets, 8 cores |
|
|
|
$120,000 |
$90,000 |
-25% |
$320,000 |
$240,000 |
-25% |
| 32 sockets, 32 cores |
|
|
|
|
|
|
$1,280,000 |
$1,280,000 |
0% |
| 32 sockets, 64 cores |
|
|
|
|
|
|
$2,560,000 |
$1,920,000 |
-25% |
Figure 1: Some Oracle customers get a 50 percent discount, others get
25 percent discount on multicore machines.
The examples in Figure 1 assume that all of the cores in each box are activated, but they don't have to be. The rounding comes into play when you activate processor cores individually, which you can do on mainframe, RISC, and Itanium servers and which we will soon be able to do on X64 machines. So if you activated three cores on a box with two dual-core chips, that would give you 2.25 as a factor, but you have to round up to three, which means a processor core is still a processor. And when you activate the remaining core, that is 0.75 times 1, which rounds up to one. Which means you owe the full price for that core. In many cases, this will be a difference that makes no difference; in some cases, it will mean a 25 percent discount.
But, for Standard Edition One and Standard Edition databases running on single-socket, dual-core processors, this will be a 50 percent discount, and that is pretty hefty. That puts Oracle's pricing for these products on par with Microsoft SQL Server and IBM's DB2. I happen to think that Oracle will have to extend the generosity to two-socket, four-core servers running the Standard Edition database. Above this processor core threshold, most customers are running Oracle databases on Unix machines, not Windows boxes.
Of course, if Oracle really wanted to be fair, it would not do any rounding at all and use decimals to calculate licensing fees. Or, it could allow rounding down from the half-way mark and force rounding up from the half-way point.
And if Oracle wanted to be really productive, it would have CPU-based pricing for its application suites. Prior to their being merged into Oracle, PeopleSoft, JDE, and Oracle all had radically different pricing models for applications. Oracle has user-based and usage-based pricing schemes for its suites, and it is unclear when or if the company will switch away from its value-based licensing for the PeopleSoft suites. (Value-based pricing uses an algorithm that takes into account the industry, revenue size, employee count, and other salient factors describing a company to calculate the price of the software.) Oracle could do in applications what it has done with databases: provide consistent, understandable, and public pricing for applications that are available on the Web.
Let's Get Virtual
What Oracle's new pricing scheme for databases does not clear up at all is the issue surrounding the use of virtual machine or logical partitioning on servers. With partitioning, a fraction of a processor can be dedicated to running a stack of software. Oracle's pricing practices today are such that if customers demonstrate that they have isolated a certain amount of processing capacity in a system to run Oracle databases, Oracle will charge accordingly. So if you have a 16-way server and you only run Oracle 10g Enterprise Edition it on four single-core processors, then you only pay $180,000, not four times that.
Still, with virtualization, decimal math is a must and so is some sort of factor to measure usage over time. One of the key benefits of virtual and logical machine partitioning is that partitions are dynamic as well as fractional--you can dedicate 2.5 cores to an Oracle database running on Unix now, and move it up to 3 cores or down to 1 core as conditions dictate. An equitable software pricing scheme has to take into account usage over time, not just a static snapshot or a theoretical maximum within a partition. In this way, the software pricing does not negate the flexibility gained from partitions.
What the software industry needs is to define a quantum of computing power that spans server architectures and operating systems. Then, the industry needs to create and adhere to a unified software metering system that can be installed on any machine and be used to meter the usage of software. Then, we can buy software like we do electricity, water, telephone, cable, and other commodities, and stop worrying about capacity planning and doing math.
RELATED STORIES
Microsoft Backs Intel, AMD on Dual-Core Licensing
Rotten to the Core: Chips, Lies, and Software Licenses
|
COMMON
