grid computating vishal thesis report

An Adaptive Load Balancing Algorithm For Computational Grid __________________________________________________________________

_________________________________________________________________________ Maharishi Markandeshwar University, Mullana 1

Chapter 1 INTRODUCTION

This chapter gives an introduction to grid computing in the terms of its

characteristics, problem areas, load balancing, objective and organization

of dissertation.

1.1 Grid Computing The term grid is increasingly appearing in computer literature, generally

referring to some form of system framework into which hardware or

software components can be plugged, and which permits easy

configuration and creation of new functionality from existing components.

Grids enable the sharing, selection, and aggregation of a wide variety of

resources including supercomputers, storage systems, data sources, and

specialized devices that are geographically distributed and owned by

different organizations for solving large-scale computational and data

intensive problems in science, engineering, and commerce.

The term grid is chosen as an analogy to the electric power grid that

provides consistent, pervasive, dependable, transparent access to

electricity, irrespective of its source. Such an approach to network

computing is known by several names: meta computing, scalable

computing, global computing, Internet computing, and more recently Peer-

to-Peer computing.

The concept of grid computing [1] started as a project to link

geographically dispersed supercomputers, but now it has grown far beyond

its original intent. The grid infrastructure [2] can benefit many

applications, including collaborative engineering, data exploration, high

throughput computing, distributed supercomputing, and service-oriented



computing. Figure 1.1 shows a conceptual view of grid computing.

Figure 1.1: Grid computing: A conceptual view 1.2 Grid Characteristics

Heterogeneity: a grid hosts both software and hardware resources

that can be very varied ranging from data, files, software components or programs to sensors, scientific instruments, display

devices, personal digital organizers, computers, super-computers

and networks.

Geographical Distribution: grid’s resources may be located at

distant places.

Resource

Supercomputer

Network 2

Internet

Network 1

Network 3



Resource Sharing: resources in a grid belong to many different

organizations that allow other organizations (i.e. users) to access

them. Non local resources can thus be used by applications,

promoting efficiency and reducing costs.

Multiple Administrative Domains: each organization may establish

different security and administrative policies under which their

owned resources can be accessed and used. As a result, the already

challenging network security problem is complicated even more with

the need of taking into account all different policies.

Consistent Access: a grid must be built with standard services,

protocols and inter-faces thus hiding the heterogeneity of the

resources while allowing its scalability. Without such standards,

application development and pervasive use would not be possible.

1.3 Problem Areas in Grid Computing

Security: Since the number of users within a system is increased,

new security mechanisms are needed to ensure that malicious code

cannot legitimate services running on the grid.

Fault Tolerance: In a heterogeneous system like the Grid, failure is

inevitable. Failures of system resources have adverse affects on

applications performance. Failures can make a process run slower

than normal or even stop it.

Resource Scheduling: A grid federates a large number of resources

contributed by individual machines into a greater total virtual

resource. For applications that are grid-enabled, the grid can offer a

resource balancing effect by scheduling grid jobs on machines with

low utilization. This feature can prove invaluable for handling

occasional peak loads of activity in parts of a larger organization.



Load Balancing: Load Balancing is crucial to computational grids. It

is a mapping strategy that efficiently equilibrates the task load into

multiple computational resources in the network based on the

system status to improve performance [3].

Resource Discovery: Grid environment is an environment system in

which applications are composed of the large set of hardware and

software resources distributed among many locations. Hence, the

problem of resource discovery can be profoundly complex due to the

size and the complexity of Grid system.

1.4 Load Balancing In computer networking, load balancing is a technique to spread work

between two or more computers, network links, CPUs, hard drives, or

other resources, in order to get optimal resource utilization, throughput,

or response time. Using multiple components with load balancing, instead

of a single component, may increase reliability through redundancy.

The availability of low cost powerful computers coupled with the

popularity of the Internet and high-speed networks have led the computing

environment to be mapped from classical distributed to grid environments

[3]. To improve the global throughput of these environments, effective and

efficient load balancing algorithms are fundamentally important. Emerging

as new distributed computing environments, computational grids [4]

provide an opportunity to share a large number of resources among

different organizations. Performance enhancement is one of the most

important issues in such grid systems. One obvious way of achieving this

goal is to add more computing nodes to the grid. However, in many

situations, poor performance is due to uneven load distribution among the

nodes in the system. Therefore, to fully exploit the computing power of

such grid systems, it is crucial to employ a judicious load balancing



strategy for proper allocation and sequencing of tasks on the computing

nodes. Load balancing algorithms in classical distributed systems, which

usually run on homogeneous and dedicated resources, cannot work well in

the Grid architectures. Grids have a lot of specific characteristics [5], like

heterogeneity, autonomy and dynamicity, which remain obstacles for

applications to harness conventional load balancing algorithms directly.

Load balancing is a mapping strategy that efficiently equilibrates the task

load into multiple computational resources in the network based on the

system status to improve performance [3].

There are many reasons a company would consider upgrading to a

load balanced solution, but the most common reasons are scalability, high

availability, manageability, ease of use and predictability. The essential

objective of a load balancing can be [6], depending on the user or the

system administrator, defined by:

The aim for the user is to minimize the make spans of its own

application, regardless the performance of other applications in the

system.

The main goal for administrator is to maximize meet the tasks

deadline by ensuring maximal utilization of available resources.

1.5 Objective of Dissertation

The main objective is to propose an adaptive load balancing

algorithm that can handle heterogeneous grid sites. Here, the

heterogeneity only refers to processing power of sites.

The proposed algorithm will balance the load in the grid, based on

the queue length of each resource and transfer the job to the

resource having minimum queue length.

The proposed algorithm will be implemented using GridSim Toolkit.



1.6 Organization of Dissertation Chapter one is an introduction to grid computing, load balancing,

characteristics of grid computing and the objective of the dissertation.

Chapter two deals with literature survey. We have discussed the schemes

and policies of load balancing and the force driving us to carry out this

dissertation work. The generic grid architecture, proposed algorithm and

sequence diagram showing working of proposed algorithm is discussed in

chapter three. Results are analyzed in chapter four. Chapter five concludes

the work which has been carried out in the dissertation.



Chapter 2 LITERATURE SURVEY

2.1 Introduction Distributed network computing environments have become a cost effective

and popular choice to achieve high performance and to solve large scale

computation problems. Unlike past supercomputers a cluster or grid or

peer-to-peer system can be used as multipurpose computing platform to

run diverse high performance parallel applications. Cluster computing [17]

environment consist of Personal Computers that are interconnected using

high speed networks and are located at same location where as grid

computing involves coupled and coordinated use of geographically

distributed resources for purposes such as large scale computation and

distributed data analysis [18] [19]. A peer-to-peer system [20] is composed

of participants that make a portion of their resources (such as processing

power, disk storage, and network bandwidth) available directly to their

peers without intermediary network hosts or servers. Peers are both

suppliers and consumers of resources, in contrast to the traditional client-

server model where only servers supply, and clients consume.

A collection of autonomous intelligent devices connected through a

communication link is called Distributed System [21]. A major advantage

of using distributed system is resource sharing. A major shareable

resource is Central Processing Unit cycles. A distributed scheduler is a

resource management component of a distributed operating system that

focuses on redistributing the load of the system among the individual

devices, such that the overall performance of the system is optimized.

Load Balancing in a distributed system is a process of sharing

computational resources by transparently distributing system workload. A



distributed computing system consists of software programs and data

resources dispersed across independent devices. A workstation user may

not use the machine all the time, but may require more than it can provide

while actively working. Some devices may be heavily loaded, while other

remains idle. Performance enhancement is one of the most important

issues in distributed system. The performance of the system can often be

improved to an acceptable level simply by distributing the load among the

devices.

2.2 Motivation for Load Distribution Consider a grid System consisting of a collection of autonomous intelligent

devices connected in a Local Area Network. Because of the random arrival

of tasks and their random Central Processing Unit service time

requirements, there is a good probability that at any time some devices are

heavily loaded, while the other devices are idle or are less loaded [22]. In

[22] authors considered a system of N identical and independent M/M/1

servers, with all servers having the same task arrival and service rates.

Taking p to be the utilization of each server, they derived the probability P

that the system is in a state in which at least one task is waiting for

service and at least one server is idle. From their analysis, the following

two observations could be made: 1. For moderate values of p, the value of P is high, indicating a good

potential for performance improvement through load redistribution. 2. If p is either too small or too large, the value of P is low. In the former case, most of the servers are lightly loaded, and

redistribution does not help. In the latter case, most systems are likely

to be busy, and finding an idle processor is unlikely. These observations

indicate good scope for performance enhancement through load

redistribution, since it is reasonable to expect that most of the time the



utilization is moderate, and that the system reaches the two extremes only

infrequently. From a real world perspective, the following scenario could be

considered. In a typical university environment, the workstations and PCs

are not used equally in all the departments at all times of the day. On the

one hand, we have departments that carry out simulations of atmospheric

systems, and similar applications that may run for days or even weeks on

their workstations, while on the other hand there are departments that

run only administrative workloads. So, while the PCs in the latter groups

of departments are idle or are less loaded on holidays, the workstations in

the former group of departments are heavily loaded, and are carrying out

simulations that were started a long time back. In such a scenario, it

makes sense if we could transfer at least some parts of the tasks from the

heavily loaded devices to the lightly loaded ones. That way, the individual

PCs in the system are used efficiently, at no extra cost.

Because of the differences in communication mechanisms in various

architectures, the load balancing problem takes different forms:

1. For multiprocessor systems, because of the presence of a global shared

memory, the granularity of load balancing could be smaller. The shared

memory provides easy synchronization constructs that can facilitate finer

control over the load. Also, the interconnection networks in such systems

are fast and reliable, providing scope for efficient information exchange

about the current load information. To this category of load balancing

belong a large number of algorithms that try to distribute a single parallel

workload onto different devices such that the overall processor-memory

and interprocessor communications are minimized.

2. For distributed/cluster systems executing sequential workloads, the

granularity of load balancing should be much larger, so that the balancing

overhead is minimal. In this category of load balancing are the algorithms

that try to balance the overall load, taking into consideration the nature of



the interconnection network, the heterogeneity in the devices, and the

failure aspects of the component devices and those of the communication

channels.

3. Lastly, there is the group of algorithms that map a parallel load onto a

cluster of autonomous devices. In a way, these algorithms are hybrids of

the algorithms in the previous two groups. They have to consider the

communication aspects of the program, without the facility of shared

memory, and in the presence of the restrictions imposed by the

communication network and possible device/channel failures.

For parallel applications, load balancing attempts to distribute the

computation load across multiple processors or devices as evenly as

possible with objective to improve performance. Generally, a load

balancing scheme consists of three phases: information collection,

decision making and data migration. During the information collection

phase, load balancer gathers the information of workload distribution and

the state of computing environment and detects whether there is load

imbalance. The decision making phase focuses on calculating an optimal

data distribution, while the data migration phase transfers the excess

amount of workload from overloaded processor to underloaded ones.

2.3 Load Balancing Schemes In the past decades, a lot of research has focused on the development of

effective load balancing algorithms for grid computing environment. Load

balancing algorithms can be classified into static and dynamic

approaches.

Static load balancing algorithms [7] assume that a priori

information about all the characteristics of the jobs, the computing

devices and the communication network are known and provided.

Load balancing decisions are made deterministically or



probabilistically at compile time and remain constant during

runtime. The static approach is attractive because it is simple and

requires minimized runtime overhead. However, it has two major

disadvantages [8]. Firstly, the workload distribution of many

applications cannot be predicted before program execution.

Secondly, it assumes that the computing resources and

communication network are all known in advance and remain

constant. Such an assumption may not apply to a distributed

environment. As static approach cannot respond to the dynamic

runtime environment, it may lead to load imbalance on some devices

and significantly increase the job response time.

Dynamic load balancing algorithm [8] attempts to use the runtime

state information to make more informative decision in sharing the

system load. However, dynamic scheme is used a lot in modern load

balancing method due to their robustness and flexibility. In [23]

authors give classification schemes for dynamic algorithms which

differ in number and type of parameters. A list of common

parameters that can be used to characterize most of dynamic load

balancing algorithms are:

(i) Centralized vs. Decentralized. In the centralized approach

[5], only one node in the distributed system acts as the central

controller. It has a global view of the load information in the

system, and decides how to allocate jobs to each of the nodes.

The rest of the nodes act as slaves; they only execute the jobs

assigned by the controller. The centralized approach is more

beneficial when the communication cost is less significant e.g.

in the shared-memory multi-processor environment.. For the

centralized approach [8], many authors argue that this

approach is not scalable, because when the system size



increases, the central controller may become a system

bottleneck and the single point of failure. In the decentralized

approach [5], all nodes in the distributed system are involved

in making the load balancing decision. Decentralized

algorithms are more scalable and have better fault tolerance.

(ii) Cooperative vs. Non-cooperative. An algorithm is said to be

cooperative if the distributed components that constitute the

system cooperate in the decision-making process. Otherwise,

it is non-cooperative.

(iii) Adaptive vs. Non-adaptive. If the parameters of the algorithm

can change when the algorithm is being run, the algorithm is

said to be adaptive (to the changes in the environment in

which it is running). Otherwise, it is non-adaptive.

(iv) Source-initiated vs. Destination-initiated. In a source-

initiated algorithm, an over-loaded device starts negotiations

with the other nodes for a potential process-migration. If a

negotiation is started by an under-loaded node, the algorithm

is said to be destination-initiated.

(v) Preemptive vs. Non-preemptive. If a process that has started

its execution can be transferred to some other device, then the

algorithm is called a preemptive algorithm. If, on the other

hand, only those processes that are in the ready queue but

have not yet received central processing unit service could be

considered for migration, the algorithm is called a non-

preemptive algorithm.

2.4 Load Balancing Policies An algorithm for the load balancing problem can be broadly categorized in

terms of four policies [6]. They are:



Location Policy is the policy that affects the finding of a suitable

device for migration. The common technique followed here is

polling, on a broadcast, random, nearest-neighbour or roster basis.

Transfer policy is that which determine whether a device is

suitable for participating in a process-migration. One common

technique followed is the threshold policy, where a device

participates in a negotiation only when its load is less than (in

destination-initiated algorithm) or greater than (in sender-initiated

algorithm) a threshold value.

Selection policy is the policy that deals with the selection of the

process to be migrated. The common factors which must be

considered are the cost of migration (communication time, memory,

computational requirement of the process, etc.) and the expected

gain of migration (overall speedup of the system, etc.).

Information policy is that component of the algorithm that

decides what, how and when the information regarding the state of

the other devices in the system is gathered and managed. They can

be grouped under demand-driven, periodic, or state-change-driven

policies. The following are desirable properties of a load balancing algorithm:

Optimal overall system performance, defined as the total

processing capacity being maximized, while retaining acceptable

delays in metrics that are visible to the users.

Fairness of service, defined as uniformly acceptable performance

provided to jobs, regardless of the device on which each job arrives.

Good performance under rare but not-impossible extraneous

condition, like sudden bursty arrival of jobs, device and

communication channel failures, etc.

Low overhead in implementation of algorithm.



Algorithm should be stable and should not generate process

thrashing. Namely, a process should not be transferred between

devices without much productive work being done on it between

successive transfers.

2.5 Related Work A lot of research had already been done in the field of grid environment

related to load balancing. In [9] a computational grid is partitioned into

multiple regional grids around a well-known broker sites. A hybrid load

balancing policy integrated static and dynamic techniques is employed to

make efficient load balancing on each region and across regions. A load

balancing model based on tree representation of a grid is proposed in [6].

It includes a hierarchical load balancing strategy which uses a task-level

load balancing and privileges, as much as possible, a local load balancing

to avoid the use of WAN communication. In [10], authors analyze and

compare the effectiveness of dynamic load balancing and job replication by

means of trace-driven simulations. Agent-based approaches have been

tried to provide load balancing in cluster of machines [11]. In [12], authors

propose a decentralized grid model, as a collection of clusters and then

introduce a dynamic load balancing algorithm (DLBA) which performs

intra cluster and inter cluster (grid) load balancing. In [8], authors present

an efficient desirability-aware load balancing algorithm to tackle the new

challenges in heterogeneous grid systems along with the simulation

results. In [13], aiming at the hierarchical grid model structure, following

statistical thinking, this paper proposed a new task scheduling and

resource allocation algorithm, which can not only increase the utilization

of resources and system throughput, but also realize the load balancing

within grid systems. In [14], authors propose a system named RESERV, a

distributed information system for Grid applications with a novel load



balancing approach, able to handle extreme load unbalance. Dynamic load

balancing strategy called DLBEM based on maximum likelihood estimation

methods for parallel and distributed applications is proposed in [15]. The

DLBEM strategy reduces considerable communication overheads caused

by workload information exchange and job migration. In the meantime,

based on the expectation-maximization algorithm, DLBEM achieves near

accurate estimation of the global system state with significantly less

communication overheads and results in efficient workload balancing. In

[16], the Route load balancing algorithm is proposed, presented and

evaluated. This algorithm is designed to equally distribute the workload of

tasks of parallel applications over Grid computing environments.

In [17] authors proposed a dynamic load balancing algorithm which

considers CPU length, CPU and memory utilization and network traffic as

load metric. In this, result was compared with the results of algorithm that

is using only queue length as metric. In [24] authors developed a load

balancing strategy for communication–intensive applications to improve

the band-width across network of cluster. This scheme can make use of an

application model to quickly and accurately determine the load induced by

a variety of parallel applications. A communication-sensitive load balancer

has been proposed by authors in [25]. The balancer uses run-time

communication pattern between processes to balance load. The workload

estimation of each device for load balancing using fuzzy system is

implemented in [26] in which run-queue length and CPU utilization are

used as the input variables for fuzzy sets and a set of membership

function was defined. This scheme focuses only on run queue length &

CPU utilization factors, other factors such as cost of migration, reliability

etc. were not considered. In [27] authors proposed a decentralized load-

balancing algorithm for a grid environment. Presented method does not

consider the actual cost for a job transfer. In [28] and [29], a sender



processor collects status information about neighboring processors by

communicating with them at every load-balancing instant. This can lead to

frequent message transfers. For a large-scale distributed environment

where communication latency is very large, the status exchange at each

load-balancing instant can lead to large communication overhead. So the

problem of frequent exchange of information is alleviated by estimating the

load, based on the system state information received at sufficiently large

intervals of time. For a dynamic load-balancing algorithm, it is

unacceptable to frequently exchange state information because of the high

communication overheads. In order to reduce the communication

overheads, in [30] authors studied the effects of communication latency,

overhead, and bandwidth in cluster architecture to observe the impact on

application performance and in [31],[32] authors presented an ant colony

based method for load distribution in which appropriate attention is not

given for job migration cost. In [23] authors presented a tree based

algorithm for dynamic load balancing in grid environment. Several issues

such as adaptability, heterogeneity are considered. Proposed method

performance can be enhanced by using it with simulators such as

GridSim. [33] addresses several issues that are imperative to grid

environments such as handling resource heterogeneity and sharing,

communication latency, job migration from one site to other, and load

balancing. Two job migration algorithms, which are MELISA (Modified

ELISA) and LBoA (Load Balancing on Arrival) are proposed. The algorithms

differ in the way load balancing is carried out and is shown to be efficient

in minimizing the response time on large and small-scale heterogeneous

grid environments, respectively. MELISA, which is applicable to large-scale

systems, is a modified version of ELISA [34] in which job migration cost,

resource heterogeneity, and network heterogeneity when load balancing

are considered. The LBoA algorithm, which is applicable to small-scale



systems, performs load balancing by estimating the expected finish time of

a job on buddy processors on each job arrival. Both algorithms estimate

system parameters such as the job arrival rate, CPU processing rate, and

load on the processor and balance the load by migrating jobs to buddy

processors by taking into account the job transfer cost, resource

heterogeneity, and network heterogeneity. In this quantify the performance

of proposed method is quantisized using several influencing parameters

such as the job size, data transfer rate, status exchange period, and

migration limit, and discussed the implications of the performance and

choice of approaches used. No provision is provided for fault tolerance.

2.6 Challenges The development of adaptive and dynamic load balancing algorithms is

challenging because intelligent devices are prone to failures and the

topology of a grid system changes frequently due to device failures and

scalability. Key open research issues include the following:

The proposed load balancing schemes/methodologies for distributed

system focus on centralized based method only, ignoring

decentralization. Load balancing algorithms for decentralized based

method need to be investigated.

Current dynamic load balancing schemes such as MELISA and

LBoA [33] are not fault tolerant. So new techniques that are fault

tolerant are desirable.

New schemes with higher scalability and efficiency in terms of

communication overhead, heterogeneity need to be developed for the

distributed systems. Selecting the appropriate load balancing policy

for distributed systems is fundamental to providing load balancing

in distributed system. However, the decision depends on the

computation, storage and communication capability of the devices.



Recent studies on decentralized dynamic load balancing schemes

have demonstrated that decentralized dynamic schemes may be

practical in distributed systems. However, adaptive nature is still too

