Aspect-Oriented Parallel Discrete Optimization on ... - Semantic Scholar

Aspect-Oriented Parallel Discrete Optimization on the Cohesion Desktop Grid Platform Wolfgang Blochinger Clemens Dangelmayr Sven Schulz ∗ University of T¨ubingen, Symbolic Computation Group Sand 14, D-72076 T¨ubingen, Germany http://www-sr.informatik.uni-tuebingen.de

Abstract This paper deals with our novel Desktop Grid platform Cohesion, which is designed to lay the system-level foundations for advanced parallel programming models and application specific frameworks. Cohesion specifically integrates functionality for parallel computing, e.g. a scalable group model and methods for collective communication. It is designed as an extensible layered architecture built around an industrial strength microkernel component. As an initial use case, we present an aspect-oriented framework for parallel discrete optimization built on top of Cohesion.

1. Introduction Desktop Grids pool idle resources of desktop computer systems for tackling resource intensive problems. Depending on the considered application domain, the overall number of computers aggregated by a Desktop Grid ranges from some dozens (e.g. workstations of corporate networks) to many thousands (Global Computing). Since contemporary desktop computer technology features enormous CPU power, even small-scale Desktop Grids are capable to deliver supercomputer-level performance. However, Desktop Grids differ significantly from traditional parallel computer systems. Particularly, resources exhibit a high degree of volatility and heterogeneity: Depending on the usage-patterns of the participating desktop computers, resources continuously join and leave the grid. The question which classes of parallel applications actually can be realized under these conditions is important for gaining a deeper understanding of the benefits and limitations of the Desktop Grid approach. Desktop Grid applications are most often based on trivial parallelism: The problem is divided into independent ∗ Author

names in alphabetical order

sub-problems which are farmed out for computation without further communication among the sub-problems (e.g. Monte Carlo simulations). Extending the scope of the Desktop Grid approach towards non-trivial parallel applications involves aspects on all levels of parallel system design. In the systems domain we need platforms supporting complex interaction patterns, in the field of programming we need expressive parallel programming models which can cope with volatility, and in the field of application design we need adaptively parallel methods. In this paper we present our Cohesion Desktop Grid platform. Cohesion was specifically designed to lay systemlevel foundations for advanced parallel programming models and application specific frameworks. It integrates a comprehensive collection of basic functionality required for parallel computing, like a scalable group model, various methods for collective communication, and also advanced procedures for distributed coordination and failure detection. Currently, we focus on employing Cohesion for irregular task-parallel applications. We investigate on the usefulness of our approach by means of a framework for parallel discrete optimization leveraging the functionality provided by Cohesion. It addresses specific challenges arising from the dynamic nature of irregular task-parallel applications, like dynamic problem decomposition, load balancing, termination detection and fault tolerance. The presented approach has been motivated by earlier studies we made on deploying a highly irregular task-parallel application (parallel Boolean satisfiability solving [3]) on a conventional Desktop Grid platform [4].

2. Related Work 2.1. Conventional Desktop Grid Platforms Conventional Desktop Grid platforms employ proven and well-understood operational models, thus have reached a considerable degree of maturity and stability. Typically,

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

2.2. Advanced Desktop Grid Platforms For the purpose of our discussion, we consider a Desktop Grid platform as advanced, if it employs an operational model based on sophisticated (e.g. Peer-2-Peer) communication functionality. In recent years, several experimental platforms of this kind have been described in the literature. Subsequently, we discuss some representatives which are continuously developed and maintained. The JNGI [19] Desktop Grid platform is mainly targeted for coarse-grained, embarrassingly parallel applications. It supports a master/worker programming model, thus is very similar to the conventional platforms at the programming model level. However, JNGI exhibits a strong focus on scalability and reliability. It pursues a self-organizing approach taking advantage of the capabilities of the JXTA P2P platform. The primary goal of the Personal Power Plant (P3) Desktop Grid platform [14] is to enable mutual and equal transfer of computing power between participating individuals. P3 provides master-worker and also message passing based programming models. It is implemented on top of the JXTA P2P protocol suite. IBIS [18] focuses on providing flexible, object-based communication primitives for Desktop Grid environments exhibiting a high degree of heterogeneity. It supports various generalizations of the remote method invocation model based on active objects.

