# Presentation: 824979

## An Update to the CDF Offline Plan and FY2006 Budget

- _Outline:_
- CDF computing model
- Budget for FY'06 and projections for FY'07-08

- _P.Murat, FNAL_

## CDF Computing Infrastructure

- CPU: Interactive and Batch Analysis Facilities
- Storage Systems
- Databases
- Networking

**Robotic Tape Storage System**

- Reconstruction Farm

- Batch Analysis Farms
- FermiGRID
- GRID

- Disk Cache

- Analysis Disk Servers

- Central interactve login pool

- Databases
- Data Catalog

## Model of the CDF Computing: the inputs

- _performance of the Tevatron _
- Luminosity profile: use design projections by the accelerator division (8.5 fb-1 by 2009)
- operations:
- 100 hours/week, 40 weeks/year, incorporate long shutdowns during the previous years
- _performance of the CDF detector:_
- Peak logging rate: 20 MBytes/sec (2002-2004) –> 60 MBytes/sec (2007-2008)
- data logger upgrade in 2005-2006
- Overall operational efficiency: 50% (2002) -> 90% (2009)

## Model of the CDF Computing

- _RAW event size:_
- reduced by a factor of 2 over the years
- dependence on the instantaneous luminosity (new for this year)
- _Profile of the instantaneous luminosity_
- <Linst>  = 0.4 L(peak)
- _Dynamically prescaled triggers_ to utilize DAQ bandwidth more efficiently
- average data logging rate: 60% of the peak
- _7 output data streams written by the data logger_
- 10% overlap between the 7 raw data streams
- For 2 streams out of 7 do not drop results of the L3 reconstruction

## Model of the CDF Computing

- Production output : total volume 15% larger than the input volume
- MC data volume: 1.3 x reconstructed data volume
- MC event size = 1.3 x reconstructed event size (measured)
- N(MC events) = N(reconstructed events)
- Ntuple event size: 30% of the data/MC event (accounts for more than 1 commonly used ntuple format)
- All the reconstructed and MC data ntupled

## Cross-checks: 2 models using different parametrizations and simplifications:
Data rates (in MB/sec) out of the data logger (I)
event rates out of the trigger system             (II)
Overall agreement between the models within 10%, use (I) as more conservative asymptotically
Primary source of uncertainty: expected volume of the RAW data 

- Data rates (in MB/sec) out of the data logger (I)
- event rates out of the trigger system             (II)
- Overall agreement between the models within 10%, use (I) as more conservative asymptotically
- Primary source of uncertainty: expected volume of the RAW data

_**Data **__**volume**__** estimates**_

## CPU Requirements: Offline Reconstruction

- 1-pass scheme: process the data 1.3 times (0.3 – calibrations)
- output of the calibration processing is not stored
- <time/event> = 3.8 Ghz*sec
- New in the model: event processing time dependence on the Linst
- Assume luminosity profile doesn't change:
- <L_inst> = 0.4 L_inst (peak)
- CPU needs well predicted
- unplanned reprocessings: ~ 10% (based on operational 4 cycles)

## CPU Requirements: Off-site Computing

- Various types of jobs
- _Biggest single consumer'2005: MC Production_
- ~600M events
- <time/event> ~ 30 Ghz*sec
- _Individual user MC _
- _Analysis jobs, not requiring large amount of input _
-  	Example: top mass fitting
_**Conclusion: **_
**CDF is using offsite CPU resources efficiently**

## Various kinds of jobs, the largest single one – making ntuples (~50% of the total)
Ntuple making executables run physics analysis algorithms. They are not fast
High-Pt analyses: <time/event> ~ 3GHz*sec 
B-analyses: <time/event> ~ 10 GHz*sec
event size : ~ 20% of the reconstructed event
2005: ntuples are made at Fermilab
Efficiency of using onsite CAFs ~95%

- Various kinds of jobs, the largest single one – making ntuples (~50% of the total)
- Ntuple making executables run physics analysis algorithms. They are not fast
- _High-Pt analyses_: <time/event> ~ 3GHz*sec
- _B-analyses:_ <time/event> ~ 10 GHz*sec
- event size : ~ 20% of the reconstructed event
- 2005: ntuples are made at Fermilab
**Efficiency of using onsite CAFs ~95%**

- _CPU requirements: Fermilab  CAF's _

