Tommaso boccali – infn pisa Referaggio CMS Tommaso boccali – infn pisa

outline Stato del computing di CMS Stato del computing italiano di CMS Processing 2016 Novita’ nel modello / sw Processing 2017 Stato del computing italiano di CMS Situazione a fine 2016 Stato acquisti 2017 Richieste 2018

Computing CMS – come si e’ concluso il 2016? Sulla carta anno di produzione standard, con Hubner factor ~ 0.4 Anche lontano da MD/TS, circa meta’ del tempo _non_ in stable beams 5.1 Msec di live time della macchina ~25/fb raccolti Luminosita’fino a 1.5e34, ma solo in caso di BCMS positivo (unlikely….) La realta’ Hubner factor fino a 0.85 a luglio 3.6Msec a fine Luglio, 7.3 previsti per il resto dell’anno > 40/fb delivered by LHC

Problemi computing 2016 – non pochi! Tape_T1 previsto dal modello (per 5.1MSec!) = 100 PB; 88 pledged On top of this, 7.3Msec vs 5.1 Msec Trigger rate 1kHz da modello, non sostenuto fino a ~Settembre (visti fino a 1.5 kHz a inizio fill) Problemi trasferimento dati dal CERN  T1s; up to 6 PB backlog Disco T1 pieno (PIC, FNAL, KIT, IN2P3) Problemi di elettronica del Tracker; risolti a meta’ Agosto 2016 Luminosita’ istantanea maggiore delle aspettative (BCMS == ok!) Trasferimenti da tape problematici, soprattutto per alcuni siti (JINR) HLT non pronto al momento della preparazione della produzione MC

Soluzioni! Siamo sopravvissuti grazie alla velocita’ con cui siamo riusciti a realizzare modifiche anche sostianziali al modello di calcolo Alcune previste comunque, ma accelerate Altre realizzate al momento E’ istruttivo vedere come si sia fatto, anche perche’ mole di queste diventano baseline per 2017 e 2018 E permettono di tenere richieste molti piu’ basse del previsto!

1) Tape_T1 previsto dal modello (per 5.1MSec!) = 100 PB; 88 pledged Soluzioni messe in campo: Pulizia estrema dei dataset RunI: Pulito tutti I RECO, tutti gli AOD prima dell’ultimo reprocessing Puliti tutti I samples a livello geant4 (GEN-SIM) ~30 PB fra T1 e T0 Cambio di modello per il resto di RunII (non solo): Per una frazione dei dataset, NON salviamo piu’ su tape I GEN- SIM (Geant4) – rifatto on the spot se serve Fine Marzo 2016 (fine anno “fiscale” C-RSG): T1 = 81/88 PB usati per noi T0 = 41/44 PB usatiper noi fino a +15% secondo I siti: WLCG dice 84/88 Dipende da cancellazioi, repack, etc T0 - T1

2) Trigger rate 1kHz da modello - visti fino a 1.5 kHz a inizio fill Il ramp up di LHC e’ stato piu’ veloce del previsto, e BCMS ha funzionato in pratica al primo colpo Meta’ luglio gia’ fino a 1.4e34 Trigger in difficolta’ a inizio Fill, con rate maggiore di 1 kHz In parte compensato verso fine fill, con rate < 1 kHz Ma questo fa si’ che in ogni caso abbiamo preso + eventi a alta lumi, e meno a bassa lumi, sbilanciando il PU medio come deciso da LHC (che non ha questo effetto) Dopo Settembre, nuovo trigger in azione, decisamente meglio 2017 dovrebbe essere ok, condizioni della macchina note con minore indeterminazione Model = 1kHz PH, 450 Hz Parking Reality ~1.2 kHz PH, ~600 Hz parking, a volte 1.2 kHz in piu’ di tigger samples

3) Problemi trasferimento dati dal CERN  T1s; up to 6 PB backlog Luglio 2016  Hubner factor fino a 0.85 Difficolta nei trasferimenti CERN  T1 Soprattutto FNAL, con enorme backlog Backlog totale fino a 6 PB Chiesto prestito di disco all IT! Lavoro con la IT per ottimizzare FTP di EOS Fattore 2 ottenuto! Solo ~ 50% di RAW su T1 Disk Solo ~ 50% di RECO su T1 Disk