3. Cohesion Desktop Grid Platform Our platform belongs to the class of advanced Desktop Grid platforms, since it provides various P2P style communication mechanisms. The main design focus of Cohesion is to provide a substrate for parallel programming models that are useful for non-trivial parallel applications.

Application Programming Models / Frameworks

Communication Microkernel & Substrate

Tools

Virtualization Cohesion

these platforms are designed in a client/server or multi-tier approach and support (variations of) the master/worker programming model. They are particularly suited for deploying commercial or mission-critical applications. However, conventional Desktop Grid platforms are mainly suited for applications which are based on trivial parallelism or for high throughput computing. Prominent non-commercial representatives of this class of Desktop Grid platforms are Boinc [5], XtremWeb [8], and ZetaGrid [20]. Examples of commercial platforms are Entropia DCGrid [7], Platform LSF [16], and United Devices GridMP [12]. Differences among these platforms can be observed concerning the client-side security model (signed code vs. sandboxing), whether the platform supports heterogeneous (especially non MS Windows) Desktop Grids or is capable of dynamically integrating new applications.

Failure Detection

Group Membership

Composable Channels

Endpoint Management

Management JMX

Security

Integration

Logging

Eclipse/OSGi Platform

JXTA J2SE Substrate

Java Virtual Machine (JVM) Solaris

Windows

Linux

Others

Figure 1. Cohesion’s layered Architecture Cohesion decomposes into a layered architecture (see Figure 1) based on the platform independent Java 2 platform. On each layer we have implemented or leveraged sophisticated state-of-the-art solutions to meet the challenges of high-performance computing in Desktop Grids outlined in Section 1. We first give a top-down overview of the responsibilities and main concepts of each layer. • Virtualization Layer - On this layer, we virtualize resources contributed by participating nodes. Nodes federate, forming groups, to work towards a common goal by employing syndicated resources. To support large resource pools, we employ a scalable state-of-the-art group model. Programming models and frameworks on higher layers are expected to rely on a task abstraction. To achieve task scheduling efficiency, it is obviously of great importance to have an accurate view of the available resource set. Therefore, we have implemented an efficient up-to-date failure detection algorithm. • Communication Layer - This layer provides for configurable and extensible communication. Cohesion differs from common platforms, as it allows for the integration of arbitrary providers of customized communication methods with diverse semantics. Furthermore, the conceptual model of composable channels allows for assembling communication channels from modularized aspects of communication (like compression, encryption or reliability). By providing a range of both, communication providers (including collective operations and robust message dissemination techniques) and modularized aspects, higher-level virtualization and application services can compose communication channels that best fit their needs. By leveraging JXTA [10] technology as default transport, Cohesion is applicable for wide area networks (WAN) with segmentations induced by firewalls and NAT devices, which are typical for environments within which Desktop Grids are deployed. • Microkernel Layer - On this layer we provide a set of basic platform services including JMX-based management, logging for diagnostic purposes and host

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

system integration facilities. To be extensible and modular, Cohesion leverages a microkernel architecture, that is the foundation of the well-known Eclipse IDE. This solution has beneficial effects on both the suitability and the usability of the Cohesion platform without compromising performance and resource consumption. A more comprehensive bottom-up discussion of each layer is presented in subsequent paragraphs.

