Referaggio calcolo CMS Maggio Pisa 1

outline Stato generale calcolo CMS Stato italiano calcolo CMS Evoluzione modello di calcolo E soprattutto … Richieste

Stato Computing Presa dati meglio del previsto: – Secondi in collisione piu’ delle previsioni, e inoltre 1 mese e mezzo aggiuntivo in pp 3

Trigger rate salito da ~400 Hz a 1200 Hz Ben oltre le specifiche a 300 Hz (che erano 100 Hz nel Computing TDR) Totale eventi raccolti 2012: 7.8B (di cui 3.2B parked) 4 PU alto ma gestibile; sostanzialmente costante tutto l’anno (a differenza del 2011) Reco time vs lumi

AODSIM (il data tier per la fisica) -> 13B di eventi MonteCarlo 5

Utilizzo in Analisi CMS-World: Ormai da > 1 anno preponderan te (>90%) attivita’ su formato dati ridoto (AOD) Ormai stabilizzati su utenti singoli la settimana 6

Utilizzo risorse T1&T2 T1: at e over pledge a parte nelle fasi di validazione prima di reprocessing T2: over pledge (effetto principale: forte over pledge di alcuni siti, US in testa) 7

Reprocessing con release 5_3_X (legacy per il run ) Reprocessing in pratica finito. Fuori dal piano iniziale: legacy reprocessing dei dati 2011 con release 5_3_X: partira’ appena pronte le calibrazioni Poi (dopo estate) si comincia con simulazioni post LS1 8

Italia T1: – Pledge 2012 e’ kHS06 CPU, 2.8 PB DISCO, 6.6 PB TAPE CPU ok, disco ancora non completamente disponibile, tape ok (da poco) – PLEDGE 2013 e’ kHS06 CPU, 3.38 PB DISCO, 6.5 PB TAPE Pledges sono al 1 Aprile, ancora non raggiunte – Piu’ precisamente: CPU non troppo distanti per overpledge CNAF, TAPE e’ una diminuzione quindi ~ ok – Disco siamo ancora lontani, ancora non siamo tecnicamente al pledge

Utilizzo T1_IT_CNAF L’approccio italiano (1 solo T1 per tutti gli esperimenti) permette periodici overpledge anche grossi – Vero soprattutto per esperimenti grossi, che sono molto efficienti a occupare tutte le risorse libere – In alcuni periodi (estate soprattutto) CMS ha avuto al CNAF periodi a risorse > 1.5 pledge, in modo costante. Questo si e’ ridimensionato successivamente. – CMS ha “ripagato” negli scorsi 2 mesi, in cui c’e’ stata poca attivita’ di reprocessing e ha ridato indietro tempo CPU # jobs / ai T1: CNAF migliore dopo FNAL 10

T1_CNAF Unici buchi di attivita’ Nov-Jan e Jun: validazione dei reprocessing. Aprile: fine del reprocessing dei dati 2012 In attesa di partire con il 2011 (legacy reprocessing) Pledge e’ ~ 2000 (dipende da come si valutano le CPU, lascio a Luca definirlo bene); momenti extra pledge la normalita’ soprattutto in estate Running Pending Total 11

Tape CNAF: 12 pledge

T2 italiani BA, LNL, PI, RM1 – Totale risorse pledge 2012: Disco = 3.5PB CPU = 45.5kHS06 – 2013: identico Accordate solo dismissioni 13

Picture simile a quella dell’anno scorso: US inarrivabili, (cf slides G1, Sett 2012) Tutti I siti italiani nella meta’ superiore # jobs, 01/2012 – 02/

Disco I T2 italiani ~ 850 TB l’uno (come il 2012) – In realta’ disco arrivato dopo 01/04/2012 … Per Pisa in effetti appena arrivato Lo spazio e’ TOTALMENTE ALLOCATO secondo I dettami di CMS – Spazio reale occupato 70-95%, ma grossa variabilita’ annuale – Non vi e’ spazio aggiuntivo usabile liberamente 01/04/ Pisa oggi: 93% occupato

