Hypothetical situation:
Host has 2.5GHz cores, and plenty of them. No over-provisioning of cores.
It has plenty of memory, 128GB, no over-provisioning there either.
I have two VMs:
VM-1 is:
2 vCPU with 5000MHz reservation and 5000MHz limit
8GB vRAM with 8GB reservation and 8GB limit
Latency sensitivity flag is set.
VM-2 is:
As above but doesn't have the 5000MHz vCPU limit.
Would it be expected that the two VMs perform the same, or would one perform worse than the other.
Our observation is that VMs supposed to process a high frequent stream if network packets will drop packets if the vCPU limit is set, but won't if it isn't.
The presumption is that although the figures would suggest there should be no performance difference, the processing of the vCPU limit causes the VM to momentarily splutter and miss a packet.
This articles explains the behavior
I have seen that, but in the situation described both VMs are effectively limited to the same extent.
Both are 2 vCPU, and the host only has 2.5GHz pCPU cores.
So in both cases even without limits the VM would be constrained to 5000MHz of host CPU resource.
So the linked KB is interesting, and describes what happens in a broad sense, but doesn't give enough information to determine if there is a performance overhead with having CPU limits that applies even when it has nothing to actually do.
can you check if there is any balooning on the VM on ESXTOP and validate the rdy% as well?
There shouldn't be any, all VM memory is reserved and limited too.
As already mentioned by msripada, look at the %RDY value in esxtop. Once for the VM with CPU limit and once for the VM without limit.
If it has an impact and the VM is actually limited, you can see this at the %RDY value because it would incease.
Yup, I understand how to detect if it is having an impact and where to see the metrics on this.
The question I suppose is whether or not I should be seeing any degradation in performance?
The only thing I can think of is that the mechanisms for CPU resource sharing on a host are dormant unless: