Upload
toyah
View
19
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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
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 changesBackwards compatible and/or internal so no
action required from usersReleases will be announced on dedicated
mailing lists
30/07/2013
3
Outline
LSA LOGGING CMW/RDA JAPC RBAC FESA TIMING
30/07/2013
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
30/07/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
30/07/2013 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 Processes473 Function + 3690 Actual + 16 Discrete = 4179
Number of SPS contexts 189 Cycles + 32 Super Cycles (obsolete?)
Setting Types LHC SPS LEIR+PS+PSB+ISOLDE
Function Targets 65% 13.7% 1.2%
Function Corrections 3.5% 2.8% 0.02%
Arrays 2D 9.2% 0.003% 0.0002%
Scalars, Strings, Scalar Arrays 4.3% 0.02% 0.3%
Total: ~82% ~16.5% ~1.5%
30/07/2013 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
30/07/2013 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
30/07/2013 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
MDB API
JAPC Monitoring
Logging Client Process
SDDS API
NFS
MDB API
JAPC Monitoring
Logging Client
LaterNow
30/07/2013 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
30/07/2013 C.Roderick
11
Logging Service: Impact
Applications will need to switch data extraction API: Extension of existing logging-data-extractor-client API
○ 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
30/07/2013 C.Roderick
12
Middleware Upgrade in LS1 Why to upgrade ?
Replace CORBA-based communication library○ Became legacy, not actively supported maintenance issue○ Major technical limitations, e.g. blocking communication
Outstanding OP issues○ No protection against ’slow/bad’ client applications○ Poor scalability when many clients subscribed○ Missing support for priority clients (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)
30/07/2013 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)
Required Actions 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.) NOT possible to perform Get/Set/Subscribe on RDA3 servers
30/07/2013 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
Required Actions 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.) NOT possible to perform Get/Set/Subscribe on RDA3 servers
30/07/2013 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 After that date, old projects REMOVED from PCROPS repository
30/07/2013 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 early
adopters Dec’13: FESA 3.2.0 with RDA3 as main
release
30/07/2013 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
30/07/2013 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
30/07/2013