Gruppi di fisica Sono ufficielmente supportati 8 gruppi di fisica: – Bari: Higgs, SUSY – LNL: ElectroWeak, Muons – Pisa: Tracking, Tau & Particle Flow – Rome: Higgs, Egamma & ECAL 16

I Tier3 2012: richiesta ai referees del calcolo di cominciare un programma di sperimentazione sui T3 (definiti “per funzionalita’”, non per locazione geografica) Idee generali – Essere ottimizzati per le attivita’ di ricerca di un gruppo INFN – non per I task MoU – Attenzione all’attivita’ interattiva – Accesso a tutti I dati mediante la cloud italiana di Xrootd – Responsabilizzare gruppo locale di CMS; preparare persone “esperte di calcolo” a livello italiano Per questo li vogliamo distribuiti nelle sezioni Prodotto un documento aggiornato sul modello di analisi, consegnato ai referees 09/2012 Richiesta = 30kEuro per il

… ma Documento ben valutato – nessuna vera obiezione tecnica … ma no soldi! Proposta referees (statement in G1 di Sept 2012): destinare ai T3 una frazione delle macchine dismesse al T1 (piccola frazione delle migliaia di cores/anno) – Ci siamo detti d’accordo, ma ancora non si e’ mosso nulla – Chiediamo adesso che in occasione dell’arrivo delle macchine nuove al T1 (~1 mese), cominci l’assegnazione delle macchine dismesse ai siti Peraltro esistono gia’ macchine dismesse l’anno prima… 18

