1. Performance analysis of a Grid-based Instrumentation Device Farm Luca Berruti 1, Franco Davoli 1, Stefano Vignola 1, Sandro Zappatore 1 1 CNIT – University of Genoa Research Unit, Via Opera Pia 13, 16145 Genova, Italy e-mail: {luca.berruti, franco.davoli, stefano.vignola, sandro.zappatore}@cnit.it

2. INGRID2008 – Ischia – Italy, April 11 th The Framework To 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

3. INGRID2008 – Ischia – Italy, April 11 th The 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.

4. INGRID2008 – Ischia – Italy, April 11 th Why a Grid-based architecture Reliability Security Accessibility High Speed when moving Signals and Controls Web-Services (WSDL, SOAP, XML, HTTP) Dedicated Architecture for Data Exchange

5. INGRID2008 – Ischia – Italy, April 11 th The Device Farm within the GRIDCC

6. INGRID2008 – Ischia – Italy, April 11 th VirtualInstrumentGridService(VIGS) Resource Service Inf& Mon Service Problem Solver Instrument Manager Instrument Element Data Mover IMS Proxy Control Manager Data Collector Access Control Manager execute() getState() create() destroy() Input Manager Event Processor FSM Engine Resource Proxy Control Manager VirtualInstrumentGridService(VIGS) Resource Service Inf& Mon Service Problem Solver Instrument Manager Instrument Element Data Mover IMS Proxy Control Manager Data Collector Access Control Manager execute() getState() create() destroy() Input Manager Event Processor FSM Engine Resource Proxy Control Manager Input Manager Event Processor FSM Engine Resource Proxy Control Manager Instrument Driver Device IAL The GRIDCC Instrument Framework

7. INGRID2008 – Ischia – Italy, April 11 th  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 GRIDCC

8. INGRID2008 – Ischia – Italy, April 11 th 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.

9. INGRID2008 – Ischia – Italy, April 11 th The VCR – IE communication (2) Actual Measuring Phase The 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.

10. INGRID2008 – Ischia – Italy, April 11 th The VCR – IE communication (3) 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.

11. INGRID2008 – Ischia – Italy, April 11 th The VCR – IE communication (4) Out-of-band mode

12. INGRID2008 – Ischia – Italy, April 11 th IE 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)

13. INGRID2008 – Ischia – Italy, April 11 th Performance 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. 1 st set of tests Each array consists of 2500 doubles 2 nd set of tests Array size is set to 5000, 10000, 20000, and 40000 doubles

14. INGRID2008 – Ischia – Italy, April 11 th Results (1) Behavior of the inter-arrival time for different numbers of active client stations (JMS broker).

15. INGRID2008 – Ischia – Italy, April 11 th Results (2) Behavior of the Response Time for different numbers of active client stations (IE polling – In-band mode).

16. INGRID2008 – Ischia – Italy, April 11 th Results (3) Behavior of the inter-arrival time vs the number of active client stations at different levels of payload (JMS in use)

17. INGRID2008 – Ischia – Italy, April 11 th Conclusions 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