1. Teamster-G : A Grid-enabled Software DSM System
Thank you, Mr. Chairman.
I am honored to be invited to give a talk here.
Taking advantage of this opportunity, I would like to thank Program Committee of this workshop.
And then let us enter the subject.
Today my topic is “Teamster-G: A Grid-enabled Software DSM System”.
Tyng-Yeu Liang, Chun-Yi Wu, Jyh-Biau Chang, Ce-Kuen Shieh
Department of Electrical Engineering, National Kaohsiung University of Applied Sciences
No.415, Chien-Kung Road, Kaohsiung, Taiwan, R.O.C
Department of Electrical Engineering, National Chung Kung University
No. 1, Ta-Hsueh Road, Tainan, Taiwan, R.O.C
{lty, smiler,andrew,

2. Outline Motivation of our research System architecture
Highlight data of performance evaluation
Summaries
I will first talk about the motivation of our research, then system architecture and highlight data of performance evaluation.
Time permitting, I will summarize my talk towards the end.

3. Motivation Providing users with an easy programming toolkit is an
important issue for grid computing.
Proposed solutions :
MPICH-G2 : message passing
GridRPC : remote procedure call
Java CoG : remote method invocation
However, the user interfaces provided by these toolkits are
not as easy and transparent for users than shared memory.
I believe that everybody knows to provide users with a familiar programming tool to develop applications is an important issue of grid computing.
(in order to enrich the kinds of grid-computing applications.)
Currently, there are many studies dedicated to enable MPI, Java or RPC for grid computing.
For example MPICH-G2 is a grid-enabled implementation of MPI.
Java CoG kits provides grid features to software developers using the Java programming language.
GridRPC is a remote procedure call API for grid computing.
However they are not as easy and transparent as distributed shared memory as we known.

4. Motivation The advantages of shared memory parallelism
natural to extend sequential programs to
distributed systems
transparent data distribution and communication
good scalability in system and program size
easy to adjust work distribution for load balance
And then let us see the advantages of share memory parallelism.
First, it is natural to extend sequential programs to distributed systems.
Second, it has transparent data distribution and communication.
Third, it has good scalability in system and program size.
Fourth, it is easy to adjust work distribution for load balance.

5. Motivation building a grid-enabled software DSM system
The aim of our work is to allowing users to develop
applications in the grid environment with shared
memory parallelism.
building a grid-enabled software DSM system
There are just a few works which have been done for enabling the use of software DSM systems in grid environment.
Although software DSM systems offer an easier programming user interface than others.
So we built a grid-enabled software DSM system it is called Teamster-G.

6. Teamster-G Teamster-G is a grid-enabled software DSM system developed
based on Teamster and Globus. This system is mainly aimed
to emulate a personal shared memory multiprocessor for user
applications in the grid environment.
Hardware : Intel 80x86 PCs and SMPs
Operating system : Redhat 9.0
Consistency : page-based and eager-updated
Programming interface : Pthread and OpenMP
Resource allocation : session-oriented and space sharing
It is built on Linux Red-hat 9.0 operating system and its hardware platform are an IBM PCs cluster and a SMPs cluster.
It supports multiple memory consistency protocols. i.e. sequential and eager released.
And it supports two kinds of programming interface. i.e. pthread and OpenMP.
Furthermore it uses a session-oriented and space sharing protocol in resource allocation.

7. System architecture TGrun TGRB
A interface for users to submit jobs and monitor program execution in grids
TGRB
A broker to allocate grid resource for users to execute their applications
TGCM
A manager to govern local resource in each cluster
Teamster-G consists of three main components.
These components are TG-run, Teamster-G resource broker for short TGRB and Teamster-G cluster manager for short TGCM.
Jobs of these components are described as follows…

8. Resource allocation
What I am showing here is the resource allocation in the framework of Teamster-G.
…show time
Finally there is a virtual dedicated cluster that is provided for user to execute his programs.

9. Program execution
What you can see here is operations of program executions.
Show time…

10. Performance evaluation
Experimental Configuration
Configuration
Cluster 1
4xPentiumIII500Mhz, 512MB
1xPentiumIII700Mhz,1024MB
1xXeron1.6Ghz,2048MB
100Mbps
Ethernet
Cluster 2
1xCeleron1.1Ghz,128MB
Communication between Cluster1&2 :
Bandwidth 6.5MB/s,
round trip time 44ms, 8 hops
We have evaluated the performance of Teamster-G in this work.
The configuration used for performance evaluation is listed in this table.

11. Performance evaluation
Application parameters
Problem size
CPU demand
Memory demand
SOR
2048x2048fp,200loops
sec
65536 KB
MPEG4
640x480, 60 frames
61.356sec
9052 KB
N-body
2400 particles
sec
131KB
Our benchmark applications are SOR, MPEG-4 and N-body.
The performance parameters of there applications are listed here…
Here we mainly concern about two things.
One is the cost of resource discovery and allocation.
And another is the performance of the test applications are spread over multiple clusters in Teamster-G.

12. Resource discovery cost
Query MDSs
1MDS
0.751sec
2MDSs
1.435sec
4MDSs
2.087sec
Query MDSs : 120records
Query resource pool in TGRB
sec
sec
for one cluster
sec
for two clusters
The experimental result shows that the cost of resource discovery is increased as well as the number of the queried MDSs.
And you can see that the pool of resource information in TGRB can effectively reduce the latency of resource discovery and selection.
Because TGRB has collected suitable resource information for DSM programs from MDSs in advance.

13. Application Performance
CASE I : Inside Cluster 1
n=1, 1xPIII500 ; n=2, 2xPIII500
n=4, 4xPIII500 ; n=6, 4xPIII500, PIII700, Xeron1.6G
SOR
n=1
N=2
n=4
n=6
Exec.time(sec)
94.547
48.625
speed up 1
1.920
3.734
5.497
data consistency
0.234
1.509
1.297
1.197
MPEG4
61.434
36.949
22.305
16.598
1.66
2.754
3.679
0.069
4.843
3.886
4.228
N-body
n=2
93.609
47.703
32.35
1.973
3.872
5.710
0.603
0.692
0.753
The work of the application in this case is distributed only in one cluster while the program threads are distributed across two cluster in another case.

14. Case II: spread Cluster 1&2 n=1, PIII500 ; n=2, PIII500+Celeron1.1G
n=4, 3xPIII500+Celeron1.1G; n=6, 4xPIII500, PIII700+Celeron1.1G
SOR
n=1
N=2
n=4
n=6
Exec.time(sec)
51.815
35.293
speed up 1
1.802
3.504
5.144
data consistency
0.234
5.691
2.674
1.860
Compare to Case I
-6.17%
-6.16%
-6.42%
MPEG4
61.434
48.7
27.037
20.487
1.259
2.27
2.99
0.069
12.278
6.046
5.5
-24.25%
-17.50%
-18.50%
N-body
Exe.time(sec)
95.152
49.028
33.147
1.941
3.768
5.57
0.0027
1.886
1.387
1.083
-1.62%
-2.70%
-2.39%
These are comparisons between case 1 and case 2.
It can be found that the latency of communication is significantly increased by the distance between cluster 1 and cluster2.
While it is acceptable except MPEG-4.
The main reason is the cost of maintaining data consistency in the AP of SOR and N-body is much smaller than the cost of data computation.
But MPGE-4 is opposite.

15. Conclusions
The resource pool of TGRB is effective to minimize the cost
of resource discovery.
Teamster-G can deliver an acceptable performance to user applications when data sharing is not heavy.
Distributing DSM programs onto multiple sites in wide area network unnecessarily cause the problem of huge data-consistency cost.
In summary, our experience shows that a grid-enabled
software DSM system can provide not only an easy
programming interface but also an acceptable performance
when load balance is achieved and data sharing is not heavy.
The important thing here is …

16. Future work OpenMP (finished) Load balancing (2nd.Q, 2005)
Reconfiguration (4th.Q, 2005)
Q.o.S (1st.Q, 2006)
Our work in this paper is only focused on the problem of resource allocation for the DSM applications in grids.
These are many other issues needed to be addressed such as …
My report leaves it at that