Italia in totale (01/ /2013) (occhio, # di jobs, non secondi CPU – e gli workflows che girano a T1 e T2 sono diversi) 19 (nota: T3_IT_Padova a meta’ 2012 e’ stato completamente integrato in T2_IT_LNL; ora sono una cosa sola)

Availability Transizione dCache -> Storm Riorganizzazione Disco CNAF Rottura controller disco 20 Upgrade dCache Riconfigurazione farm per passaggio a LHCONE Terremoto BO Problema elettrico Campus di Bari Upgrade dCache

Highlights L’Italia con gli US e’ l’unico stato ad aver fatto deployment completo di Xrootd a T1+T2 (e anche qualche T3) Abbiamo un redirettore nazionale + ospitiamo quello Europeo (Bari) – Erano 2 milestones > 100% DONE 21

Anche CNAF in Xrootd! Al CNAF e’ stata accesa un porta Xrootd Necessaria l’implementazione di patches a Xrootd per proteggere sistema TAPE del CNAF – Xrootd non pubblica nel redirettore files solo su TAPE – In caso di accesso diretto a files su tape, il recall avviene via GEMSS in modo “pulito” Patches ora accettate da Xrootd e in release ufficiale (da testare da parte nostra) CNAF + FNAL unici T1 completamente abilitati con Xrootd 22

Milestones 2013 “termine installazione/configurazione di Xrootd sui T2 per l'accesso remoto degli utenti italiani ai dati” – 1 giugno 2013 – 100% DONE “messa in opera del redirettore della cloud di calcolo italiana” – 15 dicembre 2013 – 100% DONE 23

Struttura server Xrootd Italia BA – firblibi03.ba.infn.it, gridtutorial8.ba.infn.it LNL – cmsxrd.lnl.infn.it PI – stormgf1.pi.infn.it, stormgf2.pi.infn.it RM1 – cmsrm-xrootd01.roma1.infn.it Redirettore Europeo – xrootd.ba.infn.it Redirettore italiano – xrootd-it.ba.infn.it CNAF – ds cr.cnaf.infn.it Al redirettore italiano sono connessi anche PG e TS come T3 24

Esempio di funzionamento Files letti da jobs a LNL via Xrootd: 15/04 dcache giu’ per upgrade; attivita’ di sito non ferma visto che i jobs potevano leggere dati in fallback via Xrootd 25 Altri tests fatti CNAF leggendo dati RAW in Xrootd-Fallback da FNAL T2_IT leggendo MC RAW in Xrootd-Fallback da CNAF

Analisi al T1 L’analisi al T1 per tutti gli utenti italiani e’ stata attivata (mediante un gruppo VOMS specifico) Una settimana al CNAF (estate, credo) Non nel modello di calcolo di CMS.. Per ora! Tecnicamente funziona e funziona bene, pero’ spesso il T1 e’ cosi’ pieno per le sue attivita’ MOU che alla fine i jobs girano prima nei T2 … 26

Milestone 2013 “definizione delle procedure di utilizzo del T1 per analisi e disponibilita' dello spazio disco necessario” – 1 giugno 2013 – Non ancora successo, motivo principale e’ la situazione TAPE e DISCO problematica al CNAF; non ha permesso di dedicare al momento risorse cospicue per. Entrambi problemi dovrebbero risolversi a breve, con gara DISCO CNAF (TAPE sta gia’ meglio) – 0% done per ora (la sposteremo fino almeno al raggiungimento del pledge disco T1) 27

Networking Durante gli ultimi 12 mesi – T2+T1(extra LHCOPN) sono passati a LHCONE, che permette ottimizzazione dei flussi di analisi e di trasferimento dati a matrice completa – I T2 sono passati a GARR-X 10 Gbit/s per BA, RM1, LNL (da tempo) 20-  Gbit/s per PI (recentemente) – Questo rende + sensato l’utilizzo italiano di Xrootd in modo trasparente 28

Attivita’ di sviluppo SW/CMP CRAB (tool di analisi) – Common Solutions con ATLAS/CERN-IT – Responsabilita’ di componenti fondamentali H.Riahi, D.Cingottini (PG) TaskManager Async Stageout … Computing Evolution – C. Grandi coordinatore L2, si sta formando un gruppo anche interessato agli studi Cloud partiti in CCR M.Sgaravatto (PD) 29

HLT Cloud Idea: sfruttare farm HLT (~13kCores/~200kHS06) quando la DAQ e’ spenta / ad uso ridotto – Shutdown lunghi (LS1) - ~ 2 anni – Shutdown invernali- ~ 3 mesi – Periodi di machine development ~ 2-5 giorni – Interfill – 1-2 ore Usato approccio CLOUD (Openstack/KVM con Openvswitch) – CERNVM come immagine di partenza – CVMFS per il software – Accesso allo storage via Xrootd – Possibilita’ di allocare / deallocare macchine in pochi minuti (non serve reboot dell’host) – Possibilita’ di allocare solo una frazione della farm (per esempio periodi a bassa luminosita’) Esperienza specifica, ma molte soluzioni riutilizzabili per generico uso di risorse opportunistiche, visto che – Nessuna dipendenza da sistema operativo – Nessuna dipendenza da topologia di rete (c’e’ un overlay virtualizzato) – Unico servizio che serve davvero un CLOUD service che istanzi le macchine, e una immagine preconfigurata per parlare con glideinWMS 30 M.Sgaravatto (PD): x acquisire questa expertise in Italia

Partecipazione a progetti MIUR PRIN08 (BA, MIB, PI, TS) –“Progetto e sviluppo di un ambiente hardware e software ottimizzato per l'analisi dei dati dell'esperimento CMS” –Concluso 09/2012 PRIN10/11 (… tutti …) –“Sviluppo di tecnologie per l’ottimizzazione dell’accesso ai dati di LHC, trasferibili ad altri domini scientifici, mediante l'approccio del grid e del cloud computing“ –02/2013 – 01/2016 Premiale PIDES (di CMS: CNAF, BA, PI) – sottomesso 2013 –“Long-Term Data Preservation and Scientific and Cultural Heritage” PON ReCaS (BA in CMS) PON Pegasus (BA in CMS) 31

Sinergie locali Storicamente, i centri “proto T2” sono stati iniziatori di attivita’ GRID su larga scala nelle Sezioni a partire dal La situazione attuale (per difetto, solo I progetti maggiori) – BA: Grosso centro per la fisica teorica PON RECAS Progetto PIDES per la data preservation – LNL Sinergie con esperimenti di GIII integrazione totale con PD via fibre dedicate – PI Partnership industriali (Ferrari, Ducati, Consorzio +39) Centro di Calcolo Nazionale di GIV Progetto PIDES per la data preservation Progettazione centro di calcolo teorico SISSA + proposte di collaborazione per condivisione risorse – RM1 Progetto regionale della Sapienza su cloud Nessuno di questi progetti sarebbe nato senza CMS come catalizzatore Nessuno di questi progetti sopravviverebbe a lungo senza il T2, che nella quasi totalita’ dei casi – Ha predisposto le infrastrutture – Fornisce expertise 32

Evolution of Computing Model per post LS1 1.Perche’ e’ necessario “cambiare” qualcosa – Nuovo environment da LHC – Nuove situazioni al contorno (funding etc) 2.Soluzioni: – Cambiamenti al computing model puro – Cambiamenti al nostro software 33

25 ns 50 ns Parametri …. 34 Nuovo environment di LHC

2015 Target del trigger: mantenere stessa physics capability sui canali dell’Higgs Questo da solo richiede un rate di trigger fra 800Hz e 1.2 kHz – 1 kHz nei conti seguenti (2-4 x wrt standard 300 Hz) Inoltre ci sono 2 fattori che complicano ulteriormente la situazione, a partita’ di numero di eventi raccolti – Lumi istantanea + alta = reco time x2.5 – Se 25 ns: effetto dovuto al OOTPU al momento da’ un fattore 2x (tracker soprattutto) 35

36 Per cui … In un mondo ideale, fattore 12x di risorse necessario; chiaramente impossibile Soluzioni messe in campo 1.Miglioramento dell’efficienza di uso delle risorse: CPU Mitigare effetto di trigger rate + alto: usare i T1 anche per una frazione della prompt reconstruction – Meno reprocessing standard possibili (solo 1 alla fine dell’anno) Usare farm HLT per Prompt Reco – Gia’ attivo, via HLT Cloud Uso opportunistico di risorse non CMS (e non HEP) 2.Miglioramento dell’efficienza di uso delle risorse: Disco Remote data access per evitare di dover distribuire piu’ copie dei dati/MC Data placement intelligente e dinamico Abbandono totale del formato RECO per AOD 3.Miglioramento dell’efficienza del nostro SW Computing/Offline

Rimane un fattore (~)2 di risorse da acquisire (su T0 e T1 *) Dal 2013 al 2015 … Statement di CMS: ottenibile con flat budget , o tutto su 2015 (dipende da scelte dell’ente finanziatore) – (ringraziando almeno in parte la legge di Moore …) *: I T2 sono molto meno critici, visto che li’ – Una parte dell’attivita’ scala con I dati (AOD dell’anno in corso) – Una parte scala meno (produzione MC, basta farne meno  ) – Una parte scala con il numero di utenti 37

Altre condizioni al contorno in cambiamento veloce Il paradigma CLOUD sta diventando standard industriale (molto piu’ di quanto GRID sia mai riuscito a fare) – Come implementazione, non un unico standard ma una certa interoperabilita’ per costruzione (per es. EC2 + OpenStack) Il supporto economico FPVI-FPVII (EMI, EGI) sta per finire – Se vogliamo un middleware solo nostro (HEP), dobbiamo pagarcelo – Seguire standard industriali dove si puo’, usare soluzioni comuni a N esperimenti quando non si puo’ (Common Solutions, CERN/IT) In generale, i fondi per il supporto dei siti (da INFN, per esempio), non sono certo in aumento 38

Altro …. Il mondo dell’IT ci sta cambiando intorno (lo fa da tempo in realta’, ma noi potevamo in un certo modo “fregarcene”) – Le reti geografiche sono cresciute molto + delle aspettative fine 199x (MONARC) Modello gerarchico di MONARC non piu’ una necessita’ La rete puo’ essere usata per ottimizzare accesso a storage (e comprarne quindi meno) – Le architetture di CPU stanno cambiando Mono -> multi core (da qualche anno) Cores x86 -> GPU (da qualche anno, ma non pero noi) Cores x86 -> ARM (+ recente) In GRID, passaggio ormai concluso fra WMS e pilot – Meno supporto centrale, piu’ CLOUD friendly 39

In una slide … Ridurre differenze T0/T1/T2: girare dove ci sono risorse Disaccoppiare Disco e CPU nel brokering Transizione verso tools di analisi/produzione comuni almeno con ATLAS MW GRID sostanzialmente congelato da usare nei nostri siti, ma: Essere pronti a sfruttare opportunita’ impreviste (slot in centri supercalcolo, risorse opportunistiche) via CLOUD – Tanto lavoro da fare: intra e inter cloud scheduling; ottimizzazione dell'accesso allo storage.. E additittura volunteer computing per produzione MC (completamente da fare) 40 Xrootd: BA, PI, BO + T2 CRAB3: PG BO, PD, BA

1) Solo ottimizzazione 2) Sviluppi in direzioni prevedibili3) Don’t ask … 41 Attivita’ di miglioramento SW di CMS

