Scheduling BoT's in cloudsim

From the LCG workload, i've taken 1000 tasks 'n created 10 BoT's with 100 tasks each... 

I've given submission times for the 10 BoT's as follows

Size of BoT	100		82000 MIPS
				Actual Makespan
BoT	Size Ratio	Submission Time	Ideal Makespan	{U,R}	{StoL,R}	{LtoS,R}
1	2	0.1	0.248	1.534	1.7808	1.5124
2	2	417.1	0.248	2.4052	1.60015	1.30361
3	3	952.1	0.2155	2.1625	1.63496	1.34319
4	1	1379.1	0.1576	0.76192	0.797307	0.652461
5	13	2020.1	0.5958	3.02415	2.156	1.3052
6	3	2991.1	0.1711	0.8095	0.8288	0.43392
7	5	3721.1	0.1676	0.7913	0.77075	0.3876
8	3	4034.1	0.0198	0.3212	0.31915	261
9	2	4295.1	0.052	0.4326	0.43328	0.3202
10	2	4899.1	0.2665	1.2816	1.0856	0.54276

These are the results I got... for 

{U,R} , Unordered, random

{StoL,R}, Small to Large, Random

{LtoS,R}, Large to Small, random

For some weird reason, makespan of Bot 8 for {LtoS,R} is 261 for no good reason whatsoever...

****** BoT 8

Submit Time : 4034.0

Number of tasks: 100

Size Ratio of BoT 8 = 3.0

***BOT Ordering 

LARGE TO SMALL

BOT 8

Submit Time: 4034.1

Max Execution Task: 700 & Time : 4295.1

Largest Task: 1631

Ideal Makespan : 0.019890243902439025

Actual Makespan : 261.00000000000045

I mean, the largest task itself is 1631 only.... i'm completely stumped :(

'n another thing... I've tried the same experiment with randomly allocated VM's and a constant mips of 1000... these are the observations I made from that

• Sorting LtoS, StoL is comparable
• the makespan is reduces as compared to {U,R}
• When size Ratio is more (i.e. no. of small task are more...) LtoS performs slightly better than StoL.
• When size Ratio is more, the unordered makespan is much more

Notes : The larger the size Ratio, the more number of smaller tasks there are....

These results were obtained from setting up the private cloud according to the experimental setup in 

Iqbal et al paper which i've slightly adapted and modified to fit into cloudsim spec.

The observations that I can make now are... (with the exception of BoT 8)

• Ordering tasks LtoS actually performs much better than StoL
• Ordering tasks StoL in some cases is produces larger makespan than {U,R}

But, isn't SJF the most optimal algorithm??? it's even proven to be optimal :(  so stumped rite now :( :(

I'll go check if the ordering is done correctly or not now...

So in my code the vm's are allocated in order from 1 to 10... so what is happening is all the largest tasks are getting assigned to VM #0 which has the largest processing capacity at 82,000 MIPS, whereas all the smaller jobs are getting allotted to VM's that are slowest... 26,000 Mips with 1 PE...

oh....... 

But why 261 for only BoT 8?

Something else i found was this... even though the BoT submission time was 4034 for BoT 8, in the cloudsim clock time,  cloudlets in BoT 8 are received only at 4295.1 which is the submit time of BoT 9... now how'd that happen?

4295.1: Broker: Cloudlet 769 received

4295.1: Broker: Cloudlet 779 received

4295.1: Broker: Cloudlet 789 received

4295.1: Broker: Cloudlet 799 received

4295.200230769231: Broker: Cloudlet 830 received

I can't figure out what was wrong... maybe there's something 'bout those tasks in that batch in the log itself... I took the next 100 tasks 'n it'z all good now...

So the results are kinda useless 'cos the mapping policy is not random... the largest/smallest task is getting allocated to the fastest VM... 

Now i'm gonna change this code...

  vmIndex = (vmIndex + 1) % getVmsCreatedList().size();

'n make it random...

 Random rn = new Random();

 int i = rn.nextInt(getVmsCreatedList().size());

vmIndex = i;

Hopefully, it should work now....

hmmmm....

nope... LtoS, R still produces smaller makespan as compared to StoL,R.... maybe the sooner the bigger tasks are in the system... because its in timesharing mode anywayz... maybe the overall makespan gets reduced...

Enough for today... i'll try with more number of BoT's 'n change the size of BoTs also...