expensive in terms of computation and job migration cost to

accomplish in a distributed system. The application of adaptive

nature in load balancing schemes needs to be studied further.



Chapter 3 SYSTEM MODEL

This chapter gives an introduction to computational grid model, proposed

algorithm and sequence diagram showing working of proposed algorithm.

3.1 Generic Grid Architecture

Figure 3.1: Computational grid model

The computational grid comprises of GIS, users and resources.

Each resource is a computational unit with different processing

power.

All resources and users register their information to Grid

Information Server.



3.2 Proposed Algorithm The proposed algorithm for adaptive load balancing in computational grid

is as follows:

1. Input the value of number of Users (NU) and Resources (NR).

2. Initialize the gridsim toolkit.

3. Create the gridlength of each User.

4. Get the availability of all registered Resources.

5. Initialize the NextUser = 0 and QueueLength of each resource = 0.

6. Find the resource ‘ R ’ with minimum QueueLength.

7. Allocate the job of NextUser to R and SubmissionTime_job =

GridSim.Clock( ).

8. NextUser = NextUser + 1.

9. QueueLength_R = QueueLength_R + 1.

10. Check for the arrival of any job ‘ J ’ from Resource R’ after

completing the execution.

11. If no resource arrival exist then goto step 14.

12. QueueLength_R’ = QueueLength_R’ – 1.

13. ExecutionTime_J = GridSim.Clock( ) - SubmissionTime_J.

14. If NextUser <= NU then goto step 6.

15. Print ExecutionTime_J of all jobs.

3.3 Sequence Diagram Sequence Diagram showing working of adaptive load balancing algorithm

is explained as:

Firstly, all resources register (REG) their information to GIS.

Then all users send request (REQ) to GIS for Resource

characteristics.

After that GIS sends resource characteristics (RC) to each user.



Now each user starts determining queue length (DQL) of each

resource and then send gridlet to resource having minimum

queue length (QL).

After gridlet execution is over, it is send back to user sending that

gridlet.

When all gridlets execution is over then each user print execution

time (ET) of gridlets.

Figure 3.2: Sequence diagram showing working of proposed algorithm



Chapter 4 SIMULATION & RESULTS

Following parameters are used during simulation of adaptive load balancing algorithm:

Table 4.1: Simulation parameters

Simulation Runs 4 No. of Resources 5 – 20

No. of Users 10 – 75 No. of Jobs 10 – 75

Gridlet Size (In MI) 10,000,000 - 750,000,000 Processing Power of Resources

( In MIPS) 200 – 400

The execution time of jobs corresponding to different users using ALBA (Adaptive Load Balancing Algorithm) and NALBA (Non Adaptive Load Balancing Algorithm) is shown in Figure 4.1 and Figure 4.2. The graph shows the execution time of jobs under NALBA is more than that of execution time of jobs with ALBA.

Table 4.2: Execution times of various users when number of resources = 3

Number of Resources = 3 Number of Users Execution Time (ALBA) Execution Time (NALBA)

10 2260186 2780202 25 10610471 14210527 50 37860946 44021172 75 81751425 87672115



0100000002000000030000000400000005000000060000000700000008000000090000000

100000000

10 25 50 75

Number of Users

Tim

e (s

ec)

ALBANALBA

Figure 4.1: Execution times of various users when number of resources = 3

Table 4.3: Execution times of various users when number of resources = 5

Number of Resources = 5 Number of Users Execution Time (ALBA) Execution Time (NALBA)

10 1700336 2140365 25 7250840 8010944 50 24501682 29461994 75 51752522 56793571

0

10000000

20000000

30000000

40000000

50000000

60000000

10 25 50 75

Number of Users

Tim

e (s

ec)

ALBANALBA

Figure 4.2: Execution times of various users when number of resources = 5



The execution time of jobs corresponding to different resources using ALBA and NALBA is shown in Figure 4.3 and Figure 4.4. The graph shows that execution time of jobs under ALBA is still less as compared to NALBA even when number of resources are increased due to selection of only those resources which has minimum load.

Table 4.4: Execution times of various resources when number of users = 25

Number of Users = 25 Number of Resources Execution Time (ALBA) Execution Time (NALBA)

5 7250840 8011072

10 4851694 5691870 15 4052547 4892494 20 3653400 4573562

0

1000000

20000003000000

4000000

5000000

60000007000000

8000000

9000000

5 10 15 20

No. Of Resources

Tim

e(Se

c.)

ALBANALBA

Figure 4.3: Execution times of various resources when number of users = 25 Table 4.5: Execution times of various resources when number of users = 50

Number of Users = 50 Number of Resources Execution Time (ALBA) Execution Time (NALBA)

5 24501682 29781949 10 14503492 18823936 15 11305201 15865760 20 9706906 14187526



0

5000000

10000000

15000000

20000000

25000000

30000000

35000000

5 10 15 20

No. of Resources

Tim

e (s

ec)

ALBANALBA

Figure 4.4: Execution times of various resources when number of users = 50 The results show that ALBA is better than the NALBA in all scenarios.



Chapter 5 CONCLUSION

In this dissertation, effect of load balancing on job in terms of execution time is analyzed. Results show that the execution time of ALBA is less as every time the resource with minimum queue length is selected for execution as compared to the execution time with NALBA. The algorithm is tested under various load conditions in terms of job length varying from 10,000,000 - 750,000,000 (MI). The performance of ALBA is also better when the system is lightly loaded in terms of increasing the resources and keeping the number of user as fixed.



Appendix A SOURCE CODE

import java.util.*; import gridsim.*; import java.io.*; class test11 extends GridSim { private Integer ID_; private String name_; private GridletList list_; private GridletList receiveList_; private int totalResource_; private int numgridlet; private static double ct[]; private static int ql[]; PrintWriter f = null; /** * @param name the Entity name of this object * @param baud_rate the communication speed * @param total_resource the number of grid resources available * @throws Exception This happens when creating this entity before * initializing GridSim package or the entity name is <tt>null</tt> or empty * @see gridsim.GridSim#Init(int, Calendar, boolean, String[], String[], String) */ test11(String name, double baud_rate, int total_resource,int num) throws Exception { super(name, baud_rate); this.name_ = name; this.numgridlet = num; this.totalResource_ = total_resource; this.receiveList_ = new GridletList(); this.ct=new double[num]; ql=new int[total_resource];



// Gets an ID for this entity this.ID_ = new Integer( getEntityId(name) ); System.out.println("Creating a grid user entity with name = " + name + ", and id = " + this.ID_); // Creates a list of Gridlets or Tasks for this grid user this.list_ = createGridlet( this.ID_.intValue()); System.out.println(name + ":Creating "+ this.list_.size() + " Gridlets"); } /** * The core method that handles communications among GridSim entities. */ public void body() { int resourceID[] = new int[this.totalResource_]; double resourceCost[] = new double[this.totalResource_]; String resourceName[] = new String[this.totalResource_]; LinkedList resList; ResourceCharacteristics resChar; // waiting to get list of resources. Since GridSim package uses // multi-threaded environment, request might arrive earlier // before one or more grid resource entities manage to register // themselves to GridInformationService (GIS) entity. // Therefore, it's better to wait in the first place while (true) { // need to pause for a while to wait GridResources finish //registering to GIS super.gridSimHold(1.0); // hold by 1 second resList = super.getGridResourceList(); if (resList.size() == this.totalResource_) break; else {



System.out.println(this.name_ + ":Waiting to get list of resources ..."); } } // a loop to get all the resources available int i = 0; for (i = 0; i < this.totalResource_; i++) { // Resource list contains list of resource IDs not grid resource //objects. resourceID[i] = ( (Integer)resList.get(i) ).intValue(); // Requests to resource entity to send its characteristics super.send(resourceID[i], GridSimTags.SCHEDULE_NOW, GridSimTags.RESOURCE_CHARACTERISTICS, this.ID_); // waiting to get a resource characteristics resChar = (ResourceCharacteristics) super.receiveEventObject(); resourceName[i] = resChar.getResourceName(); resourceCost[i] = resChar.getCostPerSec(); System.out.println(this.name_ + ":Received ResourceCharacteristics from " + resourceName[i] + ", with id = " + resourceID[i]); // record this event into "stat.txt" file super.recordStatistics("\"Received ResourceCharacteristics " + "from " + resourceName[i] + "\"", ""); } Gridlet gridlet; String info; // a loop to get one Gridlet at one time and sends it to a resource // entity with minimum queue length. Then waits for a reply. int id = 0;



