George Tsouloupas University of Cyprus Task 2.3 GridBench ● 1 st Year Targets ● Background ●...

George Tsouloupas University of Cyprus

Task 2.3 GridBench

● 1st Year Targets● Background● Prototype● Problems and Issues● What's Next


1st Year Targets

● Investigate benchmarking the grid– Existing benchmarking efforts and tools

● Consolidate our thoughts into a Requirements Document.

● Specify the GridBench architecture in a Design Document.

● Prototype Development– deployment testing


Background● Benchmark Hierarchies

Micro-benchmarks Micro-kernels Application Kernels

SITE gb_site_lmnetgb_site_mpbench

gb_site_hplgb_site_nas_isgb_site_nas_epgb_site_nas_ftgb_site_nas_btgb_site_nas_spgb_site_nas_lu

[Task1.1] Kernels[Task1.2] Kernels[Task1.3] Kernels[Task1.4] Kernels

GRID gb_grid_net gb_grid_lingb_grid_npb

gb_grid_cg


Background (design)

RB/LB Server CE

Portal Server

ClientApplet

ApplicationPlugin

GBAchiveR-GMADB

RB

LB

GBArchive

GBBMWrapper

MPI/other executable

GBControl

CE GBBMWrapper


GBControl

CE GBBMWrapper


GBControl

control/monitor

control/monitor

control/monitor

R-GMA flow

LB information

G-PM flow


Current Status

● Month 12 prototype in good shape– Code compiles and installs– RPM is close done (thanks to Christos!)

● Updated Design Document– Updated use case

● A better understanding of our platform, it's potential.


Choosing a prototype –Why HPL?

● It's targeted at measuring the performance of a single site.

● Simple input and output requirements. ● HPL is well known in the HPC community● Configuring and building HPL on our testbed was

supposed to be easy :)● HPL was chosen to be our champion benchmark

which would provide us with the experience of deploying benchmarks on the grid.


Month 12 Prototype● Implementation of a prototype benchmark that

runs on a local cluster. ● Benchmark gb_site_hpl will run on a cluster

that supports MPI. – Based on the High Performance Linpack benchmark.

● Alteration of HPL to accept XML input and produce XML output.

● Current cvs version builds and runs on testbed (requires minor changes including a revision of the input XML schema)


Month 12 Prototype

● Input of the benchmark is an XML document that specifies a number of parameters such as:– Problem size– Algorithm– Number of processes and data partitioning– Other tuning parameters

● Output of the benchmark is an estimate of floating point operations per second (FLOPS).


XML schema for Input<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="P"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="4"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Q"> <xs:simpleType> <xs:restriction base="xs:byte"> <xs:enumeration value="13"/> <xs:enumeration value="6"/> <xs:enumeration value="8"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:complexType name="bcastsType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="bcasts" type="bcastsType"/>

... </xs:choice> <xs:attribute name="num" type="xs:byte"/> </xs:complexType> <xs:complexType name="benchmarkType"> <xs:sequence> <xs:element ref="benchmarkName"/> <xs:element ref="description"/>

...

<xs:element name="parameters" type="parametersType"/> </xs:sequence> </xs:complexType> <xs:element name="benchmarkName" type="xs:string"/> <xs:element name="blockSizes" type="xs:integer"/> <xs:complexType name="depthsType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="depths" type="depthsType"/> </xs:choice> <xs:attribute name="num" type="xs:byte"/> </xs:complexType> <xs:element name="description" type="xs:string"/> <xs:element name="equilibration" type="xs:boolean"/> <xs:element name="executableName" type="xs:string"/> <xs:element name="gridbenchmark"> <xs:complexType> <xs:sequence> <xs:element name="benchmark" type="benchmarkType


Month 12 Prototype

● Dependencies: (for gb_site_hpl only!)– BLAS (provided by cernlib)– MPI

● Currently these are dependencies for building only. (Executable is statically linked)


Implementation / Integration problems and issues.

● Measurement depends on the efficiency of the underlying BLAS library– BLAS may not be optimized for the specific CPU (i386 Vs

P4 etc.) (May use statically linked optimized routines)

● moving target with respect to how things would run– user-space installation, CE installation, UI installation,...

● Lack of real support for MPI for job submission– Currently staging is partially manual

● Building on our platform was not as easy as expected.


What's next?1) Specifying & implementing more complex

(workflow-type) benchmarks– GGF Research Group (NGB)– Tools for specifying (JDL-DAGMan –EDG,

TRIANA –GRIDLAB)– Evolution of Design Doc

LaunchBT.

S MG.S FT.

S

Report

BT.S MG.

S FT.S

BT.S MG.

S FT.S

B.1

B.2

B.3

M.1

M.2

M.3

F.1

F.2

F.3


What's next?2) Extraction, Collection and Archival of

benchmark results– Integration with monitoring (through a G-PM API)– R-GMA (collection and archival)– MDS

3) Interpretation– Models– Tools– Metrics


Related Activities

● Investigation of Benchmarks● Functional Simulator for Processor Design

– Looking at real apps for deployment on the testbed and their use as application benchmarks

● Exploitation of other IST projects results and tools


ROADMAP

1)A detailed doc with specifications for each of the GridBench suite benchmarks outlined in the Design Document. (an Addendum?)

2)Employment of monitoring architectures for benchmark data collection (i.e. R-GMA and G-PM-based on API availability).

3)Specification of benchmark result encoding (XML) and archival

George Tsouloupas University of Cyprus Task 2.3 GridBench ● 1 st Year Targets ● Background ●...

Documents

Transcript of George Tsouloupas University of Cyprus Task 2.3 GridBench ● 1 st Year Targets ● Background ●...