Using Performance Prediction to Allocate Grid ... - Semantic Scholar

GriPhyN Technical Report 2004-25

Using Performance Prediction to Allocate Grid Resources Seung-Hye Jang, Xingfu Wu, Valerie Taylor Department of Computer Science Texas A&M University, College Station, TX 77843 {jangs, wuxf, taylor}@ cs.tamu.edu Gaurang Mehta, Karan Vahi, Ewa Deelman USC Information Sciences Institute 4676 Admiralty Way, Marina Del Rey, CA 90292 {gmehta, vahi, deelman}@isi.edu Abstract Large-scale applications often require computational grids to obtain the needed compute power for execution. Generally, users are given access to a collection of resources that can be used for execution. The collection of resources can be dynamic, and the users must decide which collection of heterogeneous and distributed resources to use. However, many users often do not have knowledge of all of the resource performance characteristics on which to make informed decisions and therefore need automated tools to perform the mapping of jobs to the available resources. In this paper, we present a resource planner system that uses performance prediction, based upon historical data, to identify the appropriate resources. This system is used with a gravitational-wave physics experiment, LIGO, for which the initial results indicate an average of 24% reduction in execution time using the performance prediction versus a random selection of resources.

1. Introduction Large-scale applications often require computational grids to obtain the needed compute power for execution. Such applications include cosmology, ocean modeling, and gravitational-wave physics. Generally, users are given access to a collection of resources that can be used for execution. The user may be given resources for which he/she is not familiar and even though he/she may have an idea about the application performance, the user may not be able to determine how the application will perform in the new environment. Thus the user may have difficulty selecting appropriate resources for one’s work. Such decisions can be supported by fully automated tools focused on resource planning. Resource planning can utilize different criteria, such as current resource availability or best performance, when making the resource selection. The goal is to reduce the turnaround time for results, which includes the wait time for resources in addition to the execution time of the application. In this paper we present a resource planner that uses performance prediction, based upon historical data, to identify the appropriate resources. The goal of the planner is to select resources so that the execution time of the application is minimized. It is well known that resource selection based on the processor speed or memory does not result in the best selection to reduce execution time [29]. Performance is determined by interactions between the dataflow and computations in the application with the system architecture.

1

GriPhyN Technical Report 2004-25 Significant work has been done in the area of performance prediction for parallel applications [20, 23]. This work indicates that historical data are needed for good performance prediction. Our system also uses historical performance data; this data is archived in a database, along with the information about the system used for the execution and detailed information about the application. The additional information is needed to put the performance data in context for use with prediction. Our resource planner system consists of the Pegasus (Planning for Execution in Grids) [2, 24] combined with the Prophesy performance modeling infrastructure [19]. The historical data are obtained from multiple databases including the Prophesy database and the Provenance Tracking Catalog (PTC) [15]. The application used to illustrate the use of the system is a pulsar search application used by the Laser Interferometer Gravitational-wave Observatory (LIGO) [11] and the LIGO Scientific Collaboration [12]. Our initial results indicate an average 24% reduction in execution time using the performance prediction versus a random selection of resources. The paper is organized as follows. Section 2 gives an overview of the system. Section 3 describes the LIGO pulsar search application. Section 4 presents the experimental results using LIGO on Grid2003 sites [6], a grid testbed developed at part of the iVDGL [8], GriPhyN [5] and PPDG [14] projects. Section 5 describes the related work, and section 6 summaries the work and describes future directions.

