This article describes a performance issue where ENS (Enhanced Networking Stack) worlds experience packet drops or latency due to high tail READY times during scheduling delays. This issue typically manifests as performance degradation for VMs running on the same host and portgroup when using ENS.
sched-stats histogram output shows a high max READY time (e.g., > 100ms).When an ENS world is placed on a busy PCPU, the vCPU migration algorithm should migrate the world to an idle or less-contended PCPU. A flaw in the current migration algorithm causes it to skip specific types of worlds, keeping them stuck on a busy PCPU and causing scheduling delays (high READY time).
The issue will be resolved in an upcoming release. Subscribe to this KB to receive update notifications.
The problem can be mitigated by setting PcpuMigrateIdleFeedback to 0.
esxcli system settings advanced set -o /Cpu/PcpuMigrateIdleFeedback -i 0
Check the ready time histogram of a ENS world using the following command:
sched-stats -w <ENS_WORLD_ID> -t run-state-histo
In the sample output below, the max READY time is 200 ms, which is high enough to cause noticeable latency or packet drops.
####### ####### EnsNetWorld-#-##bucket RUN READY WAIT COSTOP NEW ZOMBIE(< 3 us) 0 0 0 0 0 0(< 6 us) 0 0 0 0 0 0(< 11 us) 0 0 0 0 0 0(< 23 us) 0 0 0 0 0 0(< 45 us) 0 0 0 0 0 0(< 91 us) 0 0 0 0 0 0(< 181 us) 0 0 0 0 0 0(< 362 us) 0 0 0 0 0 0(< 725 us) 0 0 0 0 0 0(< 1450 us) 0 340 0 0 0 0(< 2899 us) 0 77 0 0 0 0(< 5799 us) 0 12 0 0 0 0(< 11598 us) 0 5 0 0 0 0(< 23195 us) 0 3 0 0 0 0(< 46391 us) 0 2 0 0 0 0(>= 46391 us) 0 31 0 0 0 0 min (us) 0 1000 0 0 0 0 max (us) 0 200022 0 0 0 0 mean (us) 0 12814 0 0 0 0 Total count: 0 470 0 0 0 0 Total time: 0.000 6.023 0.000 0.000 0.000 0.000
mean (us) 0 12814 0 0 0 0
Total count: 0 470 0 0 0 0
Total time: 0.000 6.023 0.000 0.000 0.000 0.000
Contact Broadcom Support for further assistance: Contact Broadcom Support.