1deb736de774809f041b28238f3d2e6d.ppt
- Количество слайдов: 14
The Ba. Bar Prompt Reconstruction Manager: a Real Life Example of a Constructive Approach to Software Development. Francesco Safai Tehrani Istituto Nazionale di Fisica Nucleare, Sezione di Roma. I for the Ba. Bar Prompt Reconstruction & Computing Groups CHEP 2000 7 -11 Feb 2000, Padova, Italy
The Prompt Reconstruction System l The software structure of the Ba. Bar experiment requires that all the incoming data get fully processed in less than 8 hours after the data taking. To obtain that the PR system requires: – a high degree of automation of the processing (automatic scheduling, fault tolerant system) – a system able to achieve a sustained processing rate of 100 Hz. Currently: peak ~55 Hz , the average processing rate can be much lower due to startup times, run length. . . FOR MORE INFO. . . http: //www. slac. stanford. edu/www/Computing/Online/Prompt. Reco/
The Prompt Reconstruction System (full view) PR Instance PR instance Farm CPU GFD GFM PRD PRF PRM PR Instance Farm CPU GFD GFM: Global Farm Manager PRM: Prompt Reco Manager GFD: Global Farm Daemon PRD: Prompt Reco Daemon PRF: Prompt Reco Framework PRD PRF
What is the PRM? l Prompt Reconstruction Manager Tasks: – Scheduling of jobs (user-request based or policy based) – Bookkeeping (Electronic logbook, Constants Block database) – User/GFM interface (simple command language interface) – Automated data retrieval (temporarily) – Multiple instances (to allow for parallel processing and reprocessing)
The Prompt Reconstruction System (PRM detailed view, current) PRM scheduler data retrieval server interface bookkeeping server “finalize” server Logging Manager GFD
The Necessity-driven Development Model l It is a response to various specific needs: – Fast prototyping: Þreliable working system on a short timescale. – Flexibility: Þability to adapt to ever-changing requests and to the lessons learned daily “on the field”. – Design: Þcoherence with OPR specifications. – Maintainability: Þeasy to maintain even though it contains parts written with different techniques/languages. – Reliability: Þrobust design technique.
Technology (I): OOAD & iterations l “relaxed” OOAD – – l use of well known analysis and design techniques patterns flexibility, reusability, robustness system evolution is simple and reliable migration to other OO languages (C++, Java) is simple “relaxed” iteration development model – iterations are a simple and powerful way to model the software development cycle but – we need to be able to change the requests for the current iteration as necessities arise fast response
Technology (II): the language l use of scripting languages – pre-existing core software: Bourne scripts – scripts allow rapid prototyping l use of PERL as scripting language PERL has several advantages: – it is Object Oriented, thus allowing for a natural extension of OOAD concepts – it is widely available and distributed under an Open Source license (GNU like) – it has high quality libraries (“modules”) that make it easy to implement powerful systems (OO Socket library, DBI Database Interface for SQL database…) – can be easily embedded in C++/Java code
Technology (III): interface layers l The PRM system behaves like a dynamic network of interacting “objects”: – message-exchange communication – complex behaviour: easy to modify l The communication between “objects” is realized through interface layers: – the implementation details are filtered at the interface level (i. e. the implementation language) – it is easy to “evolve” parts of the system without disrupting the existing (and working) one – it is easy to create “wrap” interfaces around existing scripts, integrating them seamlessly in the system
Technology (IV): the future l Communication layer: – current: TCP/IP – future: CORBA l Language evolution – current: PERL and Bourne scripts – future: C++/Java/PERL Dynamic resizing or partitioning of the processing farm l Better protection/recovery mechanisms (watchdogs, self healing software. . . ) l
An Example of Client-Server Interaction “local” query proxy network client server “remote” query l This architecture provides a high degree of isolation from the communication layer: – “smart” proxy efficient use of resources, abstraction – “painless” to switch from TCP/IP to CORBA – the proxy can be as “smart” as needed
Current Status of the PRM l l l It has been successfully “in production” since July 1999. It has proven to be robust and reliable, requiring little or no human intervention. Its flexible design adapts easily to ever-changing requests and fulfills the needs of the Online Prompt Reconstruction project. The watchdog is being implemented and will go in production soon. The multiple instance version of the PRM has been recently released and is being tested.
The current structure of the PRM scheduler data retrieval server interface bookkeeping server “finalize” server Logging Manager GFD
Some Data about Ba. Bar l Input data from DAQ: – ~30 KB/ev @ 100 Hz l Farm Architecture: – Sun Ultra 5 Sun T 1 – 100 -200 single CPU machines – 256 MB RAM – 100 Mb/s Ethernet – 2 4 Objectivity Server Sun E 450
1deb736de774809f041b28238f3d2e6d.ppt