2. System Overview Our resource planner consists of the Pegasus workflow management and mapping system combined with the Prophesy performance modeling infrastructure. Pegasus is used to map an abstract workflow description onto the available grid resources. The abstract workflow indicates the logical transformations that need to be performed, their order and the logical data file that they consume and produce. The abstract workflow does not include information about where to execute the transformations nor where the data is located. Pegasus uses various grid services to find the available resources, the needed data and the executables that correspond to the transformations. Pegasus also reduces the abstract workflow if the intermediate products are found to already exist somewhere in the grid environment. One of the ways that Pegasus maps a workflow onto the available resources is through random allocation. In this work we interfaced Pegasus and Prophesy to enable Pegasus to use the Prophesy prediction mechanisms to make more informed resources choices. Prophesy is an infrastructure for performance analysis and modeling of parallel and distributed applications. Prophesy includes three components: automatic instrumentation of applications, databases for archival of information, and automatic development of performance models using different techniques. The model builder is used to formulate predictions based upon performance data. It is assumed that historical performance data are collected using different tools and stored in different databases for more accurate prediction results. Currently, Prophesy includes three methods for developing analytical models for predictions: (1) curve fitting, (2) parameterized model of the application code, (3) coupling of the kernel models. In this paper, we utilize the curve fitting method for developing the predictions. Future work will explore the other methods. Figure 1 shows the general system workflow. The user submits an application to the resource management tool to be run in a Grid environment. The resource management tool represents applications and their data products and stores them in an abstract forms (abstract workflows)

2

GriPhyN Technical Report 2004-25 using the Chimera Virtual Data Language (VDL) [15]. Subsequently, Pegasus generates the concrete workflows (workflows that identify specific resources) by mapping the transformations in the workflow to appropriate Grid resources and selecting appropriate data. Before mapping workflows to Grid resources, Pegasus queries Prophesy to identify which available resources to select. The Prophesy server sends the performance prediction information back to the Pegasus for effective resource selection. Lastly, the workflows mapped to the appropriate resources are submitted to DAGMan [25] for execution in the Grid environment. .

!

Figure 1. System workflow.

2.1 System Description Figure 2 shows detailed integrated system view between the resource management and prediction tools. The system includes components of the Virtual Data Toolkit (VDT) [18] and the prediction tool, Prophesy. VDT is a collection of Grid middleware including Globus [17], Condor-G [16], Chimera VDS [7], and various utilities. The Chimera VDS provides methods for representing data products and producing them using Virtual Data Language (VDL). Data product definitions are stored in the form of transformations (descriptions of application programs) and derivations (recipes to produce the data files) in the Virtual Data Catalog (VDC). Using VDC definitions, the VDS generates an abstract Directed Acyclic Graph (aDAG) using logical file names. Then aDAG is translated into a concrete workflow using Pegasus. Before the Pegasus constructs the concrete workflow, it has to make several decisions such as where to run jobs and whether to transfer existing data products from remote sites or regenerate them at the execution site. To make more effective decisions, it interacts with the predictor for the desired prediction information. Upon receiving a prediction request from the Pegasus, the Prophesy queries all available databases and builds a performance model using the Prophesy model builder. Subsequently, it sends the prediction information based on the performance model back to the Pegasus. The system is designed in a way that utilizes all available databases with performance information. The current prediction framework uses two different performance databases, the Provenance Tracking Catalog (PTC) of VDS at Argonne National Laboratory and the Prophesy database at Texas A&M University. The performance data associated with every invocation of a transformation are gathered and stored in PTC including information such as resource

3

GriPhyN Technical Report 2004-25 consumption and exit code. We also use the Prophesy Automatic Instrumentation and Data Entry tool (PAIDE) [22] to instrument the application to obtain detailed application-level performance data. The application-level performance data are archived in the Prophesy database.

#

$

%

"

# &

"

#

"

"

Figure 2. VDT and Prophesy Interface.

2.2 Interface Language Our initial prediction interface includes the following query type, prophesy_site_selector. It is used to predict the best site to execute an application. It requires that Pegasus sends the information such as the application name, the semantic parameter names and their values, and the list of available resources. Once the query is received by the Prophesy server, Prophesy returns the ranking of the given resources. If the site is unknown, that is, if the historical data of the application executed at the specific site is not available, it marks the site and ranks the site as the lowest. The interface function prophesy_site_selector is defined as follows: Function Name:

prophesy_site_selector

Parameters: • application_name (value type: char *) : Name of the application • list_of_candidate _sites (value type: char * ) : List of candidate sites • semantic input names and their values (i.e. For one of our application module, ComputeFStatistics, input names are Input_SFT_Numbers, AlphaImax, and FreqImax. Value types are char * for input name and integers for their values) Return value: • Rankings of candidate sites (value type: char * )

