If you see high CPU usage in the virtual (VMware, KVM, Openstack etc.) NE-ONE or INE Network Emulators then this is perfectly normal.

The design in both of our Network Emulator families is that one (CPU) core talks to the GUI (accepts your commands, runs the Web Interface etc) and all the others spin on the CPU waiting for packets, and so they will use 100% CPU whether they are busy or idle - by design. [Technically: This design is because we use Poll Mode Drivers, because having processors interrupted (as would happen in an interrupt driver design) by packets arriving frequently is detrimental to the performance of an emulator so we spin instead.]

The default virtual NE-ONE has 2 cores allocated, and the default virtual INE has 4 cores allocated. As described above all but one of the cores will spin at 100% and the other will not, this is normal. In VMware this may trigger alarms, as this is not the usual pattern of CPU usage of a guest. So our default NE-ONE typically uses >50% CPU all the time and our default INE typically uses >75% CPU all the time. We say typically because if the GUI is busy it will be higher, but if the Host (VMware ESXi server or other virtual server) is too strapped for resources to allocate our Emulator VM all the CPU it likes it will be lower. You will therefore probably want to turn alarms off for our Emulator VMs as due to their high CPU usage.

We have published a tuning section for our Emulators in their installation guides which aims to ensure that our (Emulator) VM gets all the CPU (and memory) for its processors as “locked in” as possible. However, in a situation where the Host itself is strapped for resources this may not be a good idea as then the other guests will receive less CPU than they might want/need. That’s fundamentally always the issue with virtual systems you have to balance out the resources amongst the “guests” and our emulators are one of the guests; due to the “real time” nature of emulations they are demanding guests too.