4) Disco T1 pieno (PIC, FNAL, KIT, IN2P3) Alcuni T1 in ritardo con I pledge (KIT per esempio) Dati in arrivo maggiori del previsto Soluzioni: Solo ~ 50% di RAW su T1 Disk Solo ~ 50% di RECO su T1 Disk Puliti samples presenti su tape e non acceduti da almeno 1 anno da disco Attivato un utilizzo maggiore di JINR_Disk, che era tenuto un po’ in disparte

5) Problemi di elettronica del Tracker; risolti a meta’ Agosto 2016 Problemi delle “HIP”: elettronica del tracker in saturazione; perdita di effcienza evidente da 0.5e33 Mag-Ago: ricerca di soluzioni sw per mitigare l’effetto 13 Ago: soluzione hardware trovata, mediante ottimizzaizoni parametri elettronica Poco meno di 20/fb raccolti fino ad allora Soluzione hadrware implemenenta subito in presa dati Dati precedenti: reprocessing completo con mitigazioni software (non ottimale, ma il meglio che si potesse fare) Un mese di reprocessing; in tempo per Moriond ma ha rallentato la preparazione di nuovi samples MC

6) Luminosita’ istantanea maggiore delle aspettative (BCMS == ok!) May 2016: BCMS Unlikely, PU massimo ~ 30-40 events Jul 2016: siamo gia a quasi 50 a inizio fill Necessita’ di rifare il MC per Moriond 17; inoltre fino a fine ottobre cPU impegnate nel ReReco dei dati con le HIP Soluzione: mettere in produzione prima del previsto il premixing Invece di caricare 35PU (<>) * 16 bx (-10, +5) = 500 eventi di MinBias per ogni evento di segnale, preparare una libreria di O(200M) di eventi premixati, e poi fare merge con il segnale 1 a 2 Molto minore utilizzo dello storage dei siti  piu’ siti possono fare DIGI-RECO Problema di fluttuazioni statistiche (200M premix per fare 10B eventi MC = riutilizzo di ogni evento premixato molte volte) Lunghi e complessi tests per vedere “features” Libreria premixing O(500 TB): non si puo’ distribuire ai siti; 2 copie a FNAL e CERN, accesso via Xrootd Tempo CPU ~ ½ !

7) Trasferimenti da tape problematici Produzione MC da Nov 2016: necessita’ dirifare DIGI-RECO a maggiore PU GEN-SIM su tape, recall da tape e’ stato il problema principale In generale, CMS riesce a avere max 2 GB/s da tape a disk, e meno sulla media mensile Alcuni siti, JINR in primis, sono risultati un collo di bottiglia Soluzione: Rifare GEN-SIM da zero e’ risultato piu’ pratico che fare recall da tape Nuova modalita’ di produzione ora e’ la baseline per una grossa fetta della produzione 2017 In realta’, guardando indietro, il riutilizzo dei GEN-SIM e’ sempre stato problematico 2016: Previsioni LHC per Beam Spot sbagliate – rifare 2017: nuovi Pixel 2018: fine sostituzione elettronica di HCAL In ogni caso, GEN-SIM reuse come nel RunI improbabile

8) HLT non pronto al momento della preparazione della produzione MC A Aprile 2016, produzione MC per il 2016 in partenza, ma HLT non ancora deciso. Che fare? Si e’ deciso di sperimentare un nuovo modo operativo, in cui invece di salvare AODSIM, si salvasse RAW-AODIM (cioe’ l’evento RAW completo con AODSIM). Successivaemnte (> 1 mese dopo), quando HLT ok, si e’ riprocessato RAW-AODSIM e rifatti AODSIM con lo stesso contenuto Offline (non rifatto), e nuove tabelle trigger Tutto questo ha necessitato di 2 PB in piu’ di spazio disco ai T1/T0 Offerto dal CERN in emergenza … nel 2017 abbiamo deciso di NON simulare HLT nel MC del tutto, per cui il problema non dovrebbe ripetersi