4

GriPhyN Technical Report 2004-25 •

Probabilities of their predicted execution time (value type: double)

The Prophesy uses the predicted execution times to rank each candidate site. The less the execution time is, the higher the site is ranked. The probabilities are also based on the predicted execution times. Assume that the list of candidate sites are S1, S2, …, Si, …, Sn, and their predicted execution times are T1, T2, …, Ti, …, Tn respectively. We use the following equation to

calculate the selection probability of the site Si :

1 Ti n

1 j =1 T j

=

1 n

1 Ti j =1 T j

.

For a given application, the less the execution time is, the bigger the site selection probability. Pegasus uses the site rankings and selection probabilities to decide how to distribute jobs among available resources in Grids.

3. Application The LIGO Scientific Collaboration is a forum to support the LIGO and GEO research communities. The Laser Interferometer Gravitational Wave Observatory (LIGO) [11] is a distributed network of interferometers located in Hanford, WA and Livingston , LA. Hanford has two interferometers (4km and 2km arms), and Livingston observatory has one 4km interferometer. The German-English Observatory (GEO) 600 [4] maintains an interferometer with arms of 600 meters in length located in Northern Germany near Hannover. It has been built by BritishGerman collaborators to detect gravitational waves since 1997, and the first test run was in 2002. Collaborators from LIGO and GEO teams participated in a specific LIGO application, the pulsar search. The pulsar search is a process of finding celestial objects that may emit gravitational waves. The search requires intensive computations and huge amount of data. The steps to perform the pulsar search are as follows. First, the gravitational-wave strain channel is identified from the raw data collected at the LIGO interferometers according to some time frame. Next, the time series data are transposed to form a series of Fourier Transforms over a long time frame. The desired frequencies are then extracted from Fourier Transform files, and finally an image is constructed to perform the pulsar search [1]. Figure 3 shows the workflow of LIGO GEO pulsar search (SFTs refer to Short Fourier Transforms). ) '(

'(

Figure 3. LIGO GEO Pulsar Search.

5

GriPhyN Technical Report 2004-25

4.1 Execution Environment The PAIDE-instrumented LIGO/GEO application was executed on different Grid2003 sites. The Grid2003 [8] is a collaborative project between iVDGL [8], GriPhyN [5], Particle Physics Data Grid (PPDG) [14] and US-based physics experiments led by ATLAS and CMS. It provides 27 different Linux clustered sites with approximately 2700 total CPUs. Table 1 shows the site specifications of the selected Grid2003 sites. The specifications include CPUS: number of CPUs; CPU Type; Cache Size: level 1 cache size; Mem: total memory sizes; Batch: local batch system; Loc: site location; and VO: Virtual Organization [28], which is an abstract entity grouping Users, Institutions and Resources (if any) in a same administrative domain. Site Name

CPUS

CPU Type

UTA_dpcc CalTech-PG IU_ATLAS_Tier2 ANL_Jazz UBuffalo-CCR UWMilwaukee PDSF

162 66 64 350 80 296 400

2X2.4-2.66 GHz Intel Xeon 3X3.20GHz Intel Xeon 2X2.4 GHz Intel Pentium 4 Xeon 2.4 GHz Intel Pentium 5 XEON 1.60GHz Intel Xeon 1GHz Pentium III (Coppermine) 1-2X650-1.8 GHz Pentium III (Coppermine)

Cache Size (KB) 512 512 512 512 256 256 256

Mem (GB) 2 2 2.5 1-2 3.7 0.5 2

Batch

Loc

VO

pbs condor pbs pbs pbs condor lsf

TX CA IN IL NY WI CA

USAtlas USCMS USAtlas iVDGL iVDGL LIGO USAtlas

Table 1. Grid2003 Sites.