3.1. Microkernel Modularization is an important software engineering concept to tackle the problem of increasing complexity in state-of-the-art middleware architectures. In contrast to existing platforms, Cohesion is explicitely designed to be modular and extensible. Since there is no support for modularization in the Java 2 platform, we employ an existing language external mechanism: The Open Services Gateway Interface (OSGi) Specification [1] models modularity around the notion of bundles. A bundle is comprised of Java classes, other resources and meta information to describe the inter-dependencies among bundles. By using OSGi, we can profit from a range of matured service specifications to implement orthogonal aspects of a full-featured Desktop Grid platform, like security or lifecycle management. Especially the former is critical for Desktop Grids since hosts must be shielded from damage caused by malicious code. OSGi provides a robust role-based security facility that complements the codeor source-based permission model of the Java 2 platform. Furthermore, OSGi’s approach to security allows for dynamic security policies with real-time permission management over a well-defined API. It is thus better suited to highly dynamic environments like the Cohesion Desktop Grid platform than plain Java 2 security. In conventional systems a common way to achieve extensibility is to adopt the Microkernel Pattern, where the whole system is built around a small core that can be extended through internal servers. A generalization of this concept is the abstract extension model of the Eclipse Platform. The singleton role of the system core as a point of extension is expanded to the level of modules, making OSGi bundles the source and target of extensions. Functionality defined by one bundle through an extension point can be implemented by other bundles and contributed through extensions. All major abstractions of the Cohesion platform are implemented on top of this abstract extension model. Thus, client bundles are free to select an implementation that best fits their needs. The negotiation process between functionality providers and consumers is modeled as a constraintbased brokerage. This approach decouples service partners and promotes flexibility.

Besides these benefits, it is not a priori apparent whether the Eclipse/OSGi runtime core is appropriate for a Desktop Grid platform. To dispel such doubts, we conducted an analysis regarding three critical aspects • With a memory footprint of 1.5 MB the share of a minimal Eclipse distribution in the aggregate memory footprint of a running Cohesion instance is negligible. The greater part (approximately 40 MB) arises from using JXTA as a substrate. • The size of the minimal distribution file is below 2 MB. Therefore, the impact on deployment costs is moderate. • There is no significant impact on method invocation performance, since OSGi inter-bundle method invocations are direct method invocations.

3.2. Communication Cohesion is a message passing communication platform. Nodes communicate by exchanging Simple Object Access Protocol (SOAP) messages over channels. SOAP is used as a lightweight and extensible message format (other features of the standard, like processing models are currently not used). Utilizing an XML message format not only boosts interoperability, but also ensures operability in the presence of introspecting firewalls. As applications targeted for the Cohesion platform are anticipated not to rely on finegrained parallelism, the overhead of XML generation and parsing is unlikely to become a limiting factor. Similar to the concept of streams in Java I/O, Cohesions composable channels (cf. Figure 1) are an instance of the Decorator design pattern: Channels of arbitrary complexity can be constructed from simple components. Each component encapsulates a certain aspect of communication (e.g. compression or encryption). This modularization of communication aspects fosters reuse and reduces complexity. Channels are established between endpoints. We have implemented a range of unicast and groupcast endpoints with different semantics that are contributed as extensions to Cohesion’s endpoint management facility (cp. Figure 1). For example, we created four different groupcast implementations with different transmission characteristics: a generic one that uses unicast endpoints to deliver messages, one based on JXTA propagation pipes with support for broadcasts on the local subnet, an epidemic one that is bandwidth conservative as it injects payload into external messages to reduce overhead introduced by non-payload message parts, and finally an implementation of Bimodal Multicast [2], a randomized protocol with probabilistic reliability properties. Client bundles can choose an endpoint implementation that best fits their needs. This is crucial since this choice

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

may have a considerable impact on the scalability and performance of higher level functionality provided by the application. Substrates. The Internet Protocol (IP) is the predominant network protocol on the Internet. However, nodes are typically organized in Local Area Networks (LAN) and shielded from the outside by firewalls and addresstranslating devices (NAT). The resulting segmentation affects mutual connectivity and thus limits the overall number of compute nodes available for aggregation to a Desktop Grid. To overcome this limitation, Cohesion leverages JXTA technology. JXTA is an open P2P communication platform that establishes an overlay network [17] on top of the physical network. Segmentations are bridged by so called relay peers which act as mediators between peers that cannot address each other directly. Although we use JXTA by default, Cohesion is designed to be network agnostic. It can be used on top of any network technology that satisfies a minimal set of constraints. To abstract from the specifics of the underlying network, we introduce the notion of a substrate. It is comprised of • a group implementation with an at least weak partial group model, that is used to instantiate the root group, and • a unicast endpoint that provides at least connectionless channels with unreliable message delivery, from which channels with higher-level quality of service characteristics can be derived. We compose the whole spectrum of the platform’s functionality from this core functionality. For example, the generic groupcast is used to implement a failure detection algorithm (at least, if no other, more efficient endpoint is available), which is used by our group implementation to detect ungraceful node departures. Substrates may be environment specific or serve a special purpose. For example, a centralized approach based on a star topology can be used to route all messages through a central gateway, thus providing insight into inter-node message flow for debugging or performance evaluation reasons.

