updateVMs processing

This function is pretty tricky....

I'm using this to find expected completion time of a a particular cloudlet on a machine.

If there is not cloudlet assigned to it... it returns 0...

else it returns .2

huh...

everything traces back to cloudletScheduler... which seems to be an interface with no implementation.

Have to find out what class implements this....

oh... this is an abstract class... so if it is timeshared, then we have to look into that

public double updateVmProcessing(double currentTime,

                        List<Double> mipsShare)

Updates the processing of cloudlets running on this VM.

Parameters:

currentTime - current simulation time

mipsShare - array with MIPS share of each Pe available to the scheduler

Returns:

time predicted completion time of the earliest finishing cloudlet, or 0 if there is no next events

I think I found out why it returns .2...

Why would they code it like that :(

Now I have to write my own implementation for this and override it...

In https://github.com/marcbux/dynamiccloudsim/blob/master/src/org/cloudbus/cloudsim/CloudletSchedulerTimeShared.java

// estimate finish time of cloudlets
 for (ResCloudlet rcl : getCloudletExecList()) {
   double estimatedFinishTime = currentTime
     + (rcl.getRemainingCloudletLength() / (getCapacity(mipsShare) * rcl.getNumberOfPes()));
   if (estimatedFinishTime - currentTime < 0.1) {
    estimatedFinishTime = currentTime + 0.1;
   }


   if (estimatedFinishTime < nextEvent) {
    nextEvent = estimatedFinishTime;
   }

Dilemma

I'm a little confused here...
I've done some simulation work, enough to write a paper.
I've also got a long way to go to complete my codes....
Should I continue coding (which now involves learning JESS... which is new to me... and it will probably take some time before I become proficient in it...)
Or should I write a good paper... which also seems to be a long process...

I tried to do both 'n what happens at the end of the day is that... nothing gets done...

BoTs

So I'm having a hard time justifying why I'm concentrating on scheduling BoTs.

finally found the Minh paper... (Why didn't I come across this earlier :( :(
Now I tried to look up a tool developed by Minh which i thought would make my life easier.  It supposedly would cough up the BoTs if I fed  any workload trace.
http://www.liacs.nl/home/minhtn/models

'n bad luck... I get "Pagina niet gevonden"...

So now I guess I have to write my own code to detect BoTs.... 'n all I gotta do is follow everything from the Minh paper on "Realistic Integrated Model on Parallel Worklaods"

Some Notes from the above mentioned paper...

What are BoTs?

In any parallel system workload, W,
(This parallel concept 'bout BoT is what's utterly confusing and even though I think I've understood it... it's confounding to the person I'm explaining it to...)
(So I'm going to interpret parallel system workload as workload given to a set of machines which can execute various tasks simultaneously...)

BoT contain tasks arriving at different times (one after the other), within a particular time frame
(They have observed this to be 100 sec).  These jobs have the following characteristics :

•  They originate from the same user.
• They have the same group name
• They have the same queue name
• They have the same job name
• They have the same user estimated runtime (approximately),
• They have the same number of requested processors.

Around 70% of jobs are part of BoT's 

submission duration of a BoT is the difference between maximum and minimum duration of BoT submission.  All are less than 100%.

Now there's an algo on how to generate synthetic BoT's... but I hopefully don't have to resort to that if I could just use the above "simple" observations 'n detect BoT's from the LCG trace.

Something tells me i'm not gonna get outta this without knowing digging into the depths of the Zipf and Gaussian Distribution.

cloudlet execution

So here's the dilemma.
I don't know whether I overlooked this the last time around or I'm just noticing this.
I have around 10 VM's in my simulation...
The default scheduling of the cloudlets were modified.
When I print my log, all my cloudlets show VM #9.
But the log attached with my send() function in datacenter class show the cloudlet is sent to VM#0.
That makes sense because I used minimum execution time policy and VM#0 in my configuration has the largest MIPS....
How'd that happen??

Finally figured it out...
This is what happens when you teach for a semester 'n then reopen your code after 5 months...
No matter how much documentation or readme's ya write... somehow all of it get misplaced, you don't know where to look, what you did...
It's a big mess... 'n just when ya get the hang of it again.... classes start...