Conclusione di questa parte Il Computing di CMS e’ tiuscito a sopravivvere a un 2016 con Luminosita’ +50% del previsto Molti MC piu’ del previsto Problemi hardware che hanno necessita’ processing non previsti Scarsita’ nelle pledge (vedi dopo) Problemi di trasferimento dati … Tutto grazie all’estrema facilita’ di inserire cambiamenti nel modello, anche su scala inferiore alla settimana. Molte delle mitigazioni appena descritte, sono gia nel modello per il 2017 e il 2018, e permettono di aver diminuito le richieste di circa il 40% rispetto alle stime “dumb” Nella pratica, a parte il tape, come richieste il 2018 appena “approvato” e’ poco diverso dal 2018 come prospettato prima dell’inizio della presa dati 2016.

Piccola premessa 2017 pledge vs C-RSG recomm Prossimi plots utilizzo risorse wrt alle risorse pledged 2016 Per CMS pledged != recommended 2014-2016: deficit livello T1_tape (up to 12%) 2017: differenza decisamente sostanziale, impatto sulle richieste More later …

Utilizzo risorse – a.s. 2016 (global CMS) Maggior parte dei plots come da documenti C-RSG Utilizzo CPU: 103% del pledge T1, 129% del pledge T2 “buchi agosto/settembre” dovuti principalmente alla situazione del Tracker, che aveva messo un po’ in stallo produzione e analisi Grosso sforzo nov-feb per rigenerazione MC

“altre risorse” CPU Farm HLT: Risorse opportunistiche In operazioni per offline _anche durante data taking_ da primavera 2016 (interfill) Interfill troppo corto, mitigato con sospensione VM Tests fatti per utilizzi anche durante parti finali del fill … non in produzione In media sul 2016, HLT ha offerto a CMS 51 kHS06 ~5% del totale delle risorse di CMS T1 +T2 Risorse opportunistiche 2015: Amazon WS 2016: tests con Google, 150kCores per alcuni giorni

Efficienza CPU Qui problema “annoso” di definizione efficienza. CMS alloca internamente ”slots virtuali di 8 cores, validi 48 ore” riempiendoli alla tetris con jobs 1 e 4 threads Puo’ fare overcommit doi cores se sa di avere jobs che necessitano di poca CPU e (per esempio) alta banda Verso la fine delle 48 ore, Condor lascia slots vuote perche’ assume di non poter far partire Effetto sull’efficienza: invece di avere i “tempi” morti accountati al batch system, sono accountati internamente a CMS Efficienza payload di CMS e’ come da modello WLCG ~80% Ma a questo va aggiunto un 10-15% di inefficienza dovuta al partizionamento interno

Tape+Disk Tape: Disk @ T1 99% utilizzato a fine 2016 Come detto prima, situazione critica verso Settembre, “risolta” con drastica cancellazione soprattutto di dataset RunI (non ripetibile) Fine Marzo 2017 – da Rebus T0 tape: 40169/44000 TB utilizzati (91%) T1 tape: 84310/88200 TB utilizzati (96%) Disk @ T1 99% utilizzato a fine 2016

Disk @ T2s Il disco ai T2 e’ ~30% fra operation disk e user disk Il restante ~ 70% mantenuto fra l’85 e il 95% da DDM / Dynamo, basato su un popularity system e delle policy di eviction per dataset. Esempi RAW data puo’ sparire dal disco 3 mesi dopo data taking Vengono mantenuti su disco almeno 3 copie di MiniAOD e 1 copia di AOD Dataset non letti per 6 mesi possono essere tolti, se hanno copia su tape Etc etc Siti “rotti” Samples “verdi”: possono esser tolti in caso di necessita Samples “blu”: protetti dalle policy

Disk Popularity Numeri non buoni di CMS. Questo giro: a fine dicembre gran parte della produzione MC nuova finita, ma non ancora validata  grandissimo numero di files non acceduti Sistema di popolarity driven placement in opera: piu’ di 15 PB di dataset cancellati

Situazione Italiana – contrinuto al computing globale CMS Come al solito seconda forza in CMS La terza e’ fasulla: CERN utilizzato per Offline shutdown/etc Niente di particolarmente nuovo …

Situazione italiana - LNL Annoso problema del monitoring CPU faust in pratica non mantenuto, si usa per quello che si puo’ Utilizzo wrt pledge: sonsiderazioni sito per sito, partendo da quelli facili Utilizzo pledge al 149% Nota: transizione pilot 1Core8Cores

Pisa Buco di accounting noto e non risolvibile (Maggio 2016) Out of the box: 120% Correggendo Maggio: 130%