## 2005: observe changes in CPU usage pattern:
Production: new version of the reconstruction algorithms (v6), process only 2005 data
generate run-dependent MC only for 2005 data, do not regenerate MC for the old runs
produce ntuples only for 2005 data
The total dataset: 
2 parts (2002-2004 data and 2005 data), 50:50 approximately
For each part MC and the data processed with the same algorithms
Moving from a mode where CPU needs scale with the total dataset size to a different mode where the component proportional to the added dataset size becomes significant
CPU(2006) = A*D(total) + B*D(2006)
Analyzed 2 extreme cases: A=0 and B=0

- Production: new version of the reconstruction algorithms (v6), process only 2005 data
- generate run-dependent MC only for 2005 data, do not regenerate MC for the old runs
- produce ntuples only for 2005 data
- _The total dataset: _
- 2 parts (2002-2004 data and 2005 data), 50:50 approximately
- For each part MC and the data processed with the same algorithms
- Moving from a mode where CPU needs scale with the total dataset size to a different mode where the component proportional to the added dataset size becomes significant
**CPU(2006) = A*D(total) + B*D(2006)**
**Analyzed 2 extreme cases: A=0 and B=0**

- Model of the CPU Requirements

## CPU Requirements: “incremental” model

- CPU needs scale as an increment to the dataset size
- Large deviations from Moore's scaling (~x1.6 /year), use x1.3/year
- Used 2004-2005 data to tune the model of the CDF computing needs
- Plan to have ~50% CPU resources off-site starting from 2007

## CPU Requirements: “proportional” model

- CPU needs scale as the total dataset size
- Plan to have ~50% CPU resources off-site starting from 2007
- Budget “proportional” model

## CPU requirements: ratio between the analysis and MC jobs

- Under this assumption: analysis needs : MC needs ~ 1:1
- Primary reconstruction adds a relatively small fraction

- The most simplistic model:

## New data on Analysis Farm Usage 

- DCAF monitoring: offsite CPU facilities are extensively used for analysis
- FNAL: 20% MC vs 40% analysis, offsite: 60% MC vs 40% analysis
**Relative CPU consumption:  Analysis:MC  ~ 2:1**

## Disk Requirements

- Requirements model: total disk volume proportional to the dataset size
- Plan 2006 purchase to meet 2007 needs, retire 4-year old fileservers
- Price model: $20K per 14 TB fileserver in 2005, Moore's scaling (x2 in 18 month)
- 2 components: disk cache (backed up by the tape) and analysis disk (static)
- Optimization strategies may be different
- Taking steps towards optimization of the disk usage:
- Reorganizing project disk into the common pool
- Will work with D0 and CD to develop disk cache simulation

## Tape Drive Requirements

- Recent decision: acquisition of a new tape robot in FY'2006, arrives in March
- LT0III drives, 60 MB/sec (assume $16K/drive+mover), in 2006 use 0.2 TB tape
- Expect that one-time doubling the tape I/O bandwidth will cover the needs of the experiment through 2009

## Interactive systems, DB, miscelaneous

- Interactive systems: new code servers , interactive Login Pool upgrade
- Databases: Frontier servers bought, just maintenance
- Miscellaneous:  not predicted hardware procurements

_**DB infrastructure:**_
- Central server (ORACLE)
- Replicas (FronTier  squids)

## CDF Networking'2005

## Networking Requirements

- _FY'06 networking upgrades:_
- FCC/GCC : 3rd 6509 switch + Starlink upgrade
- CDF B0/trailers : switches and fabric upgrades

## Computing Requirements Summary

- “proportional” model used
- In 2007-2008 ratio about 50% of the total CPU located offsite

## Tapes and Operating Budget

- Capacity of 2 CDF STK silos - 10900 slots
- Budget STK9940B tapes ($75) for 2006, LTOIII tapes ($50) for 2007-2008
- new LTOIII robot: $50/slot, 5 LTOIII drives budgeted for 2006
- Contingency 15% included
- Recycling and compactification of the existing tapes in progress

## Equipment Summary

- the most expensive component is CPU (“proportional” model budgeted)
- CPU acquisition strategy assumes 50% of the total computing located offsite

## Summary

- Improved, more detailed, model of the CDF computing
- FY'06 CDF computing budget request :
- Equipment: $1,66M
- Operating and tapes: $0.21M
-  'End game' scenario : 50% of the total CPU resources offsite