Making sense of multicore pricing

• Tags:
• Virtualisation,
• Grid,
• CPU,
• Quad-core

Sally Whittle ZDNet.co.uk

Published: 30 May 2008 15:51 BST

• 
• 
• 
• 
• 

...access it, at what times, and how quickly does the system need to scale up or down?

This information should form the basis of a benchmarking exercise that will calculate the projected costs of running the application at the required level under a variety of architectures and with different application pricing models. "The key things to think about are how many processors you need, how they will be used, and what they will cost to run," says Crowe. "Different vendors may have different pricing for Itanium versus x86, so factor that into your calculations."

A major factor to take into account is whether you are likely to be consolidating servers and virtualising applications in future. In this environment, multicore processing can become even more complex.

With partitioning, a fraction of a processor can be dedicated to running a specific piece of software and, under some pricing schemes, customers may end up paying for a full processor. If you have a 16-way server and run 'X' on four single-core processors, will you pay for four or 16 processors? Virtualisation is the key issue being faced by the industry, says Crowe: "If you're running 20 applications on a single server, you need to ensure you're not running anything in an unlicensed model. That means deploying management tools that will report back utilisation in a way that IT managers can ensure appropriate licensing governance."

There are an increasing number of reporting tools available to monitor exactly what resources are dedicated to specific applications in a multicore processor — some supplied by software vendors, others by third parties. Crowe recommends investigating the options and using reporting tools to see how applications run in a given environment before making major new investments.

Next, consider whether the applications you want to run are designed for a multicore environment. The reality is that many enterprise applications cannot support the multi-threading needed to perform at speed in a multicore environment, says Illsley. "If it doesn't support multi-threading, you won't see any great improvement on a multicore processor, and you might end up increasing your licensing costs for no reason at all," he says. "In fact, if you're running the wrong application on a multicore, virtualised machine, you may even see performance get slower. So always be sure to ask whether applications have been written for this environment, and ask to see benchmarking data."

Getting enterprise software to run in a multicore environment is a major undertaking, argues Simon Garland, chief strategist of Kx Systems, a financial-software supplier. "It's not like you can just sprinkle some magic multicore fairy dust over a database-management application and suddenly it runs twice as fast," he says. "You're talking about completely rewriting hundreds of man hours, and that's not something vendors can do overnight."

Kx prices its software by core, but Jones admits this isn't always easy. "They might be running on a machine with 16 cores, but want to license four — that's not easy. With Linux, for example, the OS [operating system] is forced onto core zero, so we might end up putting you on a core that's already being used. There are cores and cores. Do we want four CPUs on one core, or one CPU on each of four different cores? How will this affect utilisation and load across the hardware?"

Once a good idea is obtained of what application is required, what performance is demanded (and possible), and the likely costs of buying the software on different processor architectures, Illsley advises that IT managers do some number-crunching. "Think about what this application will cost in terms of transactions per watt," he says. "Given the fact that power and cooling are the major factor in today's datacentre, enterprises should be making this the basis of purchasing decisions."

Opportunity amid the confusion
The current confusion around pricing for multicore systems presents large IT departments with something of an opportunity, adds Longbottom. Enterprises are increasingly ignoring the list price and simply approaching vendors with a figure of what they want to spend, he says. "If it's reasonable expenditure, then vendors will negotiate and come to some agreement; they're not using the list price, because there's no reality there."

Smaller businesses can't expect the same degree of flexibility, so Longbottom advises them to simply bypass the issue and opt for subscription-based software licences, where users pay per seat. "I think it's likely to become increasingly popular, particularly where software is hosted internally but paid for by the seat," he says.

The market is still evolving and vendors are learning as they go along, Longbottom adds. "When Oracle brought out 10g and priced it per core, the market basically said that was stupid, and Oracle changed the pricing model," he says. "Software vendors are ultimately pragmatists, and they'll do what works for customers in the end."

However, there's no getting around the fact that pricing issues are messy and will remain so for a couple more years at least, adds Giera. "Until customers have experience of buying systems under these models, it's very difficult to judge how it will affect their spending. I think vendors with the simplest pricing models will definitely gain an advantage."

• 
• 
• 
• 

• Share this article:
• Digg
• Slashdot
• Del.ici.ous
• Stumble
• Reddit