**4.3 w-GA algorithm**

The framework of the w-GA algorithm is similar to the n-GA algorithm. We focus on the crossover and mutation operations. Assume that we selected a parent such as in Figure 7(a), the following steps will be taken.

**Step 1:** Determine the critical path of each solution. The procedure to determine this is described in Algorithm 4. In each solution of our example, the sub-jobs joined with the critical 14 Will-be-set-by-IN-TECH

for this is located in we do the crossover and mutation operations. In particular, we do not carefully consider the critical path of the workflow. The runtime of the workflow depends mainly on the execution time of the critical path. With a defined solution and timetable, the

5: *prev*\_*subjob* is determined as the sub-job having latest finished data output transfer to

We start with the last sub-job determined. The next sub-job of the critical path will have the latest finish data transfer to the previously determined sub-job. The process continues until

The purpose of the crossover operation in the n-GA algorithm is creating new solutions in the hope that they are superior to the old one. In the crossover phase of the GA algorithm, when the sub-jobs of the critical path are not moved to other RMSs, the old critical path will have very low probability of being shortened. Thus, the overall makespan of the workflow has a

The primary purpose of the mutation operation is to maintain genetic diversity from one generation of a population of chromosomes to the next. In particular, it allows the algorithm to avoid local minima by preventing the population of chromosomes from becoming too similar to each other. When the sub-jobs of the critical path are not moved to other RMSs, the old critical path will have very low probability of being changed. Thus, the mutation operation

With the standard GA algorithm, it is always possible that the above situation happens and thus creates a long convergent process. We can see an example scenario in Figure 7. Assume that we select a parent as presented in Figure 7a. Using the procedure in Algorithm 4, we know the critical path of each solution which is marked by colour boxes. After the crossover and mutation operation as described in Figure 7b, 7c, the old critical path remains the same.

The framework of the w-GA algorithm is similar to the n-GA algorithm. We focus on the crossover and mutation operations. Assume that we selected a parent such as in Figure 7(a),

**Step 1:** Determine the critical path of each solution. The procedure to determine this is described in Algorithm 4. In each solution of our example, the sub-jobs joined with the critical

To overcome this elimination, we propose an algorithm called the w-GA algorithm.

critical path of a workflow is defined with the algorithm as described in Algorithm 4.

**Algorithm 4** Determining critical path algorithm

1: Let C is the set of sub-jobs in the critical path

the next sub-job becomes the first sub-job.

does not have as good effect as it should have.

low probability of improvement.

**4.3 w-GA algorithm**

the following steps will be taken.

2: Put last sub-job into C 3: *next*\_*subjob*=last sub-job

*next*\_*subjob* 6: Put *prev*\_*subjob* into C 7: *next*\_*sj* = *prev*\_*subjob* 8: **until** *prev*\_*sj*= first sub-job

4: **repeat**

path are marked with color. The sub-jobs joined with the critical path in solution 1 include 0, 2, 4, 7. The sub-jobs joined the critical path in solution 2 include 0, 3, 4, 7.

**Step 2:** Form the critical set. The critical set includes sub-jobs have appeared in both critical paths. With our example, the critical set includes sub-jobs 0, 2, 3, 4, 7.

**Step 3:** Create derived configurations. The derived configuration is extracted from the old one by getting only sub-jobs which have appeared in the critical set. After this step, the two new configurations of the example are presented in Figure 8.

Fig. 8. The new derived configurations

**Step 4:** Exchange assignment if there is improvement signal. A couple (*si* : *rj*|*si* ∈ *S*,*rj* ∈ *Ki*) is called an assignment. Assume that (*s*1*<sup>i</sup>* : *rj*) is an assignment of the derived configuration 1, and (*s*2*<sup>i</sup>* : *rk*) is an assignment of the derived configuration 2. If we change (*s*1*<sup>i</sup>* : *rj*) to (*s*1*<sup>i</sup>* : *rk*) and the finished time of the data transfer from the sub-job *s*1*<sup>i</sup>* to the next sub-job in the critical path is decreased, we say that the improvement signal appears. Without the improvement signal, the critical path cannot be shortened and the *makespan* cannot be improved. The algorithm for doing the exchange assignment is presented in Algorithm 5.

**Algorithm 5** Exchange assignment algorithm

