HostDynamicWorkload.java uses vm.getMips() as a measure of how mich mips a vm can use at maximum, most prominently at the logging section of updateVmsProcessing(double currentTime).
However, vm.getMips() retruns the variable mips of the VM, which is documented as the mips per PE.
As such, the usage of vm.getMips() results in an incorrect value that does not represent the total mips capacity of the vm when the vm contains more than one PE.
I would suggest resolving this either by modifying the usage of vm.getMips() in HostDynamicWorkload.java to use vm.getMips() * vm.getNumberOfPes(), or add a method getTotalMips()to Vm.java.
The second would have my recomendation both to reduce confusion and to allow for having differencing mips per PE, something that is assumed not to be the case throughouth the framework but that is allowed in the creation of hosts, and maybe (should be) allowed in the cration ov Vm's.
HostDynamicWorkload.java uses vm.getMips() as a measure of how mich mips a vm can use at maximum, most prominently at the logging section of updateVmsProcessing(double currentTime). However, vm.getMips() retruns the variable mips of the VM, which is documented as the mips per PE. As such, the usage of vm.getMips() results in an incorrect value that does not represent the total mips capacity of the vm when the vm contains more than one PE. I would suggest resolving this either by modifying the usage of vm.getMips() in HostDynamicWorkload.java to use vm.getMips() * vm.getNumberOfPes(), or add a method getTotalMips()to Vm.java. The second would have my recomendation both to reduce confusion and to allow for having differencing mips per PE, something that is assumed not to be the case throughouth the framework but that is allowed in the creation of hosts, and maybe (should be) allowed in the cration ov Vm's.