3.3. Virtualization Through virtualization, higher level services (like termination detection or workload balancing) can deal with resources as first class objects. In Cohesion parlance, virtualized resources are called entities. Entities are announced to the system by publishing an XML description of them within a distributed directory, called a namespace. Once

discovered, a local proxy object is derived from the description, which subsequently may be used to interact with the remote entity. Cohesion leverages XQuery to allow nodes to lookup resources with maximized expressiveness, thus reducing bandwidth consumption by minimizing unnecessary transmission of entity descriptions. The efficiency of workload balancing, and hence of the distributed computation itself, heavily depends on an upto-date view of the available compute resources. Since resources are contributed by nodes, this translates to the necessity to quickly and accurately detect node arrivals and departures. Detection speed and accuracy (of both live and faulty nodes) are aspects of the efficiency [13] of the employed combination of group model and failure detection scheme. Common platforms feature combined approaches (frequently based on a lease mechanism). As described subsequently, this introduces a direct coupling between detection speed and accuracy that limits their overall efficiency. To overcome this limitation, group membership and failure detection are separate concepts in Cohesion (see Figure 1). For both, we employ state-of-the-art algorithms to achieve our objective to be scalable and efficient at the same time. Group membership. In Cohesion, nodes become visible as entities by joining a group. Groups are entities too and thus may be published and discovered within namespaces. A group’s conceptual purpose is to establish a logical partition within the node set and to define the scope of interaction (e.g. for communication through groupcast endpoints). Since groups are hierarchical, programmers may express relations among groups (parent/child, ancestor/descendant, sibling, etc.) in accordance with the application’s domain model. A group’s properties are determined by the implemented group model. In Cohesion, such models may be contributed as extensions and are bound to concrete groups on creation using the constraint-based brokerage algorithm mentioned in Section 3.1. Thus, higher level services are able to select a group model whose properties best fit their needs. Common group models (e.g. JXTA groups) have an implicit failure detection mechanism. A node’s availability is announced by a lease with fixed validity time. Between lease emission and lease renewal or expiration the node’s membership is static. If no renewal happens before the lease expires the node is removed from the local membership list, which is called the view of the node. Clearly, with such models there is a trade off between speed and accuracy which limits the overall efficiency of the approach. Since there is no way to control lease emission and distribution throughout the node set, the group model must be considered complete (which means every node knows of every node in its group). As a consequence, each locally detected

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

membership update must be sent to and processed on each node. The bottom line is that such models are neither highly scalable nor highly efficient, which disables them as a group model for large-scale compute-intensive Desktop Grid applications. Our default group model is based on SCAMP [9], a fully decentralized, self-organizing membership protocol, that establishes a partial view of size O(log(n)) on each member node. To solve the problem of bootstrapping (i.e. finding an initial contact to send a subscription request to), we designed a subprotocol that explicitely allows for partitions within the group. Each node bootstraps by establishing a single node micro-partition. Every time a node discovers another partition of the same group (within the parent group), the smaller of both is assimilated by the larger. Failure detection. If a node crashes or becomes isolated by faulty network links, the node’s membership is not cancelled through explict unsubscription. Such ungraceful node departures are detected by a failure detection component. It is a vital building block for efficient membership management as well as for fault tolerance mechanisms. The failure detection algorithm we use is adopted from the SWIM [6] system. Nodes are monitored through an efficient peer-to-peer periodic randomized probing protocol based on epidemic information dissemination. Neither detection speed nor message load per member vary with group size. False positives (i.e. nodes that are wrongly considered faulty) are reduced by first suspecting a participant node before declaring it as failed.

