vSphere CPU Capacity calculation

[tman24]

I'm just putting together a new vSphere 6.7 cluster (latest build). This consists of 4 x ESXi hosts, each with 2 x 16C/32T CPU's @2.1Ghz. All the CPU's are detected ok, as well as hyperthreading, which is enabled and working.

What I noticed is is that the Total CPU Capacity for each host is being calculated as ~67Ghz, when based on what I think it should be, which is 64 x 2.1Ghz, which should be ~134Ghz. It would seem that the capacity is being calculated on 32 x 2.1Ghz, ie, without HT. is this correct, or am I reading it wrong? When I Iogon to each ESXi host, it also shows 67Ghz as to total CPU capacity.

[e_espinel]

Hello.
Please check the following

BIOS Settings

The default hardware BIOS settings on servers might not always be the best choice for optimal performance.

1. Make sure you are running the latest version of the BIOS available for your system.
2. Make sure the BIOS is set to enable all populated processor sockets and to enable all cores in each socket

3. Enable “Turbo Boost” in the BIOS if your processors support it.

1. Make sure hyper-threading is enabled in the BIOS for processors that support it.
2. Some NUMA-capable systems provide an option in the BIOS to disable NUMA by enabling node interleaving. In most cases you will get the best performance by disabling node interleaving (in other words, leaving NUMA enabled).
3. Make sure any hardware-assisted virtualization features (VT-x, AMD-V, EPT, RVI, and so on) are enabled in the BIOS

[Valentin Bondzio]

That is correct, capacity is defined as nominal frequency * number of cores. Reservable capacity is everything left for VMs that system / vim / iofilter pools aren't reserving. HyperThreading and Turbo Boost, even the Max All Core Frequency (MACF), are basically "Bonus" capacity because it can't be guaranteed by definition. Give the steady improvement of SMT performannce and increasing percentage of Turbo Boost MACF, we might look into how we can show that (non-reservable) capacity a bit better in the future.

I literally just did a VMUG session on that particular topic, we'll also cover it at this year's Performance Best Practices session at VMworld so tune in if this interests you.