Valutazione Del Read-Out System (ROS) Del Sistema Di Acquisizione Dati Di ATLAS Candidata Valentina Ferrara Relatore Fernanda Pastore.

Presentazione sul tema: "Valutazione Del Read-Out System (ROS) Del Sistema Di Acquisizione Dati Di ATLAS Candidata Valentina Ferrara Relatore Fernanda Pastore."— Transcript della presentazione:

1 Valutazione Del Read-Out System (ROS) Del Sistema Di Acquisizione Dati Di ATLAS Candidata Valentina Ferrara Relatore Fernanda Pastore

2 Indice Sistema di trigger e di acquisizione dati di ATLAS Sistema HLT: architettura e dataflow Read-Out System e L2PUs Valutazione del Read-Out System in sistemi semplici e combinati: effetti di saturazione Scalabilità del sistema Latenza del network Conclusioni

3 Le interazioni che avvengono nel detector producono un imponente flusso di dati (con eventi di circa 2 MB) pari a 200 MB/s e circa 5 PB/year Il sistema di trigger deve selezionare ogni secondo non più di 100 eventi interessanti su ~10 9 eventi generati il trigger di ATLAS si basa su tre livelli di selezione on-line degli eventi: ogni livello raffina la decisione del livello precedente e, se necessario, applica criteri addizionali. Sistema di trigger e di acquisizione dati

4 Il trigger di primo livello (LVL1) Effettua la prima selezione on-line operando sui frammenti degli eventi e su un sottoinsieme di informazioni provenienti dal detector. Inoltre individua le zone più interessanti per ogni singolo evento (Region of Interest, RoI) corrispondenti a muoni ad alto impulso trasverso, elettroni, fotoni, tau, adroni e jets. Il tempo di latenza previsto è di ~2 μs. Durante questo tempo i dati in arrivo dal detector sono salvati in memorie pipeline É stato progettato per accettare eventi ad una rate di ~75 KHz (estendibile fino a ~100 KHz) Primo Livello Secondo Livello Terzo Livello Storage

5 High-Level Trigger Gli eventi selezionati dal trigger di primo livello sono inviati al sistema HTL, che comprende i trigger di secondo e terzo livello Secondo Livello Terzo Livello Primo Livello Storage Il trigger di secondo livello (LVL2) compie la sua selezione in pochi ms (1-10 ms) sui frammenti degli eventi utilizzando algoritmi di precisione limitata. Sugli eventi accettati da LVL2 e ricompattati (Event Building) il trigger di terzo livello (Event Filter) esegue,previa ricostruzione dellevento, lultima selezione on-line utilizzando algoritmi piú raffinati. Tempo di processamento previsto : 1 evento al secondo

6 Region of Interest (RoIs) LVL1 invia a LVL2 informazioni su regioni del detector in cui si sono verificati eventi interessanti (ad alto impulso trasverso) Le informazioni sulle RoIs viaggiano su canali dedicati LVL2 preleva dai buffer in entrata (Read-Out Buffers) solo i frammenti relativi alle RoIs degli eventi segnalati da LVL1

7 Architettura del sistema HLT drivers del detector bufferizzano i dati selezionati da LVL1 e li servono ai componenti del sistema HLT effettuano la selezione di LVL2 nodi di destinazione di EB (Event Builder): assemblano i frammenti relativi agli eventi accettati da LVL2 canali di connessione (~1600) gestisce flusso dei dati una dopo la decisione di LVL2

8 Dataflow ROS DFM SFIsL2PU L2SV 1 2 3 4 5 6 (1) 6 (2) RoI di un evento richiesta framm. invio framm. decisione sullevento rimozione eventi dai buffer ID eventi da ricostruire 7 8 richiesta framm. invio framm.

9 Read-Out System (ROSs) Sistema che si occupa di bufferizzare i frammenti degli eventi selezionati da LVL1 e di servirli ai componenti di HLT É implementato in un numero di unità individuali (~150) fissato dal numero di canali di uscita del detector (~10 7 ) Ad ogni buffer (ROB) è associato un canale (ROL) Più ROBs sono implementati su una card chiamata ROBIN più ROBIN sono implementati in un ROS Il singolo ROBIN implementa una memoria a doppio accesso: i dati arrivano dallesterno e vengono scritti sui ROBs senza impegnare la Cpu del ROS

