Question [Toms] VMware doubles licensing fees for processors having over 32 cores

Gideon

Golden Member
Nov 27, 2007
1,608
3,573
136

While this might be done in anticipation of Cooper Lake, this really sucks for AMD. It essentially doubles the licensing fee for all ROME CPUs having more than 32 cores (previously it costed about the same as the top-end CPU, 7K, now it's double that).

Considering that WMware is Dell owned I wouldn't be surprised if this is also Intel's "Financial Horsepower" at work.

Overall it puts the rumored top end Ice-Lake with 36 cores into an interesting position (maybe a unicorn CPU?)
 

Jimzz

Diamond Member
Oct 23, 2012
4,399
190
106
I disagree, this is squared directly at AMD, and even ARM a little. Intels Cooper lake has fewer CPUs greater than 32. And the TDP, intels version of it, starts at 350watts for just 48cores. Let alone the price point as well.

Intel will push their 28 and 32core chips more and use the higher cost of software as an advantage/reason to not use AMDs higher core count CPUs.

This smells like similar BS intel did the last time AMD had a much better product. I wonder if Intels "marketing"" budget to Dell is increasing.
 
Last edited:

amrnuke

Golden Member
Apr 24, 2019
1,181
1,772
136

While this might be done in anticipation of Cooper Lake, this really sucks for AMD. It essentially doubles the licensing fee for all ROME CPUs having more than 32 cores (previously it costed about the same as the top-end CPU, 7K, now it's double that).

Considering that WMware is Dell owned I wouldn't be surprised if this is also Intel's "Financial Horsepower" at work.

Overall it puts the rumored top end Ice-Lake with 36 cores into an interesting position (maybe a unicorn CPU?)
Does this apply to 2P systems, that is, will dual Xeon Platinum systems with 56 cores also be hit?
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
Does this apply to 2P systems, that is, will dual Xeon Platinum systems with 56 cores also be hit?
That counted as two CPUs already. What's new is that per CPU licensing now has an upper limit of 32 cores per CPU. More cores than that now add one more "CPU" to be paid.
 

exquisitechar

Senior member
Apr 18, 2017
655
862
136
Personally, I wouldn’t be so quick to say this is Intel’s “financial horsepower” at work. It simply makes sense for VMware to do this, with the kind of socket level performance we are/will be seeing. They don’t need incentives from Intel, not selling less licenses than before is enough of a reason.

This isn’t good for AMD, but only in the short term. Milan will have better per-core performance than Intel’s offerings soon enough, and Intel will be releasing the 56 core Cooper and the 38 core Ice Lake (in less than stellar volumes, but still).
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
Personally, I wouldn’t be so quick to say this is Intel’s “financial horsepower” at work. It simply makes sense for VMware to do this, with the kind of socket level performance we are/will be seeing. They don’t need incentives from Intel, not selling less licenses than before is enough of a reason.

This isn’t good for AMD, but only in the short term. Milan will have better per-core performance than Intel’s offerings soon enough, and Intel will be releasing the 56 core Cooper and the 38 core Ice Lake (in less than stellar volumes, but still).
I don't think anybody disputes it makes sense for VMware to move away from their clear per CPU licensing model in face of the ever increasing amount of cores per CPU. I doubt anybody would have batted an eye if this had happened a year ago when the densest server chips were 28 and 32 cores respectively. The fact that it happened after Epyc 2 with 64 cores launched (with respective reaction by Intel), and VMware pretends to stick to its CPU licensing model, just forcing >32 cores to be counted as multiple CPUs, makes me think this was more of a knee jerk move (motivated by Intel money or not) than something planned in advance.
 

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,120
260
136
Whilst at first sight this may seem to be a nefarious move against AMD since they hold the core count advantage in servers over Intel but the more nuanced reality is that maintaining a highly complex codebase with a high degree of multi-threading such as VMware's software solutions is very hard ...

Making sure that your code is bug free in the face of multi-threading and highly performant in massively parallel systems is absolutely not trivial. VMware has to constantly refactor their codebase with ever growing core counts to get the most optimal performance out of them and this inevitably introduces regressions as well in their codebase so it's a never ending flurry of implementation and debugging work for software teams ...

I don't blame VMware for raising their licensing fees when this is the nature of their work. Writing high quality bug free code with good multi-threading and making it all maintainable is a near impossible task without a competently well prepared software team ...
 

DrMrLordX

Lifer
Apr 27, 2000
21,583
10,785
136
Core counts are going up. VMware wants to make more money with increased core counts. Imagine that.

Kinda makes me wonder why they didn't just go to per-core licensing instead of trying to do some kind of weird hybridized version of per-socket licensing. Pricing policies like theirs affects hardware acquisition policies. IT departments may wind up with sub-optimal equipment for no reason other than to dodge peculiar licensing fees.
 
  • Like
Reactions: moinmoin

itsmydamnation

Platinum Member
Feb 6, 2011
2,744
3,080
136
Kinda makes me wonder why they didn't just go to per-core licensing instead of trying to do some kind of weird hybridized version of per-socket licensing. Pricing policies like theirs affects hardware acquisition policies. IT departments may wind up with sub-optimal equipment for no reason other than to dodge peculiar licensing fees.
given your almost always I/O, memory , or memory bandwidth bound before CPU bound . doubling the lic price from 32 to 64 cores is harsh.
 

Topweasel

Diamond Member
Oct 19, 2000
5,436
1,654
136
Honestly Dells relationship with AMD does make it questionable. But honestly how often do you see a product become half as useful overnight like that. Cores were going up, Intel was just increasing margins making each successive core increase that much more expensive. The guys using VMware were not the same guys who could regularly fork out 10k for a single CPU. Intels prices meant most compute modules where in the 10-18c range for the most part and for a lot of companies that was significant growth. AMD came out with Epyc there was a lot of downsides on many server systems types and slow uptake. Boom now not only a high perf 32c but a 64c. Plus price cuts by Intel on the horizon to keep up. Now all of sudden those 32c and 64c CPU's even at the hefty price were looking like bargains. If anything its probably a sign in the server market that Vmware has been seeing an uptake in 32c+ Epyc installations and wants to make sure their margins don't take a worse hit. Honestly its still probably twice the compute capability they had been seeing per socket with their stuff at the 32c mark.
 

DooKey

Golden Member
Nov 9, 2005
1,811
458
136
Kinda makes me wonder why they didn't just go to per-core licensing instead of trying to do some kind of weird hybridized version of per-socket licensing. Pricing policies like theirs affects hardware acquisition policies. IT departments may wind up with sub-optimal equipment for no reason other than to dodge peculiar licensing fees.

This is nothing new for VMware. My IT department used them back in the 07 time frame when they were first pushing VDM. They are always causing uproar with their licensing and they definitely do cause (underfunded) IT departments to juggle hardware to dodge fees. I'm just saying no reason for tin-foil hats. As said by others, they aren't the only ones to pull crap like this.
 

Atari2600

Golden Member
Nov 22, 2016
1,409
1,655
136
While changing their approach makes sense, they way they've done it doesn't.

A simple switch at >32 cores is a bit too simplistic. They are going to have to change it again in a few years.

baselinePrice + pricePerCore*[max(nCores-X,0)]

So you get X cores as part of the baseline package, then pay an additional price per core for every extra on top of that. Simples and forward looking.