synchronized(this) { ql[id] = ql[id] + this.list_.size(); } System.out.println("queue length: " +ql[id]); for (i = 0; i < this.list_.size(); i++) { gridlet = (Gridlet) this.list_.get(i); info = "Gridlet_" + gridlet.getGridletID(); System.out.println(this.name_ + ":Sending " + info + " to " + resourceName[id] + " with id = " + resourceID[id] + " Submission Time: " + gridlet.getSubmissionTime()); // Sends one Gridlet to a grid resource specified in "resourceID" super.gridletSubmit(gridlet, resourceID[id]); // Records this event into "stat.txt" file for statistical purposes super.recordStatistics("\"Submit " + info + " to " + resourceName[id] + "\"", ""); // waiting to receive a Gridlet back from resource entity gridlet = super.gridletReceive(); System.out.println(this.name_ + " :Receiving Gridlet " + gridlet.getGridletID() + " of " + this.name_ + " Finish Time: " + gridlet.getFinishTime()); // Records this event into "stat.txt" file for statistical purposes super.recordStatistics("\"Received " + info + " from " + resourceName[id] + "\"", gridlet.getProcessingCost()); // stores the received Gridlet into a new GridletList object this.receiveList_.add(gridlet); }



synchronized(this) { ql[id] = ql[id] - this.list_.size(); } System.out.println("queue length: " +ql[id]); // shut down all the entities, including GridStatistics entity since // we used it to record certain events. super.shutdownGridStatisticsEntity(); super.shutdownUserEntity(); super.terminateIOEntities(); System.out.println(this.name_ + ":%%%% Exiting body()"); } /** * Gets the list of Gridlets * @return a list of Gridlets */ public GridletList getGridletList() { return this.receiveList_; } /** * This method will show how to create Gridlets * @param userID the user entity ID that owns these Gridlets * @return a GridletList object */ private GridletList createGridlet(int userID) { // Creates a container to store Gridlets GridletList list = new GridletList(); int id = 0; for(int i=0;i < this.numgridlet;i++) { Gridlet gridlet1 = new Gridlet(id, (i+1)*10000000,1000000 ,1000000); id++; gridlet1.setUserID(userID);



// Store the Gridlets into a list list.add(gridlet1); } return list; } public static void main(String[] args) { System.out.println("Starting Example"); try { // First step: Initialize the GridSim package. It should be called // before creating any entities. We can't run this example without //initializing GridSim first. We will get run-time exception error. int num_user = 75; // number of grid users Calendar calendar = Calendar.getInstance(); boolean trace_flag = false; // mean don't trace GridSim events // list of files or processing names to be excluded from any statistical // measures String[] exclude_from_file = { "" }; String[] exclude_from_processing = { "" }; // the name of a report file to be written. We don't want to write anything // here. See other examples of using the ReportWriter class String report_name = null; // Initialize the GridSim package System.out.println("Initializing GridSim package"); GridSim.init(num_user, calendar, trace_flag, exclude_from_file, exclude_from_processing, report_name); // Second step: Creates one or more GridResource objects GridResource resource0 = createGridResource("Resource_0"); GridResource resource1 = createGridResource("Resource_1"); GridResource resource2 = createGridResource("Resource_2"); GridResource resource3 = createGridResource("Resource_3");



GridResource resource4 = createGridResource("Resource_4"); GridResource resource5 = createGridResource("Resource_5"); GridResource resource6 = createGridResource("Resource_6"); GridResource resource7 = createGridResource("Resource_7"); GridResource resource8 = createGridResource("Resource_8"); GridResource resource9 = createGridResource("Resource_9"); GridResource resource10 = createGridResource("Resource_10"); GridResource resource11 = createGridResource("Resource_11"); GridResource resource12 = createGridResource("Resource_12"); GridResource resource13 = createGridResource("Resource_13"); GridResource resource14 = createGridResource("Resource_14"); GridResource resource15 = createGridResource("Resource_15"); GridResource resource16 = createGridResource("Resource_16"); GridResource resource17 = createGridResource("Resource_17"); GridResource resource18 = createGridResource("Resource_18"); GridResource resource19 = createGridResource("Resource_19"); int total_resource = 20; // Third step: Creates grid users test11 user0 = new test11("User_0", 560.00, total_resource,1); test11 user1 = new test11("User_1", 560.00, total_resource,1); test11 user2 = new test11("User_2", 560.00, total_resource,1); test11 user3 = new test11("User_3", 560.00, total_resource,1); test11 user4 = new test11("User_4", 560.00, total_resource,1); test11 user5 = new test11("User_5", 560.00, total_resource,1); test11 user6 = new test11("User_6", 560.00, total_resource,1); test11 user7 = new test11("User_7", 560.00, total_resource,1); test11 user8 = new test11("User_8", 560.00, total_resource,1); test11 user9 = new test11("User_9", 560.00, total_resource,1); test11 user10 = new test11("User_10", 560.00, total_resource,1); test11 user11 = new test11("User_11", 560.00, total_resource,1); test11 user12 = new test11("User_12", 560.00, total_resource,1); test11 user13 = new test11("User_13", 560.00, total_resource,1); test11 user14 = new test11("User_14", 560.00, total_resource,1); test11 user15 = new test11("User_15", 560.00, total_resource,1); test11 user16 = new test11("User_16", 560.00, total_resource,1); test11 user17 = new test11("User_17", 560.00, total_resource,1);

test11 user18 = new test11("User_18", 560.00, total_resource,1); test11 user19 = new test11("User_19", 560.00, total_resource,1); test11 user20 = new test11("User_20", 560.00, total_resource,1); test11 user21 = new test11("User_21", 560.00, total_resource,1); test11 user22 = new test11("User_22", 560.00, total_resource,1);



test11 user23 = new test11("User_23", 560.00, total_resource,1); test11 user24 = new test11("User_24", 560.00, total_resource,1); test11 user25 = new test11("User_25", 560.00, total_resource,1);

test11 user26 = new test11("User_26", 560.00, total_resource,1); test11 user27 = new test11("User_27", 560.00, total_resource,1); test11 user28 = new test11("User_28", 560.00, total_resource,1); test11 user29 = new test11("User_29", 560.00, total_resource,1); test11 user30 = new test11("User_30", 560.00, total_resource,1); test11 user31 = new test11("User_31", 560.00, total_resource,1); test11 user32 = new test11("User_32", 560.00, total_resource,1); test11 user33 = new test11("User_33", 560.00, total_resource,1); test11 user34 = new test11("User_34", 560.00, total_resource,1); test11 user35 = new test11("User_35", 560.00, total_resource,1); test11 user36 = new test11("User_36", 560.00, total_resource,1); test11 user37 = new test11("User_37", 560.00, total_resource,1); test11 user38 = new test11("User_38", 560.00, total_resource,1); test11 user39 = new test11("User_39", 560.00, total_resource,1); test11 user40 = new test11("User_40", 560.00, total_resource,1); test11 user41 = new test11("User_41", 560.00, total_resource,1); test11 user42 = new test11("User_42", 560.00, total_resource,1); test11 user43 = new test11("User_43", 560.00, total_resource,1); test11 user44 = new test11("User_44", 560.00, total_resource,1); test11 user45 = new test11("User_45", 560.00, total_resource,1); test11 user46 = new test11("User_46", 560.00, total_resource,1); test11 user47 = new test11("User_47", 560.00, total_resource,1); test11 user48 = new test11("User_48", 560.00, total_resource,1); test11 user49 = new test11("User_49", 560.00, total_resource,1); test11 user50 = new test11("User_50", 560.00, total_resource,1); test11 user51 = new test11("User_51", 560.00, total_resource,1); test11 user52 = new test11("User_52", 560.00, total_resource,1); test11 user53 = new test11("User_53", 560.00, total_resource,1); test11 user54 = new test11("User_54", 560.00, total_resource,1); test11 user55 = new test11("User_55", 560.00, total_resource,1); test11 user56 = new test11("User_56", 560.00, total_resource,1); test11 user57 = new test11("User_57", 560.00, total_resource,1); test11 user58 = new test11("User_58", 560.00, total_resource,1); test11 user59 = new test11("User_59", 560.00, total_resource,1); test11 user60 = new test11("User_60", 560.00, total_resource,1); test11 user61 = new test11("User_61", 560.00, total_resource,1); test11 user62 = new test11("User_62", 560.00, total_resource,1); test11 user63 = new test11("User_63", 560.00, total_resource,1); test11 user64 = new test11("User_64", 560.00, total_resource,1); test11 user65 = new test11("User_65", 560.00, total_resource,1); test11 user66 = new test11("User_66", 560.00, total_resource,1);



test11 user67 = new test11("User_67", 560.00, total_resource,1); test11 user68 = new test11("User_68", 560.00, total_resource,1); test11 user69 = new test11("User_69", 560.00, total_resource,1); test11 user70 = new test11("User_70", 560.00, total_resource,1); test11 user71 = new test11("User_71", 560.00, total_resource,1); test11 user72 = new test11("User_72", 560.00, total_resource,1); test11 user73 = new test11("User_73", 560.00, total_resource,1); test11 user74 = new test11("User_74", 560.00, total_resource,1);

// Fourth step: Starts the simulation GridSim.startGridSimulation(); // Final step: Prints the Gridlets when simulation is over GridletList newList = null; newList = user0.getGridletList(); user0.printGridletList(newList, "User_0"); newList = user1.getGridletList(); user1.printGridletList(newList, "User_1"); newList = user2.getGridletList(); user2.printGridletList(newList, "User_2"); newList = user3.getGridletList(); user3.printGridletList(newList, "User_3"); newList = user4.getGridletList(); user4.printGridletList(newList, "User_4"); newList = user5.getGridletList(); user5.printGridletList(newList, "User_5"); newList = user6.getGridletList(); user6.printGridletList(newList, "User_6"); newList = user7.getGridletList(); user7.printGridletList(newList, "User_7"); newList = user8.getGridletList(); user8.printGridletList(newList, "User_8");



newList = user9.getGridletList(); user9.printGridletList(newList, "User_9"); newList = user10.getGridletList(); user10.printGridletList(newList, "User_10"); newList = user11.getGridletList(); user11.printGridletList(newList, "User_11"); newList = user12.getGridletList(); user12.printGridletList(newList, "User_12"); newList = user13.getGridletList(); user13.printGridletList(newList, "User_13"); newList = user14.getGridletList(); user14.printGridletList(newList, "User_14"); newList = user15.getGridletList(); user15.printGridletList(newList, "User_15"); newList = user16.getGridletList(); user16.printGridletList(newList, "User_16"); newList = user17.getGridletList(); user17.printGridletList(newList, "User_17"); newList = user18.getGridletList(); user18.printGridletList(newList, "User_18"); newList = user19.getGridletList(); user19.printGridletList(newList, "User_19"); newList = user20.getGridletList(); user20.printGridletList(newList, "User_20"); newList = user21.getGridletList(); user21.printGridletList(newList, "User_21"); newList = user22.getGridletList(); user22.printGridletList(newList, "User_22"); newList = user23.getGridletList(); user23.printGridletList(newList, "User_23");



newList = user24.getGridletList(); user24.printGridletList(newList, "User_24"); newList = user25.getGridletList(); user25.printGridletList(newList, "User_25"); newList = user26.getGridletList(); user26.printGridletList(newList, "User_26"); newList = user27.getGridletList(); user27.printGridletList(newList, "User_27"); newList = user28.getGridletList(); user28.printGridletList(newList, "User_28"); newList = user29.getGridletList(); user29.printGridletList(newList, "User_29"); newList = user30.getGridletList(); user30.printGridletList(newList, "User_30"); newList = user31.getGridletList(); user31.printGridletList(newList, "User_31"); newList = user32.getGridletList(); user32.printGridletList(newList, "User_32"); newList = user33.getGridletList(); user33.printGridletList(newList, "User_33"); newList = user34.getGridletList(); user34.printGridletList(newList, "User_34"); newList = user35.getGridletList(); user35.printGridletList(newList, "User_35"); newList = user36.getGridletList(); user36.printGridletList(newList, "User_36"); newList = user37.getGridletList(); user37.printGridletList(newList, "User_37"); newList = user38.getGridletList();



user38.printGridletList(newList, "User_38"); newList = user39.getGridletList(); user39.printGridletList(newList, "User_39"); newList = user40.getGridletList(); user40.printGridletList(newList, "User_40"); newList = user41.getGridletList(); user41.printGridletList(newList, "User_41"); newList = user42.getGridletList(); user42.printGridletList(newList, "User_42"); newList = user43.getGridletList(); user43.printGridletList(newList, "User_43"); newList = user44.getGridletList(); user44.printGridletList(newList, "User_44"); newList = user45.getGridletList(); user45.printGridletList(newList, "User_45"); newList = user46.getGridletList(); user46.printGridletList(newList, "User_46"); newList = user47.getGridletList(); user47.printGridletList(newList, "User_47"); newList = user48.getGridletList(); user48.printGridletList(newList, "User_48"); newList = user49.getGridletList(); user49.printGridletList(newList, "User_49"); newList = user50.getGridletList(); user50.printGridletList(newList, "User_50"); newList = user51.getGridletList(); user51.printGridletList(newList, "User_51"); newList = user52.getGridletList(); user52.printGridletList(newList, "User_52");



newList = user53.getGridletList(); user53.printGridletList(newList, "User_53"); newList = user54.getGridletList(); user54.printGridletList(newList, "User_54"); newList = user55.getGridletList(); user55.printGridletList(newList, "User_55"); newList = user56.getGridletList(); user56.printGridletList(newList, "User_56"); newList = user57.getGridletList(); user57.printGridletList(newList, "User_57"); newList = user58.getGridletList(); user58.printGridletList(newList, "User_58"); newList = user59.getGridletList(); user59.printGridletList(newList, "User_59"); newList = user60.getGridletList(); user60.printGridletList(newList, "User_60"); newList = user61.getGridletList(); user61.printGridletList(newList, "User_61"); newList = user62.getGridletList(); user62.printGridletList(newList, "User_62"); newList = user63.getGridletList(); user63.printGridletList(newList, "User_63"); newList = user64.getGridletList(); user64.printGridletList(newList, "User_64"); newList = user65.getGridletList(); user65.printGridletList(newList, "User_65"); newList = user66.getGridletList(); user66.printGridletList(newList, "User_66"); newList = user67.getGridletList(); user67.printGridletList(newList, "User_67");



newList = user68.getGridletList(); user68.printGridletList(newList, "User_68"); newList = user69.getGridletList(); user69.printGridletList(newList, "User_69"); newList = user70.getGridletList(); user70.printGridletList(newList, "User_70"); newList = user71.getGridletList(); user71.printGridletList(newList, "User_71"); newList = user72.getGridletList(); user72.printGridletList(newList, "User_72"); newList = user73.getGridletList(); user73.printGridletList(newList, "User_73"); newList = user74.getGridletList(); user74.printGridletList(newList, "User_74"); System.out.println("Finish Example"); } catch (Exception e) { e.printStackTrace(); System.out.println("Unwanted errors happen"); } } /** * Creates one Grid resource. A Grid resource contains one or more * Machines. Similarly, a Machine contains one or more PEs * (Processing Elements or CPUs). * In this simple example, we are simulating one Grid resource with * one Machine that contains one or more PEs. * @param name a Grid Resource name * @return a GridResource object */ private static GridResource createGridResource(String name) { // Here are the steps needed to create a Grid resource: // 1. We need to create an object of MachineList to store one or



// more Machines MachineList mList = new MachineList(); // 2. A Machine contains one or more PEs or CPUs. Therefore, should // create an object of PEList to store these PEs before creating a // Machine. PEList peList1 = new PEList(); // 3. Create PEs and add these into an object of PEList. // In this example, all PEs has the same MIPS (Millions // Instruction Per Second) Rating for a Machine. peList1.add( new PE(0, 200) ); // need to store PE id and // MIPS Rating // 4. Create one Machine with its id and list of PEs or CPUs mList.add( new Machine(0, peList1) ); // First Machine // 6. Create a ResourceCharacteristics object that stores the // properties of a Grid resource: architecture, OS, list of // Machines, allocation policy: time- or space-shared, time zone // and its price (G$/PE time unit). String arch = "Sun Ultra"; // system architecture String os = "Solaris"; // operating system double time_zone = 9.0; // time zone this resource located double cost = 3.0; // the cost of using this resource ResourceCharacteristics resConfig = new ResourceCharacteristics( arch, os, mList, ResourceCharacteristics.TIME_SHARED, time_zone, cost); // 7. Finally, we need to create a GridResource object. double baud_rate = 100.0; // communication speed long seed = 11L*13*17*19*23+1; double peakLoad = 0.0; // the resource load during peak hour double offPeakLoad = 0.0; // the resource load during off-peak hr



double holidayLoad = 0.0; // the resource load during holiday // incorporates weekends so the grid resource is on 7 days a week LinkedList Weekends = new LinkedList(); Weekends.add(new Integer(Calendar.SATURDAY)); Weekends.add(new Integer(Calendar.SUNDAY)); // incorporates holidays. However, no holidays are set in this example LinkedList Holidays = new LinkedList(); GridResource gridRes = null; try { gridRes = new GridResource(name, baud_rate, seed, resConfig, peakLoad, offPeakLoad, holidayLoad, Weekends, Holidays); } catch (Exception e) { e.printStackTrace(); } System.out.println("Creates one Grid resource with name = " + name); return gridRes; } /* * Prints the Gridlet objects * @param list list of Gridlets */ private void printGridletList(GridletList list, String name) { try{ f=newPrintWriter("H:\\gridsimtoolkit4.1\\examples\\Example06\\test11new.txt"); int size = list.size(); Gridlet gridlet; String indent = " "; System.out.println(); System.out.println("========== OUTPUT for " + name + " ==========");



System.out.println("Gridlet ID" + indent + "User" + indent + "Resource ID" + indent + "Execution time"); for (int i = 0; i < size; i++) { gridlet = (Gridlet) list.get(i); System.out.print(indent + gridlet.getGridletID() + indent + indent); System.out.print(name); System.out.println( indent + indent + gridlet.getResourceID() + indent + indent + gridlet.getFinishTime()); } f.close(); } catch(IOException e) {} } int min() { int index = 0,s; s = ql[0]; for(int i=1; i < totalResource_ ; i++) { if(s > ql[i]) { s = ql[i]; index = i; } } return index; } } // end class



Appendix B REFERENCES

[1] Yulai Yuan, Yongwei Wu, Guangwen Yang, and Weimin Zheng,”

Adaptive Hybrid Model for Long Term Load Prediction in Computational

Grid,” 8th IEEE International Symposium on Cluster Computing and

the Grid, pp.340-347, August 2008.

[2] Youchan Zhu, Lei An, Shuangxi Liu,” A Resource Discovery Method of

Grid Based on Resource Classification,” Proceedings of First

International Conference on Intelligent Networks and Intelligent

Systems, pp. 716-719, August 2008.

[3] C. Xu and F. Lau, “Load Balancing in Parallel Computers: Theory and

Practice,” Kluwer, Boston, MA, 1997.

[4] Yajun Li, Yuhang Yang, and Rongbo Zhu,” A Hybrid Load Balancing

Strategy of Sequential Tasks for Computational Grids,” International

Conference on Networking and Digital Society (ICNDS), 2009.

[5] M. Baker, R. Buyya, and D. Laforenza, “Grids and grid technologies for

wide area distributed computing,” International Journal of Software:

Practice and Experience (SPE), vol. 32(15), 2002.

[6] B. Yagoubi, and M. Medebber, “A load balancing model for grid

environment,” Proceeding of 22nd International Symposium on

Computer and Information Sciences (ISCISC 2007), pp. 1-7, 7

November 2007.

[7] C. Kim and H. Kameda,” An algorithm for optimal static load balancing

in distributed computer systems,” IEEE Transaction on Computers, vol.

41(3), pp. 381-384, March 1992.

[8] K. Lu, R. Subrata, and A. Zomaya, “An Efficient Load Balancing

Algorithm for Heterogeneous Grid Systems Considering Desirability of



Grid Sites,” Journal of Computer and System Sciences, vol. 73(8), pp.

1191-1206, December 2006.

[9] K. Lu, and A. Zomaya, “A Hybrid Policy for Job Scheduling and Load

Balancing in Heterogeneous Computational Grids,” Proceeding of 6th

International Symposium on Parallel and Distributed Computing, pp.

19-26, 5 July 2007.

[10] M. Dobber, R. Mei, and G. Koole,” Dynamic Load Balancing and Job

Replication in a Global-Scale Grid Environment: A Comparison,” IEEE

Transaction on Parallel and Distributed Systems, vol. 20(2), pp. 207-

218, February 2009.

[11] J. Cao, D.P. Spooner, S. A. Jarvi, and G.R. Nudd,” Grid Load

Balancing Using Intelligent Agents,” Future Generation Computer

Systems, vol. 21(1), pp. 135-149, January 2005.

[12] P. K. Suri, and Manpreet Singh,” An Efficient Decentralized Load

Balancing Algorithm For Grid,” IEEE 2nd International Advance

Computing Conference, pp. 10-13, February 2010.

[13] Bin Lu, and Hongbin Zhang,” Grid Load Balancing Scheduling

Algorithm Based on Statistics Thinking,” IEEE 9th International

Conference, pp. 288-292, 2008.

[14] Gabor Vincze, Zoltan Novak, Zoltan Pap, and Rolland Vida,” RESERV:

A Distributed, Load Balanced Information System for Grid

Applications,” 8th IEEE International Symposium on Cluster

Computing and the Grid, pp. 596-601, 2008.

[15] Han Zhao, Xinxin Liu, and Xiaolin Li,” DLBEM: Dynamic Load

Balancing Using Expectation-Maximization,” IEEE, August 2008.

[16] Rodrigo Fernandes de Mello, and Luciano Jos´e Senger,” A Routing

Load Balancing Policy for Grid Computing Environments,” Proceedings

of the 20th International Conference on Advanced Information

Networking and Applications (AINA’06), IEEE, 2006.



[17] Paul Werstein, Hailing Situ and Zhiyi Huang, “Load Balancing in a

Cluster Computer,” in Proceedings of the Seventh International

Conference on Parallel and Distributed Computing, Applications and

Technologies (PDCAT'06), pp. 569-577, 2006.

[18] Casey, L.M., “Decentralized Scheduling”, The Australian Computer

Journal, vol. 13(2), pp. 58- 63, February 1981.

[19] C. Sosa, and A.S. Grimshaw, “Bringing the Grid Home,” in

Proceedings of 9th IEEE/ACM International Conference on Grid

Computing, pp. 152-159, September 2008.

[20] C. Chen, K.C. Tsai., “The server reassignment problem for load

balancing in structured P2P systems,” IEEE Transaction on Parallel

Distributed Systems, vol. 19(2), pp. 234–246, 2008.

[21] Casauant, T.L., and Kuhl, J. G., “A Tamnomy of Scheduling in

General-Purpose Distributed Computing Systems,” Institute of

Electrical and Electronics Engineer Transaction on Software

Engineering, vol. 14(1l), pp. 1578-88, November 1988.

[22] Livny, M., and M. Melman, “Load Balancing in Homogeneous

Broadcast Distributed Systems,” in Proceedings of the ACM Computer

Network: Performance Symposium, pp. 47-55, April 1982.

[23] B. Yagoubi, Y. Slimani, “Task Load Balancing Strategy for Grid

Computing,” Journal of Computer Science vol. 3(3), pp. 186-194, 2007.

[24] Xio Qin and Hong Jeong, “Improving Effective Bandwidth of Networks

on Clusters using Balancing for Communication - Intensive,” in

Proceedings of the 24th IEEE Intern Computing and Communications

Conference (IPCCC 2005), Phoenix, Arizona, pp. 27-34, 7-9 April, 2005.

[25] S. Hotovy, D. Schneider, and T. O’Donnell, “Analysis of the early

workload on the cornell theory,” ACM SIGMETRICS Conference on

Measurement and Modeling of Computer Systems, vol. 24(1), pp. 272-

273, May 1996.



[26] Yu-kwong., Lap-sun., “A new fuzzy-decision based load balancing

system for distributed object computing,” Journal of Parallel and

Distributed Computing, vol. 64(2), pp. 238-253, 2004.

[27] M. Arora, S.K. Das, and R. Biswas, “A De-Centralized Scheduling and

Load Balancing Algorithm for Heterogeneous Grid Environments,” in

Proceedings of International Conference on Parallel Processing

Workshops (ICPPW ’02), pp. 499-505, August 2002.

[28] Y. Murata, H. Takizawa, T. Inaba, and H. Kobayashi, “A Distributed

and Cooperative Load Balancing Mechanism for Large-Scale P2P

Systems,” in Proceedings of International Symposium on Applications

and Internet (SAINT ’06) Workshops, pp. 126-129, January 2006.

[29] H. Shan, L. Oliker, and R. Biswas, “Job Super Scheduler Architecture

and Performance in Computational Grid Environments,” in Proceedings

of ACM/IEEE Conference on Supercomputing, pp. 44-48, November

2003.

[30] R. Martin, A. Vahdat, D. Culler, and T. Anderson, “Effects of

Communication Latency, Overhead, and Bandwidth in a Cluster

Architecture,” in Proceedings of 24th Annual International Symposium

on Computer Architecture (ISCA ’97), vol. 25(2), pp. 85-97, May 1997.

[31] Siriluck Lorpunmanee, Mohd Noor Sap, Abdul Hanan Abdullah, and

Chai Chompoo-inwai, “An Ant Colony Optimization for Dynamic Job

Scheduling in Grid Environment,” International Journal of Computer

and Information Science and Engineering, vol. 1(4), pp. 207-214, 2007.

[32] Bing Qi Chunhui Zhao, “Ant Algorithm Based Load Balancing for

Network Sessions,” in Proceedings of 3rd International Conference on

Natural Computation, vol. 4, pp. 771-775, 2007.

[33] Ruchir Shah, Bhardwaj Veeravalli, and M. Misra, “On the Design of

Adaptive and Decentralized Load-Balancing Algorithms with Load

Estimation for Computational Grid Environments,” Institute of



Electrical and Electronics Engineer Transaction on Parallel and

Distributed System, vol. 18(12), pp. 1675-1686, December 2007.

[34] L. Anand, D. Ghose, and V. Mani, “ELISA: An Estimated Load

Information Scheduling Algorithm for Distributed Computing Systems,”

International Journal on Computers and Mathematics with

Applications, vol. 37(8), pp. 57-85, April 1999.

grid computating vishal thesis report

Documents

concept of grid computing

computational grid

network computing

term grid

grid hosts

grid infrastructure

internet computing

peer computing