10 L2PUs Ricevono dai supervisori L2SV i dati sulle RoIs contenenti lidentificatore dellevento ed informazioni su quanti e quali frammenti prelevare dal ROS Effettuano la selezione attraverso algoritmi che risiedono in ciascuno dei threads con cui sta lavorando la macchina Processano piú eventi in parallelo Se necessario ai fini della selezione, possono richiedere tutti gli eventi a granularità massima ed ulteriori informazioni di tipo RoI Sono Cpu di una farm che svolge le funzioni di LVL2

11 Valutazione del ROS Lo scopo è di identificare la configurazione ottimale del sistema per investigare possibili effetti di saturazione che porterebbero al rallentamento o allarresto del sistema di acquisizione dati Si è studiato il comportamento di un sistema in scala ridotta composto da un numero variabile di prototipi del sistema HLT interagenti con uno o piú ROS In un sistema ridotto come quello in analisi, si è considerata valida la relazione: che riassume in modo empirico il carico sulla CPU del ROS delle operazioni a lui richieste. Cpu ROS =Cpu EB xR EB +Cpu LVL2 xR LVL2 +Cpu cl xR cl

12

13 Saturazione di un ROS da 2 GHz Sistema 1x0xN (ROSxSFIxL2PU) R MAX = 33 Khz (no clears) 1 RoL per RoI

14 EB Sistema MxNx0 (ROSxSFIxL2PU) R MAX = 8.5 KHz/ROS (con Clear degli eventi nel ROS)

15 Valutazione delle richieste Clears Cpu LVL2 = 0.0606 GHz Cpu EB+cl = 0.2353 GHz Sistema 3x2xM (ROSxSFIxL2PU) : 5% acc R MAX = 2.56 KHz Cpu ROS =Cpu EB xR EB +Cpu LVL2 xR LVL2 +Cpu cl xR cl Cpu cl =0.0074 GHz

16 Saturazione di un ROS da 3 GHz R MAX = 55 KHz Sistema 1x0xN 1 RoL per RoI

17 Latenza del network R (LVL2)max = 33 KHz t LVL2 = 30.3 μs R (EB)max = 8.5 KHz t EB = 0.114 μs t EB = t rec + 12t f t LVL2 = t rec + t f t rec = 22.7 μs t f = 7.6 μs Il parametro che più influenza il tempo impiegato per portare a termine una richiesta sia di LVL2 che di EB è quello che dipende maggiormente dalla latenza del sistema e non in modo rilevante dalla velocità del ROS

18 Conclusioni (1) Si è visto che un ROS da 2 GHz sostiene fino a 33 KHz di richieste di LVL2 rientrando, con un ampio intervallo di sicurezza, nel limite del valore stabilito dal progetto pari a 20 KHz Si è mostrato inoltre che un ROS sostiene, entro ampi limiti di sicurezza, fino a 8.5 KHz di richieste da parte di EB (il valore di progetto è stabilito entro i 5 KHz) In base ai dati sperimentali e alla relazione di carico, si sono identificati i carichi specifici normalizzati a 1000 richieste di ogni singolo componente Questo permette di valutare in futuro il comportamento del ROS al variare del numero di richieste dei componenti di HLT e di prevedere eventuali effetti di saturazione

19 Conclusioni (2) I test effettuati hanno compreso infine lo studio della scalabilità del sistema in previsione del 2007: un ROS di 3 GHz sostiene fino a 22 KHz in più di un ROS da 2 GHz Il sistema finale del DAQ di ATLAS prevede luso di 150 ROSs (fissati dai canali dei detector) Dai nostri test, lavorando alla saturazione, si dovrebbe utilizzare una potenza di calcolo pari a 600 Cpu da 3 GHz per LVL2. Considerando la Legge di Moore e tenendo conto degli effetti degli altri componenti non presi in considerazione nei casi analizzati, nel 2007 sarebbero necessari circa 200 bi- processori da 8 GHz.