Interesting Results: folding in a VM under ESXi 5

S

Syran

Gawd
Joined
Apr 26, 2007
Messages
683
I just upgraded my lab from ESXi 4.1 to ESX5.0; and one of the things I was interested in was the better foundation for threading that ESX5.0 has.

My lab box runs a dual Xeon X5570 @ 2.93Ghz with Hyperthreading Enabled, 48GB of Ram.

I normally run my folding VM capped at 12.5Ghz, as I do not want to cause issues with any test boxes running at any given time. It is also set for low shares in the Resource Allocation. 12GB of VRam was assigned to the machine.

I ran the work with 16cores (2 sockets, 8 cores each in the VM Settings, then changed it to 1 Socket, 8 Cores)
The WU is a P6993 (R0, C71, G275)
With 16 cores: Typical TPF: 11:55
With 8 cores: Typical TPF: 5:43

I wasn't really sure what to expect, but the results I did receive were quite interesting. I'm thinking of trying dropping to 6 and 4 cores, and seeing what kind of results I get. I may also max out the CPU one night when we don't have any testing going on and try again without any caps.
 
16 vcpu the new max? IIRC 8 "cores" is a max.

It would be interesting to mess around with this on my SR-2 so I can have another ESXi host to play with. :) I would also "HAVE TO" buy more ram...
 
For enterprise plus, it's 32vcpu/physical cpu. You set it up as Sockets & Cores, which is kinda nice.
For everything else, I think it's 8vcpu/physical cpu.
 
Syran said:
I ran the work with 16cores (2 sockets, 8 cores each in the VM Settings, then changed it to 1 Socket, 8 Cores)
The WU is a P6993 (R0, C71, G275)
With 16 cores: Typical TPF: 11:55
With 8 cores: Typical TPF: 5:43
Click to expand...

So it was slower with more cores? What did I miss?
 
nitrobass24 said:
So it was slower with more cores? What did I miss?
Click to expand...

Thats the basics of it, at least when I had it limited to 12.5ghz over the cores, it doubled the amount of TPF by doubling the amount of cores. I was attempting to figure out if you could use the HT to your advantage in a situation like this, since ESXi does not count HT cores towards total available CPU.
 
Just ran some new numbers. Same VM, new WU, did it with 8 and 4 core counts.

WU: P6965 (R0, C37, G421)
8 Cores TPF: 5:49
4 Cores TPF: 4:47

I'm thinking, that in the case of standard SMP running in a VM, that setting the cores at 2, and just running what you want may give you the best results. I'm going to test it on the next WU that comes along, trying to do 50% at each core count to give the best average.
 
Okay, I think I've figured it out, I dropped it down to 2 cores, and found it only using 6Ghz of CPU power. I think because it tries to spread things over cores; when you limit your CPU usage to the machine, you need to match that limit with the maximum number of cores that can go with it. Ie: instead of running 8 cores at 1.5Ghz, I'm better off with 4 running at 2.93ghz. Really doesn't seem like HT in a VM environment works well.
 
I moved my SR-2 over to ESXi so I can use it for testing another VM I need for school. I lost about 10K on a 6903, no CPU usage limitations, no other VMs running during this WU and I converted my physical install. vShpere reports the VM using 53.8GHz out of 43.2GHz total for the host...
 
I run ESX 5.0 and experience the same results when tinkering with socket and core counts. The way I have it set right now is 2 sockets and 4 cores, so 8 threads. This maxes out the host's CPU according to the performance chart, yet I don't get a lot of PPD. The ESX host has 2 sockets with 4 HT cores. In the vSphere client, it says the ESX host has 16 logical processors. It realizes the HT. But giving my VM 16 threads turns out to only use 50% of the host's CPU. Seems like VMWare is killing the PPD potential the ESX host hardware has.
 
The observed effect has actually always been true with VMware. The experts in [H] Virtualized Computing can explain it better but the general guide is to not use more than one core per VM unless you have some specific reasons for doing so and the app will actually take advantage of it.

You could argue that FAH is created to take advantage of it, except it's not optimized for VMware then or some such. Still worth to clearly formulate the question and post it to the virtualization forum.
 
You must log in or register to reply here.
Back
Top