Fase 1: subito dopo LS1 Niente che non sia gia’ in buono stato ha speranza di essere usabile Per CMS sostanzialmente: Multicore Scheduling (vero) – Vero: Multicore “dei poveri” gia’ usabile oggi (forking) – Piani dicono multithreading vero in test finale late 2013, e subito dopo in produzione 42

Vantaggi Multicore #1 43 Avere controllo completo su una macchina intera invece che su uno “slot” porta numerosi vantaggi, alcuni attuali altri “possibili” Miglior utilizzo delle caches dei processori Scheduling di jobs a alta CPU e a alto I/O sulle stessa macchine (ora le controlliamo “globalmente”) Meno memoria utilizzata (perche’ calibrazioni etc sono presenti una volta sola) -> disegnare algoritmi piu’ efficienti, ma che utilizzino piu’ memoria Trend opposto a quello seguito gli scorsi due anni, dove si e’ fatto di tutto per diminuire la memoria, a volte a scapito delle performance

Vantaggi Multicore #2 Utilizzo di risorse opportunistiche con meno RAM, ad oggi a noi negate Il fatto che lo scheduling non e’ piu’ per core, ma per “macchina” diminuisce di un fattore ~ 10 il carico dell’infrastruttura di computing # di jobs da gestire # di slots da gestire # di files temporanei da gestire In fase finale di test Autunno 2013 (perche’ ESISTE gia’) 44