4.2 Training Set We identified three primary input parameters that affect the execution time of the LIGO/GEO application. These parameters include the number of input Short Fourier Transforms (SFTs), AlphaImax, and FreqImax. The input parameter AlphaImax is the number of Alpha values for which to calculate the output. Similarly, the input parameter FreqImax is the number of frequency values for which to calculate the output. AlphaImax and FreqImax determine the search region of the pulsar search. Table 2 provides the history or training set that was used to develop the analytical performance model used for prediction. Notice that with varying parameter values, the best site for the execution changes (the best site for the execution is highlighted). For example, for input SFTs: 100, AlphaImax: 51, and FreqImax: 10001, PDSF gives the best performance. For another input set whereby input SFTs: 500, AlphaImax: 51, and FreqImax: 10001, UBuffalo-CCR results in the best performance. Hence, prediction is needed to identify the best site. The analytical performance model was generated using a multivariate least squares fit to the data. As the application is executed on additional sites, the performance data is archived and used to refine the performance model used for prediction.

4.3 Benchmark Description As mentioned in Section 1, it is well known that historical data is needed for performance prediction with resource planning. In this section we provide an experimental data to

6

GriPhyN Technical Report 2004-25 demonstrate the advantages of using prediction for resource selection in contrast to random site selection or static site selection based upon a given benchmark. In terms of random selection, we used the rand( ) function with the seed value equal to 10000 to identify a site to be used for execution. In terms of the static selection, we used the well-known Linpack benchmark [13] as described below.

!

"

#

$%! % &

$

''

$ !

#

%

**

+

***

,,-.

/-+0

,-./01

.**

+

***

1. - ,

1/.-1.

,2/.1

11*- ,

1/ -20

+0-+

1**

+

***

/2 -/

/2 -1

13 /31

/ 2-*0

/22-,.

.02- .

/**

+

***

,, -,+

,+ -+

3, /31

,/0- ,

,++-*

+**

+

***

./-,/

.+- +

++-/0

02./.0

/ -00

,**

+

***

**,-+/

,22&/.0

0*-11

.*- ,

* 2- 1

0**

+

***

,,40/ .

/2+-*.

. *-*0

..,-..

**

+

***

/+1-+0

/,.-.,

11-1,

+ 1- /

,1 1/.-

2**

+

***

,31 /-0

,01-1,

.*1.-,.

***

+

***

,01&/22

21/-.

., +-/1

21.-/2

/+-2+

**

+

***

0/+-

++,-,1

+00-0,

-2./30

+ *- ,

**

.+

***

./,- .

21,-*

.../&4

/,-.*

,+-/,

. 10-*2

**

1+

***

0/.- 1

1 ,- .

.* -,2

-*/

,,.3/&3

.22.-1/

**

/+

***

..02-2/

,++-+,

/**-./

+ +-.2

, 4,/1-

1 1 -1*

**

++

***

1.0/-*

.* .-/1

,.23/1.

+ -++

2.-11

**

,+

***

1 +*-1+

.120-0+

&2,&/22

.

..*,-//

++1 -11

**

0+

***

// 2-*2

.0,+-,,

& &,/2&

.+.1-+

.+,/- +

,1 2-..

**

+

***

/20/-2.

1

-0.

&3&4/4,

. + -01

.2 ,-//

0.,*-.+

**

2+

***

+++2-/+

1/

-.+

&41,/0

1 2/-+2

1..0-*,

+*-+*

**

+

.***

&0-/34

1+0-0*

1 1- *

1/ -*

1*+-

**

+

1***

1&3/-2

+1 - 0

/,1-/,

+*.-21

/01-1,

.00-2/

**

+

/***

-3-/,4

0*.- 1

, /-1.

,0 -0.

,,,-/

0*1-/,

**

+

+***

.30/2.

212-.

0 +-,,

**

+

,***

21/-+.

.*-/

**

+

0***

, - *

**

+

***

.+2- *

**

+

2***

, 41/12

**

+

****

++*-..

./2-2

.22-2,

0/-

$() * +

0 2-*

0-00

,+.-1*

/1/-/,

0

-.0

.. ,-*1 1*11-, 1.*/-.2 12* / 01-/ /2 0- 0 11/-

/,2 -*

+,-10

,0-2

00,- 0