Bari (Come per il CNAF e tutte le VO in questi due siti) l’attivita’ pre Maggio 2016 non ha la label di esperimento Attivita’ precedente “totale” e’ costante, per cui facciamo estrapolazione che dovrebbe dare Used/pledge = 90% Decisamente > 100% da settembre in poi, oggi viaggia tranquillamente sui 3000 cores di media

Roma1 Sito piu’ problematico per situazione personale Tecnologo In aspettativa Settembre 2015, dimessosi definitivamente Settembre 2016 Nuovo assegnista da Settembre 2016, fase di ramp up lenta Inoltre parte delle CPU spente per installazione nuovo hardware: spazio fisico limitato, necessita’ di spaostamenti che impattano su availability delle risorse Ancora da effettuare passaggio a code MultiCore  in questi giorni! Utilizzo del pledge = 48%

Tier1 Stesso “problema” di Bari (per tutte le VO) Estrapolando, utilizzo di 86% del pledge

Site Readiness Attenzione: 18% del tempo “bianco”: minitoring non funzionante.

CPU efficiency Per il payload nessun particolare problema Pisa un po’ bassa d’estate 2016 – francamente difficile ricostruire perche’ adesso Probabilmente un workflow particolare?

Share relativo Italiano Il grosso overpledge di LNL e’ ben visibile

Utilizzo disco Italia Popularity per sito non disponibile in CMS – questo e’ come usiamo il disco centrale Utilizzo dischi ai nostri siti in linea con il resto: fra l’85% e il 95% Sui nostri dischi: T1_IT T2_IT

Richieste 2018 – un po’ di storia Ottobre 2016: richieste 2017 e 2018 dopo gli aumenti del 50% di performance previsti da LHC A partire da un aumento teorico del +40% sul 2017, scesi a +20%  2017 blessed 2017: grosso problema (gia’ affrontato a Settembre e a Novembre in CSN1) 2018: aumento 0-30% rispetto al 2017 Non piccolo, ma non confrontabile con l’aumento 2016  2017 In linea di principio, 2018 non problematico. Ma…

…. Pledge non hanno raggiunto le raccomandazioni Se uno confronta le richieste 2018 non con richieste 2017, ma con pledge 2017  aumento enorme, fino al 70% CMS ha speso l’autunno a cercare correttivi a questa situazione Cercare trovare modo di avere pledge compatibili con le raccomandazioni Cercare di dimunuire le richieste con ulteriori cambiamenti al modello

Oltre a quello gia’ descritto nelle prime slides Maggiore utilizzo dell’accesso remoto ai dati: diminuzione delle copie di AOD(SIM) fino a 1 solamente Si conta sul fatto di usare maggiormente MiniAOD Si rischia un delay sulle analisi che invece abbiano bisogno di AOD  rischio accecttabile Non salviamo piu’ l’output di Geant su tape come baseline Rischio nel caso ci siano da fare reprocessing, giudicato accettabile Samples di PhaseII: baseline per l’analisi diventa MiniAOD e non piu’ AOD o RECO Spazio disco risparmiato In questo modo richieste 2018 POCO DIVERSE DA QUELLE 2017 (tape apart)

Pero’ … Richieste 2018 ancora grandi rispetto a pledge 2017 Tante iterazioni con C-RSG, con outcome finale Totale delle richieste endorsed da C-RSG al 100% Consigliato (& implementato) spostamento di 20 PB di tape da T1 a T0 T0 altrimenti molto vicino al +0%, pare che CERN abbia accettato di aiutare vista la contingenza

Situazione fine 2017 (prevista) CAVEAT: dopo meeting, tolti da acquisti CPU 2017 ~4 kHS06 come da proposta Acquisti 2016: O(200) TB in piu’ acquisiti come dichiarato a Febbraio, CNS1 2017: CPU: gara nazionale con CNAF – in partenza Tutto CMS, and Roma1 che deve acquisire solo 1.4 kHS06 – vediamo che succede Difficilmente alla giunta di Giugno …. Disco: RM1: acquisto con ATLAS (stessi rack corti Rittal) Acquisti di 50 TBN meno del pledge, a causa di quantizzazioni – da recuperare piu’ in la’? LNL, BA: gara comune con ALICE (+CT) Grossi problemi, siamo oltre i 600kEur, non si trova amministrazione che voglia seguirla PI: espansione sistema Fujitsu acquisito l’anno scorso, in modo da preparare infrastruttura globale anche per gli altri utenti Prezzo ignoto, di sicuro entro I parametri referee Anno prossimo spazione per > 1 PB senza ulteriore infrastruttura Acquisti esattamente come da tabella referees: (ma la quantizzazione?)

