1 / 18

Changes in LSA and related projects during LS1

G.Kruk on behalf the LSA team, D.Romano , C.Roderick , W.Sliwinski , S.Deghaye , J.C.Bau. Changes in LSA and related projects during LS1. Introduction. Focus of this presentation is on LHC-related changes in LSA and on “associated” CO projects/libraries

toyah
Download Presentation

Changes in LSA and related projects during LS1

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. G.Kruk on behalf the LSA team, D.Romano, C.Roderick, W.Sliwinski, S.Deghaye, J.C.Bau Changes in LSA and related projects during LS1

  2. Introduction • Focus of this presentation is on LHC-related changes in LSA and on “associated” CO projects/libraries • Even if not mentioned here, most CO services will introduce changes • Backwards compatible and/or internal so no action required from users • Releases will be announced on dedicated mailing lists

  3. Outline • LSA • LOGGING • CMW/RDA • JAPC • RBAC • FESA • TIMING

  4. Changes in LSA APIs • Why to change? • The API was growing over the last 10 years, initially based on SPS and LHC, later incorporated requirements from Injectors (InCA) • LS1 – time to clean up • Hard to introduce new functionality in some cases • Extract common concepts into a generic module (in accsoft) for re-use • Accelerator, Accelerator Mode, Beam, etc. • Profit from latest Java features and new programming concepts • Make the API cleaner (uniform) and simpler to use • Non-backward compatible change • LSA API users need to adapt their applications • Upgrade Plan • Release Candidate (NEXT): late Q3 2013 for early adopters • Release as PRO: toward the end of 2013 G.Kruk

  5. LSA Database Performance Issues • In 2011 and 2012 – several reports about poor performance • Operations involving heavy access to settings • Several reasons • Rapidly growing volume of settings (doubled over 2012) • More clients (PS, PSB, ISOLDE) • Some applications need latest settings for calculations • Reading many settings with relatively high frequency • or scanning historical settings of many beam processes • .. and causing eviction of other settings from the RAM cache • We improved the situation by • Putting in place a mechanism to avoid pulling settings by client applications • Tuning the database • Further optimizations of SQL queries • But we started to hit hardware limits • Disc I/O due to insufficient RAM cache G.Kruk, C.Roderick

  6. LSA Database Data Volumes • LS1 – time to clean up unused settings • ~130 GB of data in total (~60 GB in 2011) • where ~110 GB  settings (~50 GB in 2011) • Number of LHC Beam Processes • 473 Function + 3690 Actual + 16 Discrete = 4179 • Number of SPS contexts • 189 Cycles + 32 Super Cycles (obsolete?) G.Kruk, C.Roderick

  7. LSA Database Hardware Upgrade • Today • Hardware (from March 2008): CPU 2.27 GHz, 2 Cores, 16 GB RAM • Disc: Fast HDD (15K RPM) but without flash cache • End of 2013 • End of Life for the existing hardware • New Hardware: CPU 2.8 GHz, 16 Cores, 128 GB RAM • Disc: Fast HDD with 300 GB flash cache • If we clean up the data – whole database would fit in the RAM • Flash 1.000 x faster than HDD • RAM 100.000 x faster than HDD • The regeneration should be then terribly fast • If not, we still have a plan B G.Kruk, C.Roderick

  8. LSA Applications Improvements • Today • Several different applications to deal with settings • Generation, Trim Editor, Actual Trim, Settings Compare, Copy, Drive, etc. • Often hard to find the necessary functionality • Especially for new users • After LS1 • Unify these applications into one • One application (access point) for all settings-related operations • With some long waited improvements and goodies • Improvements in other applications if time allows (during 2014) • E.g. EquipState G.Kruk, D.Romano

  9. Logging Service: What will change? • SDDS will disappear from the Logging Service during LS1 • Existing data will be preserved on a case-by-case basis Later Now NFS SDDS API MDB API MDB API Logging Client Process Logging Client JAPC Monitoring JAPC Monitoring C.Roderick

  10. Logging Service: Why? • Significant Maintenance Overhead: • 2 logging solutions • 2 sets of Java products for read / write / visualization • 2 distinct infrastructure services (IT/DB + BE/CO/IN) • Huge Number of Distinct Files • Technical challenge to manage / back-up SDDS files • Functionality limitations • 1 file per acquisition ⇒ difficult to analyze over time / correlate with other signals C.Roderick

  11. Logging Service: Impact • Applications will need to switch data extraction API: • Extension of existing logging-data-extractor-clientAPI • will support return of JAPC ParameterValue • Ready late Q3 2013 • Migration to be completed before end February 2014 • Data owners will be contacted where applicable (during Q3 2013) regarding preservation of existing data C.Roderick

  12. Middleware Upgrade in LS1 • Why to upgrade ? • Replace CORBA-basedcommunicationlibrary • Becamelegacy, not activelysupported maintenanceissue • Major technicallimitations, e.g. blockingcommunication • Outstanding OP issues • No protectionagainst’slow/bad’clientapplications • Poorscalabilitywhenmanyclientssubscribed • Missing support for priorityclients (e.g. SIS, PM, InCA) • + others … • Upgrade Plan(tentative) • Convention: RDA2 (OLD)  RDA3 (NEW) • Integration of RDA3 with JAPC (summer’13) • Integration of RDA3 with FESA3, FGC & PVSS (autumn’13) • Validation & testing of MW with Eqp. groups (winter’13/14) • Operational deployment in 2014 (e.g. FESA3 classes) W.Sliwinski

  13. Changes in RDA • New major version: RDA3 (summer’13) • Public API NOT backward compatible • New protocol, new architecture, new design • Same device/property model & Get/Set/Subscribe calls • Note: FESA2.10 stays with RDA2, FESA3 will use RDA3 (end of 2013) • RequiredActions for RDA Users • For Java: Use new version of JAPC • For Java: New JAPC will support communication with RDA2 & RDA3 servers • For C++: Upgrade user code to new RDA3 API • For C++: RDA3 will support communication with RDA2 & RDA3 servers • Consequences if NO Action staying with old RDA2 • NOT possible to communicate with new RDA3 servers (FESA3, FGC, etc.) • NOTpossible to perform Get/Set/Subscribe on RDA3 servers W.Sliwinski

  14. Changes in JAPC • New major JAPC version  upgrade for RDA3 (summer’13) • Public API backward compatible • Possible API extensions, but always compatible • Extensions requested by other projects (InCA/LSA, JMON) • Public API backward compatible • RequiredActions for JAPC Users • Update JAPC jars and re-release your product • New JAPC will support communication with RDA2 & RDA3 servers • Consequences if NO Action  staying with old JAPC & RDA2 • NOT possible to communicate with new RDA3 servers (FESA3, FGC, etc.) • NOTpossible to perform Get/Set/Subscribe on RDA3 servers W.Sliwinski

  15. Changes in RBAC • Rename of RBAC Java projects (summer’13) • NOT backward compatible change • Change of package names  different imports • Old projects deprecated • + clean-up of deprecated API (methods) • Required Actions for RBAC Users • Update dependencies, update imports in the code and re-release • Consequences if NO Action • End-of-life for old RBAC Java projectsFebruary’14 • Afterthatdate, oldprojectsREMOVED from PCROPSrepository W.Sliwinski

  16. FESA Roadmap 2013 • Feb’13: FESA 3.0.9 for early adopters (~20 classes) • Jul’13: FESA 3.1.0 released for 32 & 64 bits • Jul’13: Stop new developments with FESA2 • Jul’13: LTIM for FESA 3 available • Oct’13: FESA 3.2-RC with RDA3 for earlyadopters • Dec’13: FESA 3.2.0 with RDA3 as mainrelease S.Deghaye

  17. Changes in LHC TIMING • Change of a low-level protocol between LIC and LHC • Improvement to resolve problem detected in Nov’12 when a wrong LHC injection kicker fired • Change of the distribution mechanism of telegram data • DTMs replaced by RDA3 distribution mechanism • TGM Library still there but based on this new mechanism • Later, FESA class(es) will be provided to distribute dedicated timing information • New service • Two new Operational Modes will be added • To condition RBAC rules independently for CMS and ATLAS J.C.Bau

  18. Resources • BE/CO changes workshop (March’13): https://indico.cern.ch/conferenceDisplay.py?confId=242717 • Review of the Controls Middleware (June’13): https://indico.cern.ch/conferenceDisplay.py?confId=259755

More Related