```
1: imp_signal ← 0
2: for each sub-job si in the critical set do
3: (s1i : rj) change to (s1i : rk)
4: if has improving signal then
5: imp_signal ← 1
6: else
7: (s1i : rk) change to (s1i : rj)
8: end if
9: (s2i : rk) change to (s2i : rj)
10: if has improving signal then
11: imp_signal ← 1
12: else
13: (s1i : rj) change to (s1i : rk)
14: end if
15: end for
```
With each sub-job, we exchange the RMS between two configurations. If the exchange indicates an improvement signal, we keep the change. Otherwise, we return to the old assignment.

2 3 3 4 5 5 3 6

<sup>19</sup> w-TG: A Combined Algorithm to Optimize the Runtime

(1)

(2)

7 to 32.

have *k* = 0.

DangMinh/desc\_expe2.txt.

Fig. 11. Newly created configurations

of the Grid-Based Workflow Within an SLA Context

• Have different amounts of data transfer.

sub-job has the same CPU performance requirement.

2 2 3 2 2 3 4 6

• Have a different number of sub-jobs with the number of sub-jobs being in the range from

• Have different sub-job specifications. Without loss of generality, we assume that each

The runtime of each sub-job in each type of RMS is assigned by using Formula 4.

*rtj* <sup>=</sup> *rti*

*pki*+(*pkj*−*pki*)∗*k pki*

With *pki*, *pkj* is the performance of a CPU in RMS *ri*, *rj* respectively and *rti* is the estimated runtime of the sub-job with the resource configuration of RMS *ri*. *k* is the speed up control factor. Within the performance experiment, in each workflow, 60% of the number of sub-jobs have *k* = 0.5, 30% of the number of sub-jobs have *k* = 0.25, and 10% of the number of sub-jobs

The complexity of the workflow depends on the number of sub-job in the workflow. In the experiment, we stop at 32 sub-jobs for a workflow because it is much greater than the size of the recognized workflows. As far as we know, with our model of parallel task sub-job, most existing scientific workflows as described by Ludtke et al. Ludtke et al. (1999), Berriman et al. Berriman et al. (2003) and Lovas et al. Lovas et al. (2004) include just 10 to 20 sub-jobs.

As the difference in the static factors of an RMS such as OS, CPU speed and so on can be easily filtered by SQL query, we use 20 RMSs with the resource configuration equal to or even better than the requirement of sub-jobs. Those RMSs have already had some initial workload in their resource reservation and bandwidth reservation profiles. In the experiment, 30% of the number of RMS have CPU performance equals to the requirement, 60% of the number of RMS have CPU performance which is 100% more powerful than requirement, 10% of the number

We created 20 RMSs in the experiment because it closely parallels the real situation in Grid Computing. In theory, the number of sites joining a Grid can be very large. However, in reality, this number is not so great. The number of sites providing commercial service is even smaller. For example, the Distributed European Infrastructure for Supercomputing Applications (DEISA) has only 11 sites. More details about the description of resource configurations and workload configurations can be seen at the address: http://it.i-u.de/schools/altmann/

of RMS have CPU performance which is 200% more powerful than requirement.

(4)

If there are some changes in either of the two configurations, we move to step 5. If there is no change, we move to step 4. In our example, the possible changes could be presented in Figure 9.

Fig. 9. Derived configurations after exchanging

**Step 5:** Do crossover. When there is no change with step 4 we do a normal crossover with the two derived configurations. This procedure is presented in Figure 10.

Fig. 10. Normal crossover operations

**Step 6:** Do mutation. The mutation is done on the derived configuration with no successful change. With each selected configuration, the mutation point is chosen randomly. At the mutation point, *rj* of *si* is replaced by another RMS in the candidate RMS set. Like the normal GA algorithm, the probability to do mutation with a configuration is small. We choose a random selection because the main purpose of mutation is to maintain genetic diversity from one generation of a population of chromosomes to the next. If we also use mutation to improve the quality of the configuration, the operation mutation needs a lot of time. Our initial experiment shows that the algorithm cannot find a good solution within the allowable period.

**Step 7:** Reform the configuration. We return the derived configurations to the original configurations to have the new configurations. With our example, assume that step 4 is successful so we have two new derived configurations as in Figure 9. The new configurations are presented in Figure 11.