4. Aspect-Oriented Desktop Grid Framework for Parallel Discrete Optimization As an example application we study parallel discrete optimization in Desktop Grids using aspect-oriented design. Our aim is to review paradigms of software design as well as specific requirements emerging from parallelizing discrete optimization problems in Desktop Grids.

4.1. Discrete Optimization The general optimization problem consists of a set of possible solutions and a function which is to be maximized (or minimized) by an optimal solution. Discrete optimization problems differ from general optimization problems in that the set of possible solutions is finite and discrete. Instances of these problems are solved in many areas of scientific research or industrial application. Examples involve scheduling (like route planning or robot motion control), logistics and management.

In most cases, a state space graph is used to solve these problems. This graph is spanned when examining all possible actions step-by-step, heading for a solution. It is traversed via heuristic search techniques exploiting problemspecific knowledge, thus reducing the average time complexity. A generic algorithm realizing heuristic search employs an agenda which contains all currently open nodes of the search graph (search frontier). Typical techniques are breadth-first search, depth-first search or their derivatives using heuristics or heuristic estimates to direct the search. The latter can be used to order the nodes of the search frontier or rather to decide which node to extract next.

4.2. Aspect-Orientation The key paradigm of aspect-orientation is separation of concerns. For example, the aspect (or concern) of expanding a search graph is separated from the aspect of handling each node; likewise, the concern of algorithm implementation is separated from the aspect of parallelization (e.g. by converting procedure calls into remote method invocations). This separation of concerns consists of three phases: 1. Identification - Core and crosscutting concerns are identified. 2. Separation - Identified concerns are implemented and rules are defined how to assemble these concerns. In this phase core concerns are implemented as conventional components, while crosscutting concerns are implemented as aspects. 3. Integration - The system is assembled according to the earlier specified rules. Aspect-orientation now aims at delaying this phase. Even an integration during runtime can be achieved (by means of dynamic weaving). A possibility to identify crosscutting concerns is accomplished by distinguishing between the essence and the incarnation of a system [15]. The essence of a system is constituted by its true requirements and properties, which would exist even if there was perfect technology at hand. The incarnation of a system in contrast is the sum of all persons and machines realizing the essence. Both differ only because of the lack of perfect technology. The language extension to Java used to implement the framework is AspectJ. The main concepts it provides are join point, pointcut, advice and introduction. While join points are well-defined points in the control flow, advices are pieces of code to be executed when pointcuts apply. Pointcuts allow the abstract declaration of sets of join points. They can include calls to methods complying with a specified (abstract) signature. Introductions statically extend the signature of dedicated classes by adding fields or

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

methods. In AspectJ an aspect as a language construct represents the encapsulation of one or more of the described code elements. These (AspectJ) aspects represent the assembly rules used to combine the (conventionally implemented) modules. When adapting a concern to a new environment only these rules have to be changed while maintaining the basic functionality of the corresponding module. In the following we describe how one can achieve multidimensional decomposition through applying these concepts on parallel discrete optimization.

4.3. Concerns of Parallel Discrete Optimization The first or core concern of the system is heuristic search. Using the aspect-oriented paradigm enables us to implement this in a straight-forward way without wasting one thought on parallelization or having later to change already implemented source code, when considering necessities resulting from parallelization. When these are taken into account, one can identify the following concerns. They qualify as prime examples for crosscutting behavior and can be more efficiently modularized through adopting aspect-orientation than when applying conventional objectoriented decomposition. • Load Balancing - Dynamic balancing of workload is a first example of a crosscutting concern whose necessity results from the inability of a single processor, even if of supercomputer-level, to solve the problem in acceptable time, in other words: out of the nonexistence of perfect technology. In this context workload is represented by the content of the agenda on different hosts (grid nodes), which in turn is composed of the nodes constituting the search frontier. • Termination Detection - Another concern to be addressed in this context is detection of the termination of a parallel computation. This requirement arises out of the distribution of workload whose computational effort is uncertain. • Fault Tolerance - Fault tolerance is another issue resulting from the lack of perfect technology. In this context fault tolerance is restricted to losses of remotely handled workload caused by persisting host malfunctions. Transient failures are covered by the failure detection of the underlying Cohesion platform. • Distributed coordination - A basic necessity for realizing distributed applications lies in providing functionality to coordinate concurrent control flows on different hosts. This module leverages Cohesion to exchange messages.

