180 likes | 275 Views
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
E N D
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 • 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
Outline • LSA • LOGGING • CMW/RDA • JAPC • RBAC • FESA • TIMING
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
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
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
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
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
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
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
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
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
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
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
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 projectsFebruary’14 • Afterthatdate, oldprojectsREMOVED from PCROPSrepository W.Sliwinski
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
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
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