Presentation is loading. Please wait.

Presentation is loading. Please wait.

“Port Monitor”: progress & open questions Torsten Wilde and James Kohl Oak Ridge National Laboratory CCA Forum Quarterly Meeting Santa Fe, NM ~ October.

Similar presentations


Presentation on theme: "“Port Monitor”: progress & open questions Torsten Wilde and James Kohl Oak Ridge National Laboratory CCA Forum Quarterly Meeting Santa Fe, NM ~ October."— Presentation transcript:

1 “Port Monitor”: progress & open questions Torsten Wilde and James Kohl Oak Ridge National Laboratory CCA Forum Quarterly Meeting Santa Fe, NM ~ October 2003 Research supported by the Mathematics, Information and Computational Sciences Office, Office of Advanced Scientific Computing Research, U.S. Department of Energy, under contract No. DE-AC05-00OR22725 with UT-Battelle, LLC.

2 1 Quick Comments 1Or MY FIRST REAL CCA/CCAFE EXPOSURE 1Create a simple component application with PortMonitor from scratch 1Using a very simple getSum (A+B=C) component 1Built a PortMonitor for the getSum port and plug-in-pray 1Starting with an object oriented application 1Converting the object design step by step into a component design to get the feel of what is needed 1No problem installing CCA stuff on Mandrake (after fixing configure errors by hand in Babel & Ccafe) 1using sources (configure with prefix’s like rpm installations) 1and ‘make install’

3 2 Quick Comments 1Difficult to start a CCA application project from scratch 1Necessary information is distributed over a lot of documentation and guides 1A short compilation of steps and operations is needed 1Hard to choose the appropriate source tree & install structure for the project 1Maybe a standard is needed? 1A lot of support structure has to be built from scratch 1Scripts for building code from sidl files in appropriate locations 1Macros for finding other stuff (depending on the chosen file dependencies and install structure) 1Build structure, including configure- & Make-files

4 3 More Comments 1Using Automake, Autoconf, Libtools & Autoheader makes building & maintaining really easy (for a new component/application) 1That’s why a well defined build and install structure is needed 1Shared library dependencies are hell 1Trade-off shared library efficiency (resource usage) for software build complexity 1Using too many makes it hard to keep track of and hard to make work correctly 1Define what is installed from whom in a standard distribution 1Eg. Babel XML repository, ccafe XML repository 1Client side sidl file and/or libraries 1Tutorial examples are currently restructured by Wael & Boyana 1Having an experienced component guy available helps a lot as well (thank you Wael )

5 4 Potential Install Tree Structure 1 1CCA/ 1Ports repository 1Components repository 1Port Monitor repository 1Application repository 1Libs 1Cca-ports 1Port client libs 1Includes 1Cca-ports 1Port header files dependency structure ports Components need port definition Port monitors need port definition Applications use components & portmonitors

6 5 Potential Install Tree Structure 2 1Ports repository 1Xml port repository 1Port 1 dir 1 … 1 Port N dir 1Port sidl file 1Components 1Component 1 dir 1 … 1Component N dir 1Component library 1Component cca file

7 6 Potential Install Tree Structure 3 1Port Monitor repository 1Port monitor 1 dir 1 … 1Port monitor N dir 1Port monitor library 1Port monitor cca file 1Application repository 1Application 1 dir 1 … 1Application N dir 1Ccafe scripts 1Application driver 1Driver cca file 1Driver libraries

8 7 Trivial Component Application 1Simple calculation of the sum of two integer inputs

9 8 Ccafe Output 1Hey, 0+0=0 what a blast

10 9 Component Application With PortMonitor 1With added PortMonitor component (custom-designed for port)

11 10 Ccafe Output 1Cool, 0+0 is still 0 (PortMonitor didn’t break anything )

12 11 Next Functionality Priority List – Part1 1Needed functionality (priority can be discussed): 1Writing port invocation trace files 1Error analysis, port invocation replay & replay with different input values 1Creating standard input format for black-box testing 1Interface with the port monitor component for interactive functionality 1Use GUI component inside or outside the component framework 1But what to do in batch mode? 1Communicate with user GUI via communication port, outside the scope of the component framework

13 12 Next Functionality Priority List – Part2 1Providing user input for: 1Toggling trace file generation (even selecting what to save in file) 1Selecting what to monitor (specific function calls on a port, which ports …) 1Toggling lock-step functionality 1Changing input parameter before resuming execution 1How to support debugging better? 1Start extern debugger when entering suspicious component 1How to automatically pause code for debugger attachment?

14 13 Action list – Feedback appreciated 1Selecting trace file storage format 1Good to select an established format that allows use of existing tools for analysis 1Storage requirements (compression) depend on application size, frequency of invocation and amount of data transferred via port calls 1Dynamically choose to store big data packed (increased complexity) 1Readable & editable for parameter changes (Ascii vs. binary) 1Trace similar to performance trace 1Maybe TAU provides a good starting point 1Might switch to Vampire format (Epilog)

15 14 Action list – Feedback appreciated 1Serializing ports 1Support passing of objects via port method invocation 1Needs support from port or object itself 1Get_serialized_me method 1Set_serialized_me method


Download ppt "“Port Monitor”: progress & open questions Torsten Wilde and James Kohl Oak Ridge National Laboratory CCA Forum Quarterly Meeting Santa Fe, NM ~ October."

Similar presentations


Ads by Google