4.4. Load Balancing To meet the demand for the dynamic balancing of workload we introduce the concept of generic dynamic balance. The corresponding framework is capable of balancing arbitrary user-defined attributes of distributed systems and is not restricted to balancing workload. It enables different balancing schemes, which can be applied to single (meta-) objects. These objects are assumed to contain other (exchangeable) objects, e.g. the nodes of the search frontier of a graph. The framework allows for the specification of arbitrary norms, which can be applied to sets of local (exchangeable) objects. Estimation of workload is just one example. Other properties modelled are constraints triggering discrete balancing actions (e.g. an empty agenda), the order in which the corresponding host is chosen (e.g. random, round robin [11]) and the manner in which a concrete balancing action is carried out. The constraints are reviewed regularly. If they apply, the balancing module chooses a neighbour from the set of known hosts. Balancing acts are then realized through interchanging exchangeable objects between the local host and the chosen neighbour using dedicated add- und removemethods of the object to be balanced. To ensure that the corresponding attribute is up-to-date, the module for dynamic balance attaches advice (through pointcuts) to calls to these add- and remove-methods. This way the module monitors all executions of respective methods, thus keeping the corresponding attribute up-to-date. One important feature of this approach is that the module for dynamic balance can be reused for similar necessities: e.g. to equally distribute solution quality over neighbouring hosts, when breadth-first searches like best-first are applied or to exchange individuals in distributed evolutionary algorithms. Reusability in this extent became only possible because the aspect-oriented design paradigm was applied.

4.5. Termination Detection To be able to detect distributed termination we employ a (modified) tree based termination detection algorithm. For this purpose every time a node is expanded, a counter is increased which holds the number of open (unvisited) nodes of the tree the node belongs to. Conversely, this counter is decreased every time a node has been closed (visited). When this counter reaches zero, the graph spanned when fully expanding the root node has been traversed. When a node has been received during load balancing, it is treated like a separate application with its own counter (and graph). When this counter reaches zero, the originating host is informed about the successful traversal of the node’s (sub-) graph, which in turn decreases the original counter. To en-

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

16 14 12

speedup

able this, multiple pointcuts are defined covering relevant join points. The latter contain the expanding or visiting of nodes, as well as balancing acts exchanging nodes between different hosts.

10 8 6

4.6. Fault Tolerance

4 2

4.7. Distributed Coordination To address communication and distributed coordination we designed a simple model incorporating so called distributed objects. In contrast to regular objects, distributed objects are assumed to be distributed in time and space, a requirement arising from the degree of workload to be handled. Distribution in space means the propagation of method calls to these objects on neighbouring hosts (visible to the host). Alternatively, this can be interpreted as a bundling of corresponding objects (e.g. singletons) on different hosts. Distribution in time then again means that object state persists after the termination of the JVM and objects are instantiated according to an earlier persisted state. The XMLserialization functionality, used to realize persistence, is also used to serialize object-encapsulated remote procedure calls (the method calls to be propagated). The obtained representation is in turn injected into SOAP-messages employed by the underlying Cohesion platform. Distribution is declared through attaching annotations (metadata) to dedicated methods. The corresponding introductions (see Section 4.2) are encapsulated in (AspectJ) aspects, while pointcuts are defined intercepting and propagating calls to methods bearing these annotations. The set of hosts on which these method calls are propagated, adapts dynamically to the set of neighbouring hosts, thus addressing the high volatility prevailing in Desktop Grids. This approach is supported by the functionality supplied by the Cohesion platform. Especially the group abstraction is used to define coordinates in host space for propagating method calls. Through providing these groups and associated endpoints or views the platform efficiently enabled the superimposition of a distributed object model overlaying arbitrary Desktop Grid infrastructures.

