1 / 17

Performance analysis of a Grid-based Instrumentation Device Farm

Performance analysis of a Grid-based Instrumentation Device Farm.

haley
Download Presentation

Performance analysis of a Grid-based Instrumentation Device Farm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Performance analysis of a Grid-based Instrumentation Device Farm Luca Berruti1,Franco Davoli1, Stefano Vignola1, Sandro Zappatore11CNIT – University of Genoa Research Unit,Via Opera Pia 13, 16145 Genova, Italye-mail: {luca.berruti, franco.davoli, stefano.vignola, sandro.zappatore}@cnit.it

  2. The Framework To develop a GRID based platform (named Device Farm) for the remote access and control of distributedreallaboratoriesfor telecomunication testing The aim is to offer access to physical resources for several applications, for instance • Research • Education • Industry R&D INGRID2008 – Ischia – Italy, April 11th

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

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

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

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

  7. The Device Farm within the GRIDCC • 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. INGRID2008 – Ischia – Italy, April 11th

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

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

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

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

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

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

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

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

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

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

More Related