Gara CPU 2017: numeri finali come da DB assegnazioni BA: invece di acquistare 4.6 kHS06 acquistare 3.1 kSH06 PI: da 12.4 a 10.4 LNL: da 2.5 a 1.95

Share di CMS_IT in CMS Frazione di risorse nel pledge italiano 2015: 13% 2016: 12% 2017: 12% rispetto alle richieste di Aprile 2016, nella pratica (da Rebus) T1_CPU: 11%, T1_Disk: 10%, T1_Tape: 12% T2_CPU: 11%, T2_Disk: 9% 2017: da https://cds.cern.ch/record/2210171/files/CERN- RRB-2016-104.pdf Italy al 12.86% Che si fa? Mia proposta e’ tornare al 13% ALMENO per quello che riguarda T1_Tape (dove c’e’ maggiore preoccupazione…) C’e’ margine per T1_*?

Costi unitari + acquisti 2016 T1_CPU = 8 Eur/HS06 T1_Disk = 180 Eur/TBN T1_Tape = 25 Eur/TB T2_CPU = 8 Eur/HS06 T2_Disk = 180 Eur/TBN Alla CSN1 del 7 febbraio CMS ha dichiarato acquisti ulteriori per BA: +13TB disco, -1 kHS06 PI: +50 TB disco LNL: +150 TB disco, +1 kHS06 Quindi 213 TB(N) in meno da acquisire per il 2018. Questi vengono spalmati sui 4 T2, e diminuiscono il delta totale 2018-2107 Corretto dopo meeting!

Situazione prevista a fine 2017 e evoluzione 2018 – T2 All In

Tier-1 Simulazione: Nessuna dismissione (come al solito – non le conosciamo) CPU e Disk al 12% di CMS Tape al 13% di CMS Corretto dopo meeting, messo tape 25 Eur/TB

Mitigations? – A livello di T2 Garantire dismissioni CPU lasciate indietro dall’anno scorso, ma ritardare quelle del 2018 stesso In pratica, stiamo assumendo che il turnover delle CPU sia 5 anni e non 4 Come gli anni scorsi, abbassare overhead (50% pare essere diventato la norma) Attenzione pero’: questo va anche bene se la Sezione aiuta, se questo avviene sempre meno Nel nuovo “corso” sulla politica di acquisti, almeno vorremmo la promessa che l’overhead venga ripristinato con gli avanzi di gara (gia’ per il 2017, peraltro…) Facendo questo si va a ….

Un paio di note 2018 cominciano le dismissioni ReCaS… magari le ritardiamo di un anno adesso, ma prima o poi arrivano … Siamo mortalmente in ritardo con i pledge 2017 (disco) 2016: siamo ok con I requirement di CMS (disco totale, disco per operazioni centrali) 2017: T1: siamo sotto di 1.9 PB, dovevano essere presenti dal 1 aprile. Quando? T2: siamo sotto di 1.8 PB. Gara in partenza, ma vista la richiesta di gara unica, sara’ lunga molti mesi Che fare? Onestamente e’ il primo anno in cui siamo in una situazione cosi’ critica …. E soprattutto: che fare per non essere nella stessa situazione nel 2018?

Conclusioni Aumento 2018 vs 2017 di CMS, da modello, molto ridotto. Molti +0%, quasi tutti i numeri con aumento a singola cifra Da molti punti di vista, cambiamenti nel modello “tirano indietro” di un anno: facciamo 2018 con risorse simili a quelle gia’ previste per il 2017, ci rimangiamo buona parte dell’aumento LHC … pero’ mettendoci dentro pledge ridotte fino al 24% rispetto al modello, anno non facile come avrebbe potuto. CMS sulla carta dovrebbe operare la transizione 12%  13%. Proponiamo di farla con calma, per il momento sulla categoria T1_Tape solamente