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