performance analysis of a grid-based instrumentation device farm

Performance analysis of a Grid-based Instrumentation Device Farm

Performance analysis of a Grid-based Instrumentation Device Farm

Luca Berruti1, Franco Davoli1,

Stefano Vignola1, Sandro Zappatore1

1CNIT – University of Genoa Research Unit,Via Opera Pia 13, 16145 Genova, Italy

e-mail: {luca.berruti, franco.davoli, stefano.vignola, sandro.zappatore}@cnit.it

Luca Berruti1, Franco Davoli1,

Stefano Vignola1, Sandro Zappatore1

1CNIT – University of Genoa Research Unit,Via Opera Pia 13, 16145 Genova, Italy

e-mail: {luca.berruti, franco.davoli, stefano.vignola, sandro.zappatore}@cnit.it

INGRID2008 – Ischia – Italy, April 11thINGRID2008 – Ischia – Italy, April 11th

The FrameworkTo develop a GRID based platform (named Device Farm) for the remote access and control of

distributed real laboratories for telecomunication testing

•Research

•Education

•Industry R&D

The aim is to offer access to physical resources for several applications, for instance


The GRIDCC projectThe GRIDCC project

The GRIDCC (Grid enabled Remote Instrumentation with Distributed Control and Computation) project was aimed at extending Grid technology to the real-time access and control of instrumentation.

CNIT investigated the use of GRIDDCC framework to remotely control a set of instruments (Device Farm) for measurements on telecommunication systems.

The GRIDCC (Grid enabled Remote Instrumentation with Distributed Control and Computation) project was aimed at extending Grid technology to the real-time access and control of instrumentation.

CNIT investigated the use of GRIDDCC framework to remotely control a set of instruments (Device Farm) for measurements on telecommunication systems.


Why a Grid-based architectureWhy a Grid-based architecture

Reliability

Security

Accessibility

High Speed when moving Signals and Controls

Web-Services(WSDL, SOAP, XML, HTTP)

Dedicated Architecture forData Exchange


The Device Farm within the GRIDCCThe Device Farm within the GRIDCC


Virtual Instrument Grid Service (VIGS)

ResourceService

Inf & MonService

ProblemSolver

InstrumentManager

Instrument Element

Data Mover

IMSProxy

ControlManager

DataCollector

Acc

ess

Co

ntr

ol M

an

ag

er

execute()

getState()

create()

destroy()

InputManager

EventProcessor

FSMEngine

ResourceProxy

Control Manager

Virtual Instrument Grid Service (VIGS)

ResourceService

Inf & MonService

ProblemSolver

InstrumentManager

Instrument Element

Data Mover

IMSProxy

ControlManager

DataCollector

Acc

ess

Co

ntr

ol M

an

ag

er

Acc

ess

Co

ntr

ol M

an

ag

er

execute()

getState()

create()

destroy()

InputManager

EventProcessor

FSMEngine

ResourceProxy

Control Manager

InputManager

EventProcessor

FSMEngine

ResourceProxy

Control Manager

Instrument Driver

Device Device Device

IAL

The GRIDCC Instrument Framework


Each Device in the Farm is identified by a set of variables, which can be written and read.

These variables are handled by a proper software layer (Instrument Abstraction Layer - IAL, offering an Instrument Abstraction Service - IAS), written in Java.

The IAL implements a set of methods for reading/writing the variables, for connecting/releasing the Device, and so on.

In this way, the IAS acts as an interface between the Device Driver and the application using the specific Device.

Each Device in the Farm is identified by a set of variables, which can be written and read.

These variables are handled by a proper software layer (Instrument Abstraction Layer - IAL, offering an Instrument Abstraction Service - IAS), written in Java.

The IAL implements a set of methods for reading/writing the variables, for connecting/releasing the Device, and so on.

In this way, the IAS acts as an interface between the Device Driver and the application using the specific Device.

The Device Farm within the GRIDCCThe Device Farm within the GRIDCC


The VCR – IE communication (1)

Initialization Phase

The user issues a series of commands to properly set all the physical components involved in the experiment.

Each command is set to the IE by invoking several Remote Procedure Calls (RPCs) provided by the Web Services associated to the IE.

The IE returns the status of the IE and/or an array of variables associated to the instruments controlled by the IE.


The VCR – IE communication (2)Actual Measuring PhaseThe IE has to (periodically) return the user an array of variables containing the data gathered (i.e. a trace of an oscilloscope). Two data exchange modes.

In-band mode

The user issues a command (via a XML-SOAP RPC) in order to get the variables that must be monitored.

the proper formatting of the command into a XML message addressed to the IE Web Service the actual transmission of such a packet to the IE Web Service Engine end-point the reception, upon completion of the command at the IE, of the XML response message the decoding/disassembling of the message that carries the result of the command issued.



Actual Measuring Phase

Out-of-band mode

The user sends a command to the IE in order to subscribe to the reception of a group of data (i.e., an array of variables) from a certain device.

The IM controlling the device opens a channel toward a dispatcher (a broker in JMS terminology)

The IE communicates back to the user a sort of “locator” that specifies the channel used by the dispatcher

At the user end, an user Applet connects (subscribes) to the dispatcher at the specified “locator” to automatically receive data whenever they are released by the instrument.



Out-of-band mode


IE Performance evaluationIE Performance evaluation

Goal:To evaluate the performance of data delivery via the JMS in the Device Farm case Specifically, we want to estimate:• how many clients the system can serve at the same time;

• the time spent to receive a specific array of variables

Finally, we want to compare the results with those achievable without the use of the JMS (in-band communication case)


Performance Test Set-upPerformance Test Set-up

•PCs: Fujitsu-Siemens Scenico AMD-Athlon 2.14 GHz•Switch: CISCO – Catalyst 2900 – 24 Fast Ethernet ports•OS: Windows XP professional –sp2 •JMS: Sun - jmq 3.5 sp2

Virtual Instrument continuously sends data (viz. arrays) to the JMS topic as fast as possible.

1st set of testsEach array consists of 2500 doubles

2nd set of testsArray size is set to 5000, 10000, 20000, and 40000 doubles


Results (1)Results (1)

5 10 15 20 250

5

10

15

20

25Measure I Measure II Measure III Mean measure

Active client stations

Inte

r-a

rriv

al t

ime

[ms]

Behavior of the inter-arrival time for different numbers of active client stations (JMS broker).



Behavior of the Response Time for different numbers of active client stations (IE polling – In-band mode).

5 10 15 20 250

1000

2000

3000

4000

5000

6000

Measure I Measure II Measure III Mean measure


Res

pons

e tim

e [m

s]



Behavior of the inter-arrival time vs the number of active client stations at different levels of payload (JMS in use)

5 10 15 20 250

50

100

150

200

250

300

5000 10000 20000 40000


Inte

r-a

rriv

al t

ime

[m

s]


ConclusionsConclusions

•In applications involving remote instrumentation, a Device Farm, data must be frequently collected from the field and displayed on the user client stations (for instance, the traces of an oscilloscope) .

• The problem of dispatching arrays of variables becomes more relevant whenever numerous clients are monitoring the variables.

• A possible solution to the problem is to equip the IE with a subsystem that can provide a publish/subscribe data transfer mechanism.

• Within the GRIDDCC framework, the use of a JMS can strongly improve the overall performance of the entire framework

performance analysis of a grid-based instrumentation device farm

Documents

set of instruments device

set of variables

control of instrumentation

specific device

device driver

distributed control

array of variables

remote instrumentation