2/*-.

*.0-,,

4,4/03

.+2/-/+

*2/-00

.* - 2

,2.,/.1

1*1,-21

,&&2/3

1/+0-/

/, -/1

.+1-+*

10/-.2

,+/-/

/.2-11

+1 -1*

+,.-+2

0*1- 1

.*-+/

0*-+0

/

- ,

,-&-/33

.

.-/.

1 0+-* /1*2-+,

Table 2. Training Set and Related Performance Data.

Figure 4 provides the execution rates of the Linpack benchmark on the Grid2003 sites. The Linpack benchmark is a set of well known numerically intensive operations used to measure floating point performance. The problem set is 1000 by 1000, solving Ax=B. The Linpack performance indicates that UTA_dpcc site gives the best performance; this site is used as the static site in the comparison below.

7

GriPhyN Technical Report 2004-25

UTA_dpcc

Caltech-PG

IU_Atlas_Tier2 1

Ubuffalo-CCR

UWMilwaukee

PDSF

0.00E+00

5.00E+01

1.00E+02

1.50E+02

2.00E+02

2.50E+02

Mflops/Sec

Figure 4 : Linpack performance results on Grid2003 sites (Each value is the average of 100 runs).

4.4 Experimental Results Table 3 gives the experimental comparison of site selection using Prophesy’s prediction mechanisms, a random site selection algorithm, and static selection of UTA_dpcc using Linpack results for 14 different parameter values. The site selections are given for the prediction and random selection methods, as well as the execution time for the selected sites which are given in terms of seconds. Further, we provide the relative error of the random site selection and the UTA_dpcc selection (based upon Linpack) as compared to that of the prediction method. Negative error values indicate better site selection than that resulting from the performance prediction; and positive error values indicate that the performance prediction had the better selection corresponding to a smaller execution time. The results indicate that the prediction method provided the best site selection versus random and static in all but four cases; for these four cases the best site was off by 10% or less. Further, for the random selection case, the relative error was as large as 170%. The prediction method identified sites that were on average 26% better (or smaller) in execution time than the random site selection. In comparison to the static selection, the relative error was as large as 25% with an average relative error of 9.7% overall. Hence, it is best to use prediction. It is noted that the overhead for obtaining the prediction was negligible, and occurs prior to execution of the application.

8

GriPhyN Technical Report 2004-25

$ !% 56 ! ** ** ** ** ** .** .** 1** /** /** +** ,** 0** .**

2+ *+ + .+ 1+ + ++ 1+ + + + + 0+ +

" 1*** *** *** *** *** .*** *** +*** .*** 1*** .*** .*** .*** ***

'( '( '( '( '( # '( & # # # # & &

0+*-,/ 1.0*-12 1,10-2 121 -10 /.21+++- + 11+0- / +*1 - , 1+-1* ,2 -.+ //+-+0 /- . 10*10-11 ..+,-*.

!

'( # &4 # # # # )& )& &% 55 )& & &4 '(

0+*-,/ .22 -+, 2 +1-/2 1+,.-0, 1 / -01 +++- + 1*1*-+2 010*-, 1+.-.1 221-./ /+.-.1 .*1+-20 21,2.-*+ .,,1-*+

8 *-*3 $ -+3 0*-23 $2-/3 $ *-+3 *-*3 $2-03 +-+3 2- 3 0-23 *-+3 - 3 +1-*3 -*3

6

2,,+- * 1+ 0-10 1 2 -11 /.1+- 0 / 10-,1 ,0,-0 /. 2-/. +*1 - , 1*0-+/ 2,,-,1 /0.-20 .*1+-20 10*10-11 ..+,-*.

&3/29

+7 86 *-+3 2-03 0-*3 0-03 .-03 . - 3 .+-03 *-*3 +-.3 ,-13 -23 - 3 *-*3 *-*3 4/.9

Table 3: Runs with prediction, random site selection, and using Linpack results.

5. Related work Sun and Wu [21] have introduced an application-level task scheduling system using a general prediction model [10] for non-dedicated network computing. The focus is on the dynamic, nondedicated systems, not on the individual applications, which is our focus. Further, we include performance data, such as variance, that takes into account the dynamic aspect of non-dedicated systems. Jang Uk In et. al. are working on SPHINX, a Scheduling in Parallel for a Heterogeneous Independent NetworkX [9]. SPHINX has a prediction engine that provides a prediction for the planner based on a simple average and variance calculation using its prediction database; this work is in its initial stages. In contrast, we used a multivariate least squares fit to provide the prediction based upon the input values. Performance Analysis and Characterization Environment (PACE) [26] provides quantitative prediction data regarding the performance of complex applications running on a local grid resource. It consists of application tools, resource tools, and evaluation engines. The application tools generate an application model which describes requirements for application run. The resource tools provide several resource monitors (e.g., CPU monitor) and their measurements are described in a resource model. The evaluation engines make a prediction based on simulation performed with both application and resource model. In contrast, Prophesy develops an analytical performance model that can be used for the prediction, thereby significantly reducing the overhead for complex applications.

6. Summary and Future work Large-scale applications often require computational grids to obtain the needed compute power for execution. Although a collection of resources that can be used for execution are known, users 9

GriPhyN Technical Report 2004-25 may have difficulty selecting appropriate resources for their goals because the users may be unable to determine how the application will behave in the new environment. Addressing this issue, we have presented a resource planner that uses performance prediction, based on historical data, to identify the appropriate resources. Our initial results indicate an overall performance gain, an average 24% reduction in execution time using the performance prediction versus a random selection of resources. Future work is focused on using the performance prediction to make other decisions as well as using different methods, such as parameterized model or the coupling method, to generate the predictions. The combined resource planner and predictor can be used in other decision-making processes such as whether to transfer an existing data product from a remote site or regenerate it at the execution site. Reusing the existing data product is not always the best choice in terms of the total execution time. Also, the resource planner can help allocating the necessary number of compute nodes before the actual execution. For instance, one can reserve the necessary number of nodes ahead so that the job executions are completed on time.

References [1] Ewa Deelman, James Blythe, Yolanda Gil, Carl Kesselman, Gaurang Mehta and Karan Vahi, From Metadata to Execution on the Grid, Pegasus and the Pulsar Search, GriPhyN Technical Report 2003-15, 2003. [2] Ewa Deelman, James Blythe, Yolanda Gil, Carl Kesselman, Gaurang Mehta, Karan Vahi, Kent Blackburn, Albert Lazzarini, Adam Arbree, Richard Cavanaugh and Scott Koranda, Mapping Abstract Complex Workflows onto Grid Environments, Journal of Grid Computing, vol.1, no. 1, pages 25-39, 2003. [3] Fredrik Vraalsen, Ruth A. Aydt, Celso L. Mendes and Daniel A. Reed, Performance Contracts: Predicting and Monitoring Grid Application Behavior, Grid Computing - GRID 2001: In Proceedings of the Second International Workshop on Grid Computing, Denver, CO, Springer-Verlag Lecture Notes in Computer Science 2242, pages 154-165, November 12, 2001. [4] GEO 600 homepage, http://www.geo600.uni-hannover.de/. [5] Grid Physics Network (GriPhyN), http://www.griphyn.org/. [6] Grid2003, http://www.ivdgl.org/grid2003/. [7] Ian Foster, Jens Vockler, Michael Wilde and Yong Zhao, Chimera: A Virtual Data System for Representing, Querying, and Automating Data Derivation, 10th International Conference on Scientific and Statistical Database Management (SSDBM02), 2002. [8] International Virtual Data Grid Laboratory (iVDGL), http://www.ivdgl.org/. [9] Jang Uk In, Adam Arbree, Paul Avery, Richard Cavanaugh, Suchindra Kategeri and Sanjay Ranka, SPHINX: A Scheduling Middleware For Data Intensive Applications On A Grid, GriPhyN Technical report 2003-17, 2003. [10] Linguo Gong, Xian-He Sun and Edward F. Waston, Performance Modeling and Prediction of Non-Dedicated Network Computing, IEEE Transactions on Computers, vol. 51, no. 9, September 2002. [11] Laser Interferometer Gravitational Wave Observatory (LIGO), http://www.ligo.caltech.edu/. [12] LIGO Scientific Collaboration, http://www.ligo.org/. [13] Linpack software library, http://www.netlib.org/benchmark/Linpackc/. [14] Particle Physics Data Grid (PPDG), http://www.ppdg.net/.

10

GriPhyN Technical Report 2004-25 [15] The Chimera Virtual Data System Version 1.2 User Guide, http://www.griphyn.org/chimera/snapshot/VDS-1-User-Guide.V37.0911.pdf/. [16] The Condor Project Homepage, http://www.cs.wisc.edu/condor/. [17] The Globus Alliance, http://www.globus.org/. [18] The Virtual Data Toolkit, http://www.lsc-group.phys.uwm.edu/vdt/. [19] Valerie Taylor, Xingfu Wu and Rick Stevens, Prophesy: An Infrastructure for Performance Analysis and Modeling of Parallel and Grid Applications, ACM SIGMETRICS Performance Evaluation Review, vol. 30, issue 4, March 2003. [20] Warren Smith, Ian Foster and Valerie Taylor, Predicting Application Run Times Using Historical Information, In Proceedings of the IPPS/SPDP ‘98Workshop on Job Scheduling Strategies for Parallel Processing, 1998. [21] Xian-He Sun and Ming Wu, GHS: A Performance Prediction and Task Scheduling System for Grid Computing, In Proceedings of 2003 IEEE International Parallel and Distributed Processing Symposium (IPDPS 2003), Nice, France, April 2003. [22] Xingfu Wu, Valerie Taylor and Rick Stevens, Design and Implementation of Prophesy Automatic Instrumentation and Data Entry System, the 13th IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS2001), Anaheim, California, August 2001. [23] Vikram S. Adve, Rajive Bagrodia, James C. Browne, Ewa Deelman, Aditya Dube, Elias N. Houstis, John R. Rice, Rizos Sakellariou, David J. Sundaram-Stukel, Patricia J. Teller and Mary K. Verno, POEMS: End-to-end Performance Design of Large Parallel Adaptive Computational Systems, IEEE Transactions on Software Engineering, vol. 26, no. 11, pages 1027-48, November 2000. [24] Ewa Deelman, James Blythe, Yolanda Gil, Carl Kesselman, Gaurang Mehta, Sonal Patil, Mei-Hui Su, Karan Vahi and Miron Livny, Pegasus : Mapping Scientific Workflows onto the Grid , Across Grids Conference 2004, Nicosia, Cyprus, 2004. [25] James Frey, Todd Tannenbaum, Ian Foster, Miron Livny and Steven Tuecke, Condor-G: A Computation Management Agent for Multi-Institutional Grids, Journal of Cluster Computing, vol. 5, pages 237-246, 2002. [26] Graham R. Nudd, Darren J. Kerbyson, Efstathios Papaefstathiou, Stewart C. Perry, John S. Harper and Daniel V. Wilcox, PACE - A Toolset for the Performance Prediction of Parallel and Distributed Systems, International Journal of High Performance Computing Applications, Special Issues on Performance Modeling, Sage Science Press, vol. 14, no. 3, pages 228-251, 2000. [27] Junwei Cao, Stephen A. Jarvis, Daniel P. Spooner, James D. Turner and Graham R. Nudd, Performance Prediction Technology for Agent-based Resource Management, 11th IEEE Heterogeneous Computing Workshop (HCW02), Fort Lauderdale, Florida, April 2002. [28] Ian Foster, Carl Kesselman and S. Tuecke, Abstract Entity Grouping Users, Institutions and Resources (if any) in the same administrative domain, The Anatomy of the Grid, International Journal of High Performance Computing Applications, 15, 3, 2001. [29] Richard Gibbons, Historical Application Profiler for Use by Parallel Schedulers, Lecture Notes on Computer Science, pages 58-75, 1997. [30] Xingfu Wu, Valerie Taylor, Jonathan Geisler, Xin Li, Zhiling Lan, Rick Stevens, Mark Hereld and Ivan R. Judson, Design and Development of Prophesy Performance Database for Distributed Scientific Applications, Proc. the 10th SIAM Conference on Parallel Processing for Scientific Computing, Virginia, March 2001.

11