Information Technology Reference
In-Depth Information
Table 2.
Details of the instances and sequential processing times
scenario
edge size
instance id
step size
execution time (s)
1
0.05
210
2
0.10
177
1.5
3
0.20
217
4
0.50
1030
1
5
0.05
318
6
0.10
214
3.0
7
0.20
198
8
0.50
362
9
0.05
765
10
0.10
672
1.5
11
0.20
809
12
0.50
4068
2
13
0.05
1160
14
0.10
780
3.0
15
0.20
712
16
0.50
1500
17
0.05
2044
18
0.10
1715
1.5
19
0.20
2002
20
0.50
9796
3
21
0.05
2271
22
0.10
2002
3.0
23
0.20
1596
24
0.50
3798
Workload Management System that arranges several requests submitted by dif-
ferent users from an (application-oriented) back-end portal.
Groups of 4 and 6 tasks were created, and each group is executed as a sin-
gle job. This way a total of 4 and 6 jobs will be launched. The main reasons
for grouping tasks in different jobs are to apply the paradigm of domain de-
composition and also to avoid job failures due to a single task failure. OurGrid
allows setting the number of times a certain task will be rescheduled if it fails;
the default value is 3 and it was not changed for experimentation. The groups
comprise instances of different scenarios, selected using uniform distributions of
integer numbers in the range [1
,
24] for instance selection, and in the ranges [1
,
6]
and [1
,
4] for group selection (depending on the number of groups created).
OurGrid allocates resources according to the number of tasks included in a
job. If a job is composed of a large number of tasks, a site with insucient
resources could be ignored by the allocation algorithm. As we are dealing with
volunteer infrastructures, 4 and 6 tasks per job is a suitable number. It has to
be remarked that MCell is a computing demanding application and launching
many tasks in a single job could overload a single site.
The groups for 4 and 6 tasks are shown in Table 3, along with the execution
times for the parallel executions.
