1. 20 Dec 20101 Peter Clarke Computing production issues 1.Disk Space – update from high-mu workshop 2.Disk planning 3.Use of T2s NCB meeting 20-Dec-2010

2. 8 Nov 20102 Peter Clarke At what point does physical disk space for DST at CERN run out ? At what point do copies of DST at T1s fall below an acceptable level At what point does CPU power become inadequate ? What deviations from Canonical Computing Model (CCM) are required ? Questions at workshop

3. 8 Nov 2010 Boundary assumptions for storage 3 Peter Clarke 1.Disk Allocation: 1.6 x 10 6 stable beam seconds will be recorded in 2011 2.DST Space is the limitation (i.e. MC and user space can be managed) 1.Two processing passes (i.e. RecoX-StrippingY) are kept at any time 2.…but we will limit 2010 DST data on disk to 100 TB somehow.  CURRENTLY IT IS 290 TB !!!!!!!! 1.DST event size = 130 kB Brown=departure from CCM

4. CERN-M-DST 6-10 July 2009 Peter Clarke 4 RECO08-STRIPPING12 230 TB  290 TB = 50 TB ????? Used Free

5. 8 Nov 2010 DST Disk space at CERN 5 Model is simple 525 TB is available  260 TB per processing pass. For 6 x 10 6 seconds  ~ 50 MB/ second to DST For 130 kB events  ~ 350 “Hz to DST” Green= OK within CCM

6. 8 Nov 2010 DST Disk space at T1s 6 Formally there exist no solution within CCM (6 copies) We present as “how many copies are possible” for each scenario

7. 6-10 July 2009 Peter Clarke 7 Strategy for DST disk space for 2011 (for discussion ?): -Manage DST to “live” for 2011 -Develop tools to make this easier -Much cleaning up has been done (Renato) -Will mean deviating from CCM -We need all pledged disk to be in place. -Need to put all new disk into CERN-M-DST space token Strategy for DST for 2012 -Ask for more Strategy for MC -Aggressive clean up and deletion going on now -Problem: users always need MCn, MCn-1, MCn-2,…. -  need detailed deletion mechanism, cant do “rm MC09*” -Need two new space classes -Wastebasket – to hold deleted data for a while in case needed -Archive

8. 8 Nov 2010 Boundary Assumptions for CPU 8 1.CPU use is driven by the number of events (HLT accept rate) and the event complexity (pile up). 2.The initial processing pass should take no more than 50% of available CPU 3.A re-stripping should take no more than 15 CPUdays 4.A re-processing should take no more than 75 CPUdays 5.We will commission the use of T2s for reconstruction.

9. 8 Nov 2010 Compute Power 9 1.Column 2 shows % of CPU capacity used for Pass 0 2.Column 3 shows re-stripping time 3. Column 4 shows re-processing time 4.Column 5 shows the amount of T2 usage we would need to bring the processing time back within boundary constraints.

10. 8 Nov 2010 Compute Power 10 Conclusions: The 2000Hz HiMu scenario is achievable with a departure from the computing model to use T2s. The 3000Hz scenario is possible but much more dependent upon use of T2s. The more aggressive scenarios do not look feasible at present. A significant augmentation in compute power would be required to manage these. Note: Use of T2s is not straightforward. Needs development and has not yet been commissioned for production Will need serious plan for time and effort to achieve this. Relies upon success of bringing more people

11. 8 Nov 2010 Conclusion 11 Peter Clarke Disk < 6 copies  CPU: Needs T2s Up to orange could be accommodated with foreseeable developments once decision is made – but still has implication for operations effort. Red requires going away and coming up with relatively radical proposals