The regular Cloudlet workflow is as follow:

• a Cloudlet is submitted to a VM and may wait in a queue until the VM has enough PEs to execute the Cloudlet (according to the CloudletScheduler policy).
• After a Cloudlet is scheduled using a CloudletSchedulerTimeShared, it will share the CPU with other concurrent Cloudlets. This way, multiple Cloudlets are executed preemptively (i.e., interchangeably).

However, the time a preempted Cloudlet is supposed to wait until be scheduled again is not computed.
The oversimplified CloudletSchedulerTimeShared doesn't actually perform preemption, but just reduces the amount of MIPS a Cloudlet can use when there are more Cloudlets than CPU cores.
This way, it enables all Cloudlets to run at the same time (which is not possible with current processor technologies). Check issues #27, #33 and #58 for more details.

When a CloudletSchedulerSpaceShared is used, when there are fewer CPU cores than Cloudlets, the next Cloudlet just starts executing when a previous one completely finishes its execution. This wait time is not computed either.

The Cloudlet.getWaitingTime() method returns the time the Cloudlet waited before starting executing, not the intermediate wait time after the Cloudlet started executing but was descheduled (preempted) for some reason. Before the implementation of Google Cluster Data readers (#149), a Cloudlet was never descheduled, but now this is a reality (as it is in real CPU scheduling).

It has to be assessed if the Cloudlet.getWaitingTime() will be used just to return the time the Cloudlet waited to be scheduled for the first time (as it is now) and a new method such as getTotalWaitingTime() will be introduced that adds up the intermediate waiting times. Possibly the first method should be renamed to getStartWaitingTime().