Fase 2 (~2018) Qui si puo’ fare R&D vera sull’architettura Tre aspetti in gioco 1.Massively multicore, ma sempre x86: XEON Phi 2.Massively multicore, architettura nuova: GPU+CUDA/OpenCL 3.Riduzione dei consumi sia diretti sia di condizionamento: ARMv8_64 45

1. XEON Phi Interessante per usi “tipo coprocessore”: un core Intel standard esegue ricostruzione, e passa la parte meglio parallelizzabile (tracking) al Phi Non necessita di nuovo codice: architettura di host e guest e’ la stessa E’ una buona palestra per massively multicore Chi lo fa ? Al momento ITALIA in pole position, con Francesco Giacomini + Matteo Manzali hanno cominciato una collaborazione con CMS per studiare il boost di particolari algoritmi (inizio probabile e’ il seedinf nei Pixel), usando il Phi del CNAF Pisa ha altri 2 Phi, collaborazione in partenza con informatici per capire se e’ possibile collaborazione Recentemente il gruppo HLT/CERN ha manifestato interesse... Non credo siano ancora partite attivita’ vere e proprie 46

2. GPU Questa e’ una soluzione molto performante in un piccolo subset di algoritmi (quelli sostanzialmente vettoriali) E’ anche la piu’ complicata dal punto di vista degli skill necessari; non permette un facile riuso di codice (deve essere riprogettato) – CUDA, OpenCL, etc In CMS si e’ pensato a utilizzi solo a livello di trigger, ma non mi pare si stia davvero muovendo nulla 47

3. ARM (v8, 64 bit) Interessante per 2 motivi: 1.Consumo! 1.Un core i7 consuma W (e in media altri ~4 per raffreddarlo) 2.Un core ARM e’ W 2.E’ un mercato con molta concorrenza (prezzi bassi, aumento di performance maggiore anno su anno) – La ricompilazione di CMSSW su ARM e’ pressoche’ conclusa – Per ora e’ solo un test preliminare (ARMv8 non esiste ancora) ma non e’ detto che in 6-7 anni il mercato e/o I costi infrastrutturali non ci spingano in questa direzione 48 Per il momento attivita’ CERN/OpenLAB. Sistema di sviluppo equivalente arrivato a Pisa la settimana scorsa; interesse da parte degli informatici per benchmarking / misura di performance

49

Ma prima: stato acquisti 2013 CPU: AQ copre le necessita’ dei siti – Tutto ok, opzione non ancora esercitata dai siti Disco: come al solito in ordine +/- sparso – Pisa continua con DDN (gia’ arrivato!) – Possibile sinergia ALICE+CMS per BA+LNL – Roma da sola (piccole cifre…) 50

Richieste 2014 C-RSG 04/2013 NB: in realta’ in alcuni casi in Italia abbiamo + del pledge 2013; sostanzialmente perche’ assegnazioni CSN1 erano avvenute prima dello scrutiny REBUS fa fede: 51

REBUS T1 T2 52

Tier1 Al netto delle dismissioni (vedi Luca) unico aumento sono 650 TB di TAPE 53

TIER2 “mancano” 5.2 kHS06 54

Dismissioni T2 (T1 segue altra strada) TOTALE e’ – 23.6 kHS06 (caso limite e’ Pisa, TUTTE le CPU vanno fuori manutenzione) – 440 TBN Dismissioni pure = 390kEur (se 10 Eur/HS Eur/TBN) 55

Richieste summary T1 – Dismissioni come decise dal centro – 650 TB di Tape T2 – Aumento di 5.2 kHS06 – Dismissioni pari a 23.6 kHS06 e 440 TBN – (+ server / networking come share solito) 56 (se 10 Eur/HS Eur/TBN)

Una nota: manutenzioni/emergenze Sett ‘12: “…il supporto per il mantenimento ordinario delle infrastutture e' a carico delle sezioni/laboratori che ospitano i Tier-2 mentre quello della infrastuttura straordinaria (tipo UPS) va a carico della CCR. Se i direttori non hanno soldi … presentino il problema al direttivo e li saranno discusse le possibili soluzioni.” CCR: ok! Problemi UPS a BA e RM1, CCR ha finanziato tutto/in parte la cifra per tornare operativi! Man.Ordinaria: non ok! Richiesta da direttore PI per contributo manutenzioni non presa in considerazione In pratica, NON abbiamo una soluzione per le manutenzioni ordinarie dei centri; che si fa?????? 57

Dismissioni T2 Prima stima al momento Cosa ci aspettiamo? – Nel corso di 3 anni dismissione di tutte le CPU – Nel corso di 3 anni dismissione di 60-75% del disco Per il disco dipende totalmente dalla fase Per esempio, per Pisa aspettatevi botta l’anno dopo 58

Summary delle richieste (+ usual share di networking e server) 59

NOTA BENE Volutamente non ho nominato ReCaS, vedere il talk di Gianpaolo Queste sono le richieste globali, indipendentemente da dove arrivino I fondi…. 60

ReCaS Da slides di GP, il max che si puo’ ottenere e’ 1.Delta nazionale (pochissima roba) 2.Dismissioni Bari Parte delle dismissioni Bari Molto poco del delta Per cui: forte (!) richiesta di mantenere I T2 not ReCas operativi (-> dismissioni accordate) : aumento di risorse ai T2 not ReCaS (naturale visto il punto 4 sopra) 61

62 BACKUP

SITI 63

ROMA1 Infrastruttura 1 – terminata con fatica la gara per le ventole per il terzo chiller (su fondi 2102 raschiati qui e la’) – purtroppo ci sono problemi con il DURC del vincitore, quindi al momento non abbiamo previsioni sull’installazione del sistema – reminder: il terzo chiller era stato acquistato a fine 2011 Infrastruttura 2 – abbiamo avuto un incidente sull’UPS: una batteria si e’ bruciata e ha generato a catena un surriscaldamento di una intera linea di batterie del secondo UPS – rimpiazzo gia’ ordinato, abbiamo chiesto alla CCR il rimborso delle spese (circa 9000 euro IVA inclusa) Il sito performa molto bene e non ci sono problemi 64

BARI CPU: – Via AQ INFN Storage: – Si sta valutando se associarsi alla gara storage CMS+Alice a LNL oppure impegnare i soldi sulla gara ReCaS La seconda soluzione ha il vantaggio di sfruttare una percentuale di sconto maggiore e fornire risorse identiche alle acquisizioni ReCaS Ha lo svantaggio di avere tempi di acquisizione più lunghi 65

BARI – attivita’ Batch System: – Testing di SLURM: Batch system Open Source con scalabilità anche superiore ad LSF – Testing di Torque 4.x per verificare le migliorate capacità di scalabilità File-system: – Testing di sistemi di storage che permettano di usare replica software dei dati invece dei RAID Hadoop GlusterFS Soluzioni Cloud: – Testing di OpenStack – Interesse nel verificare la possibilità di eseguire workflow di CMS su un testbed OpenStack 66

Releases CMSSW_5_2_X per la prima parte dell’anno – Ottimizzata per alto PU rispetto alle release 2011 (4_X_Y) 35% meno RAM 120% + veloce Nota: miglioramenti su un sample speciale ad altissimo PU; nella presa dati standard miglioramenti inferiore Passati a CMSSW_5_3_X all’inizio dell’estate; usata anche per Heavy Ions modifiche soprattutto per GlobalEventDescription (meglio noto come ParticleFlow) In generale, T0 non ha mostrato particolari sofferenze dopo un 2011 complicato 67

Disco/Tape Disco: per il disco e’ (per ora) solo una cache del Tape, per cui e’ per costruzione sempre al 90% di occupazione ( disco ha influenza sull’efficienza e sullo stress del tape system) – Cambiera’ nei prossimi mesi, anche CMS va versouna separazione esplicita aree D1T0 e D0T1 Tape: situazione e’ stata spesso al limite. Abbiamo superato i 5.8 PB utilizzati, ma soprattutto il CNAF in totale e’ stato a poche centinaia di TB dal riempimento sia in Primavera, sia a fine anno. Ora sembra rientrato 68

Siti interessati Al momento della disponibilita delle macchine, l’assegnazione ai siti sara’ in base alle garanzie che queste danno di fruibilita’ delle stesse Come detto un T3 e’ una funzione, non un sito, per cui siti possibili sono – Il T1 (e in particolare la Sezione di Bologna) – I T2 – I centri di CMS gia’ esistenti su fondi non INFN I maggiori sono TS, NA, BO, PG, MIB … ma anche FI, CT, TO sono interessati (in pratica, tutti …) 69

Come # cpu seconds (non da CMS ma da EGI, meno “certificato”) (non chiedetemi perche’ EGI pensi che Vienna sia in Italia…) 70

Responsabilita’ SW/CMP (dai prev 2013) Posizioni di L1 in tutti i progetti “computing” 71

FTE “operations” Per i siti abbiamo – CNAF: 2 assegnisti nominali (in media meno viste le lentezze per assunzioni / carenza di candidati) pagati per CMS – T2: vecchio “piano Forti”: nessun personale finanziato per la gestione Frazioni di staff/assegnisti CMS non dedicati Eventuali assegni PRIN/Firb/Borse Tecnologiche Media sui T2: difficile sommare piccoli contributi di N persone, ma in media direi che siamo su FTE/sito – Mediamente sparsi su + di una persona – Mediamente FTE sul calcolo sono non solo di CMS.. Questa e’ la frazione ascrivibile a CMS – CMS ci riconosce come lavoro di servizio sui TierX: 31 FTEMonth per il T1 60 FTEMonth per i 4 T2 – I totali di ESP su computing/Offline/PPD sono stati per il FTEMonth Computing (include i 91 di cui sopra) 38 FTEMonth Offline 52 FTEMonth PPD 72

73

T Dando per acquisito il 2014 come nelle scorse slides Per cui in caso di completa accetazione da parte dello scrutiny, l’aumento sarebbe 19.5 kHS TBN 3.2 PB di tape (sempre escluse dismissioni) 74

Evoluzione dismissioni CPU = 100% DISCO = 2.1/3.5 = 60% 75

T Dando per acquisito – Situazione 2014 – Dismissioni 2014 effettuate Rimane: – Risorse pure: 14.3 kHS06 ~ 600 TBN 76