10 h

0 1

2

1h 4

nodes

8

12

5 min 16

seq run uent tim ial e

The module for fault tolerance keeps track of dispatched workload by intercepting balancing acts through pointcuts. To be able to re-instantiate lost workload, proxies are created every time a node is to be remotely handled. These proxies can then be used to recreate associated workload when it is assumed to be lost (the host holding the workload is presumed to have gone permanently offline). For this purpose every host monitors communication (through pointcutting communication acts) with hosts he has given over workload.

Figure 2. Performance on Dedicated Cluster

5. Performance Evaluation We carried out performance measurements in two different settings employing a branch-and-bound approach to solve randomly generated travelling salesman problems. In the first setting, we conducted micro studies in the controlled environment of a dedicated cluster. This allows us to check whether significant speedups are possible at all. In the second setting we performed tests in an authentic Desktop Grid environment, aggregating resources from multiple separate network segments. Microstudy on a Dedicated Cluster. Our cluster consists of 16 nodes (2.6 GHz Xeon CPU, 2 GB main memory) connected by a 100 Mbps Ethernet network. To keep local attributes (see Section 4.4) consistent, we employed a balancing scheme with frequent mutual inter-node update operations. As Figure 2 shows, we achieve significant speedups. For larger problem instances speedups are linear in the number of nodes. Live Test in a Desktop Grid. Our Desktop Grid testbed consists of 64 nodes of various platforms (see Figure 3). We conducted our performance tests in two different configurations: While the first contained all available hosts, the cluster nodes were omitted for the second. This reduced heterogeneity with respect to clock speeds. Because of the strict security policy of our department, the underlying network is highly segmented. Hence, all traffic between segments has to be relayed by a central JXTA super peer, which inescapably becomes a bottleneck on high inter-segment traffic. Therefore, we employed a round robin work-stealing scheme with significantly reduced communication overhead. Furthermore, the aspect of fault tolerance (see Section 4.6) is of particular importance, because message losses are now possible when there is a message queue overflow on the central relay node. Nevertheless, as depicted in Figure 4 it was possible to achieve speedups even for small to medium-sized problems.

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

1x Super Peer

24x Edge Peer Suse Linux 1.7 GHz Intel Celeron 256 MB RAM

100 MBit Ethernet

100 MBit Ethernet

Solaris 9 4 x 450 MHz UltraSPARC II 4 GB RAM

TCP/IP Firewall

... HTTP

HTTP HTTP Proxy Server

24x Edge Peer Solaris 8 500 MHz UltraSPARC IIe 512 MB RAM

...

15x Edge Peer

Firewall Router (NAT) 100 MBit Ethernet

Generic Linux 2 .6 GHz Intel Xeon 2 GB RAM

...

100 MBit Ethernet

TCP/IP

TCP/IP

Figure 3. Desktop Grid Setup #Nodes n tp [min] Speedup Efficiency [%] #Nodes n tp [min] Speedup Efficiency [%]

1 (= ts )

16

32

64

73.97 1.00 100

6.59 11.22 70

8.07 9.17 29

5.49 13.48 21

1 (= ts )

16

32

48

73.97 1.00 100

16.05 4.61 29

11.05 6.70 21

12.10 6.11 10

Figure 4. Performance on Desktop Grid

6. Conclusion In this paper we reported on our extensible Desktop Grid platform Cohesion and demonstrated its application in the light of an aspect-oriented framework for parallel discrete optimization. The main contribution of our work is to broaden the application scope of the Desktop Grid approach by enabling a comprehensive class of irregular task-parallel problems. While requiring more complex interaction capabilities than embarrassingly parallel problems, such taskparallel applications exhibit a certain degree of insensitivity to heterogeneity and volatility. Other prominent application classes (e.g. data-parallel or SPMD iterative methods) don’t naturally show these properties. An important question for future research will be whether it is possible to completely compensate such deficiencies on the parallel system and/or programming model level or whether fundamentally new parallel formulations for these problems have to be found first.

References [1] OSGi Service Platform, Release 3. http://www.osgi.org. Open Service Gateway Initiative. [2] K. P. Birman, M. Hayden, O. Ozkasap, Z. Xiao, M. Budiu, and Y. Minsky. Bimodal Multicast. ACM Trans. Comput. Syst., 17(2):41–88, 1999.

[3] W. Blochinger, C. Sinz, and W. K¨uchlin. Parallel propositional satisfiability checking with distributed dynamic learning. Parallel Computing, 29(7):969–994, 2003. [4] W. Blochinger, W. Westje, W. K¨uchlin, and S. Wedeniwski. ZetaSAT – Boolean satisfiability solving on desktop grids. In Proc. of the IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2005), Cardiff, UK, 2005. [5] Boinc. http://boinc.ssl.berkeley.edu. [6] A. Das, I. Gupta, and A. Motivala. SWIM: Scalable Weaklyconsistent Infection-style Process Group Membership Protocol. In Proceedings of the International Conference on Dependable Systems and Networks (DSN 2002), 23-26 June 2002, Bethesda, MD, USA, pages 303–312. IEEE Computer Society, June 2002. [7] Entropia DCGrid. http://www.entropia.com. [8] G. Fedak, C. Germain, V. Nri, and F. Cappello. XtremWeb: A generic global computing system. In IEEE Intl. Symp. on Cluster Computing and the Grid, CCGRID 2001, pages 582–587, Brisbane, Australia, 2001. [9] A. J. Ganesh, A.-M. Kermarrec, and L. Massouli. Peer-toPeer Membership Management for Gossip-based Protocols. IEEE Trans. Comput., 52(2):139–149, 2003. [10] L. Gong. Project JXTA: A Technology Overview. Technical report, Sun Microsystems, October 2002. [11] A. Grama and V. Kumar. State of the art in parallel search techniques for discrete optimization problems. IEEE Transactions on Knowledge and Data Engineering, 11(1):28–35, 1999. [12] United Devices GridMP. http://www.ud.com. [13] I. Gupta, T. D. Chandra, and G. S. Goldszmidt. On Scalable and Efficient Distributed Failure Detectors. In Proceedings of the twentieth annual ACM symposium on Principles of distributed computing, pages 170–179. ACM Press, 2001. [14] Y. T. Kazuyuki Shudo and S. Sekiguchi. P3: P2P-based middleware enabling transfer and aggregation of computational resources. In Proc. Cluster Computing and Grid 2005 (Fifth Int’l Workshop on Global and Peer-to-Peer Computing), Cardiff, UK, 2005. [15] S. M. McMenamin and J. F. Palmer. Essential systems analysis. Yourdon Press, Upper Saddle River, NJ, USA, 1984. [16] Platform LSF. http://www.platform.com. [17] B. Traversat, A. Arora, M. Abdelaziz, M. Duigou, C. Haywood, J.-C. Hugly, E. Pouyoul, and B. Yeager. Project JXTA 2.0 Super-Peer Virtual Network. Technical report, Sun Microsystems, May 2003. [18] R. V. van Nieuwpoort, J. Maassen, R. Hofman, T. Kielmann, and H. E. Bal. Ibis: an Efficient Java-based Grid Programming Environment. In Proceedings of the Joint ACM Java Grande - ISCOPE 2002 Conference, pages 18–27, Nov. 2002. [19] J. Verbeke, N. Nadgir, G. Ruetsch, and I. Sharapov. Framework for Peer-to-Peer Distributed Computing in a Heterogeneous, Decentralized Environment. In Proceedings of the Third International Workshop on Grid Computing (GRID ’02), pages 1–12, London, UK, 2002. Springer-Verlag. [20] ZetaGrid. http://www.zetagrid.net.

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE