1ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Pavia IFAE 2006Pavia IFAE 2006Andrea Negri, UC IrvineAndrea Negri, UC Irvine
ATLAS trigger/daq ATLAS trigger/daq ArchitetturaArchitettura
Infrastruttura High Level TriggersInfrastruttura High Level Triggers
Event filter Event filter DesignDesign
Test e validazioneTest e validazione
Piani per i prossimi mesiPiani per i prossimi mesi
2ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
ATLASATLASEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
3ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
ATLASATLASEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
4ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
ATLASATLASEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
5ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Sezioni d'urto e rateSezioni d'urto e rate
Energia nel centro di massa 14 TeV
Luminosità 1034 cm2s1
Rate di collisione 40 MHz
Rate di eventi ~ 1 Ghz
Eventi sovrapposti per collisione ~ 23
Storage rate ~ 200 Hz
Event RateCollision Rate
Storage Rate
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
6ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Sezioni d'urto e rateSezioni d'urto e rate
LVL1
HLT
Energia nel centro di massa 14 TeV
Luminosità 1034 cm2s1
Rate di collisione 40 MHz
Rate di eventi ~ 1 Ghz
Eventi sovrapposti per collisione ~ 23
Storage rate ~ 200 Hz
Storage Rate
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
Event RateCollision Rate
7ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
8ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
9ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
10ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
Region Of Interest
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
11ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
12ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Level 1 triggerImplementato in Hardware
Dati a bassa granularità da calo e muon
Event FilterAccesso all'intero evento
“Seeded” dal risultato del LVL2
Algoritmi derivati dall'offline
Level 2 triggerAccesso ai dati delle sole regioni definite “di interesse” dal LVL1
Massima granularità
40 MHz
~75 kHz~2 µs
~2 kHz
~10 ms
~ 1 s
~200 Hz
Muon
ROD ROD ROD
LVL1
Calo Inner
PipelineMemories
ReadoutDrivers
RatesLatency
RoI
ATLAS T/DAQ systemATLAS T/DAQ system
LVL2
Event builder network
Storage: ~ 300 MB/s
ROBROB ROBROB ROBROB ReadoutBuffers~1600
EF farm~1000 CPUs
1 evento
ogni milioneTDAQ( )≈
EF
CM energy 14 TeV
Luminosity 1034 cm2s1
Collision rate 40 MHz
Event size ~ 1.6 MB
Detector channels ~ 108
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
13ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Software di selezione HLTSoftware di selezione HLTHLTSSW basato sullo stesso framework (Gaudi/Athena) utilizzato nell'offline
Evita duplicazioni (specie nei servizi)Semplifica gli studi di performance e validazioneEvita la comparsa di potenziali sistematiche di selezione
HLTSSW
Steering
ROB DataCollector
DataManager
HLTAlgorithms
Processing Task
Event DataModel
L2PU Appl
<<import>>
Event DataModel
Reconstr. Algorithms
<<import>>
StoreGateAthena/Gaudi
<<import>><<import>>
Event FilterHLT Core Software
Offline Core Software Offline Reconstruction
HLT AlgorithmsLVL2
Il design del codice HLTSSW garantisce la massima simmetria tra offline/onlineIl LVL2 utilizza algorithmi appositamente sviluppati per l'ambiente onlineL'EF utilizza algoritmi derivati da quelli utilizzati nell'analisi offline
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
14ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Software di selezione HLTSoftware di selezione HLTHLTSSW basato sullo stesso framework (Gaudi/Athena) utilizzato nell'offline
Evita duplicazioni (specie nei servizi)Semplifica gli studi di performance e validazioneEvita la comparsa di potenziali sistematiche di selezione
HLTSSW
Steering
ROB DataCollector
DataManager
HLTAlgorithms
Processing Task
Event DataModel
L2PU Appl
<<import>>
Event DataModel
Reconstr. Algorithms
<<import>>
StoreGateAthena/Gaudi
<<import>><<import>>
Event FilterHLT Core Software
Offline Core Software Offline Reconstruction
HLT AlgorithmsLVL2
Il design del codice HLTSSW garantisce la massima simmetria tra offline/onlineIl LVL2 utilizza algorithmi appositamente sviluppati per l'ambiente onlineL'EF utilizza algoritmi derivati da quelli utilizzati nell'analisi offline
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
15ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Software di selezione HLTSoftware di selezione HLTLa selezione è basata su step successivi
L'esito di ogni algoritmo di trigger fornisce il seed a quello successivoL'ordine nel quale gli algoritmi sono eseguiti è stabilito dallo “Steering” in base al confronto tra la configurazione (sequences objects) e il risultato del processamento (satisfied trigger conditions) Gli eventi possono essere rigettati ad ogni step (early rejection)
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
16ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Potenza di calcolo: ~ 1000 biprocessori @ 8 GHz
Richieste generali
Scalabilità, flessibilità e modularità
Indipendenza dall'HW al fine di non porre limiti all'evoluzione tecnologica
Affidabilità e “fault tolerance”
Evitare perdite di eventi e bias nel campione selezionato
Punto potenzialmente critico perchè l'EF gira algoritmi derivati dall'offline
SFI
SFO
SFI
SFO
SFI
SFO
SFI
SFO
SubFarmInput
SubFarmOutput
EFSubFarm
Infrastruttura daq Event FilterInfrastruttura daq Event FilterL'EF è organizzato in diverse Subfarm, connesse a
differenti porte di uscita dello switch di EB Possibilità di partizionare le risorse delle EF e
girare in parallelo multiple istanze di DAQ
(es.: per calibrazione e commissioning)
Event builder network
Storage
Read out system
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
17ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Potenza di calcolo: ~ 1000 biprocessori @ 8 GHz
Richieste generali
Scalabilità, flessibilità e modularità
Indipendenza dall'HW al fine di non porre limiti all'evoluzione tecnologica
Affidabilità e “fault tolerance”
Evitare perdite di eventi e bias nel campione selezionato
Punto potenzialmente critico perchè l'EF gira algoritmi derivati dall'offline
SFI
SFO
SFI
SFO
SFI
SFO
SFI
SFO
SubFarmInput
SubFarmOutput
EFSubFarm
Infrastruttura daq Event FilterInfrastruttura daq Event FilterL'EF è organizzato in diverse Subfarm, connesse a
differenti porte di uscita dello switch di EB Possibilità di partizionare le risorse delle EF e
girare in parallelo multiple istanze di DAQ
(es.: per calibrazione e commissioning)
Event builder network
Storage
Read out system
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
18ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
data processing << >>data flow
Infrastruttura DAQ Event Filter: designInfrastruttura DAQ Event Filter: designOgni nodo di processamento è connesso individualmente a SFI e SFO
SFI/SFO sono i server, i nodi di processamento i clientPermette l'inserimento dinamico (o la rimozione)
di nodi di processamento o intere subFarm
Permette l'utilizzo di subfarm
geograficamente distribuite
Possibili connessioni multiple tra client e server:
riindirizzamento dinamico nel caso di malfunzionamento di una particolare SFI
Evita “single point of failure”: un malfunzionamento di un nodo di processamento
non interferisce con le operazioni nel resto del sistema
Al fine di garantire la sicurezza dei dati in caso di problemi di processamento, il design è stato basato sul disaccoppiamento tra:
Farm remota
SFI
SFO
SFI
SFO
SFI
SFO
SFI
SFO
Event builder network
Storage
Read out system
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
19ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
data processing << >>data flow
Infrastruttura DAQ Event Filter: designInfrastruttura DAQ Event Filter: designOgni nodo di processamento è connesso individualmente a SFI e SFO
SFI/SFO sono i server, i nodi di processamento i clientPermette l'inserimento dinamico (o la rimozione)
di nodi di processamento o intere subFarm
Permette l'utilizzo di subfarm
geograficamente distribuite
Possibili connessioni multiple tra client e server:
riindirizzamento dinamico nel caso di malfunzionamento di una particolare SFI
Evita “single point of failure”: un malfunzionamento di un nodo di processamento
non interferisce con le operazioni nel resto del sistema
Al fine di garantire la sicurezza dei dati in caso di problemi di processamento, il design è stato basato sul disaccoppiamento tra:
Farm remota
SFI
SFO
SFI
SFO
SFI
SFO
SFI
SFO
Event builder network
Storage
Read out system
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
20ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
data processing << >>data flow
Infrastruttura DAQ Event Filter: designInfrastruttura DAQ Event Filter: designOgni nodo di processamento è connesso individualmente a SFI e SFO
SFI/SFO sono i server, i nodi di processamento i clientPermette l'inserimento dinamico (o la rimozione)
di nodi di processamento o intere subFarm
Permette l'utilizzo di subfarm
geograficamente distribuite
Possibili connessioni multiple tra client e server:
riindirizzamento dinamico nel caso di malfunzionamento di una particolare SFI
Evita “single point of failure”: un malfunzionamento di un nodo di processamento
non interferisce con le operazioni nel resto del sistema
Al fine di garantire la sicurezza dei dati in caso di problemi di processamento, il design è stato basato sul disaccoppiamento tra:
Farm remota
SFI
SFO
SFI
SFO
SFI
SFO
SFI
SFO
Event builder network
Storage
Read out system
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
21ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
In ogni nodo di processamento:
Le funzionalità di dataflow sono espletate
da un processo (Event Filter Dataflow) che:
Gestisce le comunicazioni con SFI e SFO
Custodisce gli eventi durante il loro transito nell'EF
Rende gli eventi disponibili alle:
Processing Tasks che eseguono, nel framework
Athena, gli algoritmi di selezione (HTLSSW)
La comunicazione tra EFD e PTs avviene tramite
un'interfaccia (PTIO) basata su unix domain socket e shared memory
Differenti implementazioni di PTIO permettono alla PT di accedere ad
eventi distribuiti dal sistema di monitoring o eventi registrati su file (debug)
Disaccoppiamento DataFlow Disaccoppiamento DataFlow DataProcessing DataProcessing
Node n
DataFlow
DataProcessing
EFD
SFO
SFI
AcceptedEvents
IncomingEvents
PT #1
PT #n
PTIOPTIO
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
22ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
In ogni nodo di processamento:
Le funzionalità di dataflow sono espletate
da un processo (Event Filter Dataflow) che:
Gestisce le comunicazioni con SFI e SFO
Custodisce gli eventi durante il loro transito nell'EF
Rende gli eventi disponibili alle:
Processing Tasks che eseguono, nel framework
Athena, gli algoritmi di selezione (HTLSSW)
La comunicazione tra EFD e PTs avviene tramite
un'interfaccia (PTIO) basata su unix domain socket e shared memory
Differenti implementazioni di PTIO permettono alla PT di accedere ad
eventi distribuiti dal sistema di monitoring o eventi registrati su file (debug)
Disaccoppiamento DataFlow Disaccoppiamento DataFlow DataProcessing DataProcessing
Node n
DataFlow
DataProcessing
EFD
SFO
SFI
AcceptedEvents
IncomingEvents
PT #1
PT #n
PTIOPTIO
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
23ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al loro ingresso nel nodo gli eventi vengono scritti in una shared
memory (sharedHeap) utilizzata per renderli disponibili alle PTs
Ogni PT, utilizzando l'interfaccia PTIO (socket)Richiede un evento
Ottiene un pointer alla porzione di sharedHeap
contenente l'evento da essere processato
(tale porzione è mappata in memoria dalla PTIO)
Processa l'evento
Comunica all'EFD l'esito della selezione
Gli eventi non possono essere corrotti dalla PT,
perchè la mappatura in memoria è read onlyE' l'EFD che gestisce lo sharedHeapSe una PT ha un crash, l'evento è ancora posseduto dall'EFD che può quindi assegnarlo ad un'altra PT o eseguire un “force accept”
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeap
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
24ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al loro ingresso nel nodo gli eventi vengono scritti in una shared
memory (sharedHeap) utilizzata per renderli disponibili alle PTs
Ogni PT, utilizzando l'interfaccia PTIO (socket)Richiede un evento
Ottiene un pointer alla porzione di sharedHeap
contenente l'evento da essere processato
(tale porzione è mappata in memoria dalla PTIO)
Processa l'evento
Comunica all'EFD l'esito della selezione
Gli eventi non possono essere corrotti dalla PT,
perchè la mappatura in memoria è read onlyE' l'EFD che gestisce lo sharedHeapSe una PT ha un crash, l'evento è ancora posseduto dall'EFD che può quindi assegnarlo ad un'altra PT o eseguire un “force accept”
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeap
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
25ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al loro ingresso nel nodo gli eventi vengono scritti in una shared
memory (sharedHeap) utilizzata per renderli disponibili alle PTs
Ogni PT, utilizzando l'interfaccia PTIO (socket)Richiede un evento
Ottiene un pointer alla porzione di sharedHeap
contenente l'evento da essere processato
(tale porzione è mappata in memoria dalla PTIO)
Processa l'evento
Comunica all'EFD l'esito della selezione
Gli eventi non possono essere corrotti dalla PT,
perchè la mappatura in memoria è read onlyE' l'EFD che gestisce lo sharedHeapSe una PT ha un crash, l'evento è ancora posseduto dall'EFD che può quindi assegnarlo ad un'altra PT o eseguire un “force accept”
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeap
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
RO map
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
26ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al loro ingresso nel nodo gli eventi vengono scritti in una shared
memory (sharedHeap) utilizzata per renderli disponibili alle PTs
Ogni PT, utilizzando l'interfaccia PTIO (socket)Richiede un evento
Ottiene un pointer alla porzione di sharedHeap
contenente l'evento da essere processato
(tale porzione è mappata in memoria dalla PTIO)
Processa l'evento
Comunica all'EFD l'esito della selezione
Gli eventi non possono essere corrotti dalla PT,
perchè la mappatura in memoria è read onlyE' l'EFD che gestisce lo sharedHeapSe una PT ha un crash, l'evento è ancora posseduto dall'EFD che può quindi assegnarlo ad un'altra PT o eseguire un “force accept”
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeap
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
RO map
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
27ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al loro ingresso nel nodo gli eventi vengono scritti in una shared
memory (sharedHeap) utilizzata per renderli disponibili alle PTs
Ogni PT, utilizzando l'interfaccia PTIO (socket)Richiede un evento
Ottiene un pointer alla porzione di sharedHeap
contenente l'evento da essere processato
(tale porzione è mappata in memoria dalla PTIO)
Processa l'evento
Comunica all'EFD l'esito della selezione
Il realtà la PT può modificare un evento Aggiungere informazioni utili all'analisi offline, o rimuovere frammenti inutilizzati (in caso di calibrazione), etcMa tali modifiche (differenze stile “cvs”) sono registrate in un'area scrivibile dello sharedHeap mentre l'evento originale non viene modificato
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeap
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
RO map
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
28ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Al fine di garantire la sicurezza dei dati anche in caso di crash
dell'EFD, lo sharedHeap è implementato come memory mapped file
Le operazioni di scrittura sono gestite direttamente dal
sistema operativo che garantisce la coerenza della
mappatura pur limitando al massimo l'I/O
In caso di crash, la nuova istanza di EFD può
recuperare gli eventi rileggendoli dallo sharedHeap e
mandarli in un speciale stream di debugging
Il sistema può essere fuori sincrono solo in caso di
problemi di alimentazione, crash del sistema operativo o rottura del disco
Questi problemi sono comunque indipendenti dalla tipologia
dell'evento e quindi non possono condurre a bias nei dati raccolti
Node n
EFD
SFO
PT #1
PTIO
PT #n
PTIO
SFI
100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111
10100110100111000101000111
Evy
SharedHeap
Evx
Evz
Sicurezza dei dati e Fault Tolerance: lo sharedHeapSicurezza dei dati e Fault Tolerance: lo sharedHeapEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
29ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
L'EFD è composto da differenti tasks interconnesse per formare un dataflow
(completamente configurabile) interno all'EFD
Dataflow basato su reference passing
Solo il pointer all'evento
(ospitato nello sharedHeap) scorre tra le tasks
Le tasks che implementano interfacce verso
componenti esterne sono eseguite da thread
indipendenti (Multi Thread design)
Al fine di assorbire latenze di comunicazione
Flessibilità e modularitàFlessibilità e modularità
Node n
EFD
SFO
PT#1
PTIO
PT#2
PTIO
SFI
Input
ExtPTs
Output Output
Trash
SFI
Input
SFO
Monitor
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
30ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
L'EFD è composto da differenti tasks interconnesse per formare un dataflow
(completamente configurabile) interno all'EFD
Dataflow basato su reference passing
Solo il pointer all'evento
(ospitato nello sharedHeap) scorre tra le tasks
Le tasks che implementano interfacce verso
componenti esterne sono eseguite da thread
indipendenti (Multi Thread design)
Al fine di assorbire latenze di comunicazione
Tale flessibiltà e modulatità permette l'aggiunta di
funzionalità addizionali e l'utiilizzo dell'EF per compiti
diversi da quelli di pura selezione e classificazione degli eventi
Flessibilità e modularitàFlessibilità e modularità
Node n
EFD
SFO
PT#1
PTIO
PT#2
PTIO
SFI
Input
Sorting
ExtPTs
ExtPTs
Output Output
Trash
SFI
Input
PT#a
PTIO
PT#b
PTIO
SFO
PT dicalibrazione
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
31ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Il sistema di Event Filter è stato validato in diverse condizioni
Test bed locali dedicati principalmente a studi
sul singolo nodo e all'integrazione degli algoritmi
Test beam dedicati all'integrazione con tutti
gli altri elementi della trigger daq
Test di scalabilità dedicati alla verifica della
robustezza e all'integrazione
Commissioning della preserie tdaq
Event Filter: test di validazione TestsEvent Filter: test di validazione TestsEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
32ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione Event Filter: test beam combinato 2004Validazione Event Filter: test beam combinato 2004
pROS
LocalLVL2 farm
Contains the LVL2 result that steers/seeds the EF processing
1010101000100010010010001000
10110LVL1calo
1010101000100010010010001000
10110LVL1mu
1010101000100010010010001000
10110RPC
1010101000100010010010001000
10110TGC
1010101000100010010010001000
10110CSC
1010101000100010010010001000
10110MDT
1010101000100010010010001000
10110Tile
1010101000100010010010001000
10110LAr
1010101000100010010010001000
10110TRT
1010101000100010010010001000
10110SCT
1010101000100010010010001000
10110Pixel
DFM
SFI
EB n
etw
ork
EF farm @ Meyrin
LocalEF farm
SFO
Remote farm @ Canada@ Poland
TRTLAr
Tilecal
MDT-RPC BOS
TRTLAr
Tilecal
MDT-RPC BOS
Gateway
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
33ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione online della catena di selezione delle segnature muoniche
(muon slice)µFast
TrigMooreTrigMooreMOOREMOORE
RPCRPC
TGCTGC
µµCTPICTPI CTPCTP
MuId SAMuId SA
MuId COMBMuId COMB
Validazione Event Filter: test beam combinato 2004Validazione Event Filter: test beam combinato 2004
pROS
LocalLVL2 farm
ROS
ROS
ROS
ROS
ROS
DFM
SFI
data
net
work
Local EF farm
LVL1LVL1 µComb
µIsol
σ = 61 µm
mm
Residuals of segments fit
in muon chambers
HLTSSW@LVL2HLTSSW@LVL2
HLTSSW@EFHLTSSW@EF
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
34ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione online della catena di selezione delle segnature muoniche
(muon slice)µFast
TrigMooreTrigMooreMOOREMOORE
RPCRPC
TGCTGC
µµCTPICTPI CTPCTP
MuId SAMuId SA
MuId COMBMuId COMB
Validazione Event Filter: test beam combinato 2004Validazione Event Filter: test beam combinato 2004
pROS
LocalLVL2 farm
ROS
ROS
ROS
ROS
ROS
DFM
SFI
data
net
work
Local EF farm
LVL1LVL1 µComb
µIsol
σ = 61 µm
mm
Residuals of segments fit
in muon chambers
HLTSSW@LVL2HLTSSW@LVL2
HLTSSW@EFHLTSSW@EF
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
35ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione online della catena di selezione delle segnature muoniche
(muon slice)µFast
TrigMooreTrigMooreMOOREMOORE
RPCRPC
TGCTGC
µµCTPICTPI CTPCTP
MuId SAMuId SA
MuId COMBMuId COMB
Validazione Event Filter: test beam combinato 2004Validazione Event Filter: test beam combinato 2004
pROS
LocalLVL2 farm
ROS
ROS
ROS
ROS
ROS
DFM
SFI
data
net
work
Local EF farm
LVL1LVL1 µComb
µIsol
σ = 61 µm
mm
Residuals of segments fit
in muon chambers
HLTSSW@LVL2HLTSSW@LVL2
HLTSSW@EFHLTSSW@EF
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
36ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione online della catena di selezione delle segnature muoniche
(muon slice)µFast
TrigMooreTrigMooreMOOREMOORE
RPCRPC
TGCTGC
µµCTPICTPI CTPCTP
MuId SAMuId SA
MuId COMBMuId COMB
Validazione Event Filter: test beam combinato 2004Validazione Event Filter: test beam combinato 2004
pROS
LocalLVL2 farm
ROS
ROS
ROS
ROS
ROS
DFM
SFI
data
net
work
Local EF farm
LVL1LVL1 µComb
µIsol
σ = 61 µm
mm
Residuals of segments fit
in muon chambers
HLTSSW@LVL2HLTSSW@LVL2
HLTSSW@EFHLTSSW@EF
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
37ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Validazione Event Filter: Test di scalabilitàValidazione Event Filter: Test di scalabilità
Year: 2001 2002 2003 2004 4/2005 7/2005
Farm size(nodes): 100 220 220 230 300/800 700
DC
Infrastructure Infrastructure
LVL2
EF EF EFLVL2EB
Integrated:
LVL2 with algorithm
EF with algorithm
HLT image
LXBATCH @ CERN5 weeks,June/July 2005
100 – 700 dual nodesfarm size increasing in steps
30 % of 30 % of Atlas TDAQAtlas TDAQ
Westgrid @ Canada
May 2005300 – 800 dual
Test dedicati alla scalabilità del sistema Verifica delle funzionalità DAQ/HLT su larga scala
Studi sulla gerarchia del sistema di Run Control esui dei tempi di transizione tra gli stati
Studi sulla granularità delle subfarm di HLT
Effetto degli algoritmi sulle performance e sulla scalabilità del sistema (es: concorrenza nell'accesso ad DB)
Installazione/distribuzione del SW sui nodi(NB: 3 release: tdaq, hlt, offline)
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
38ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Test di scalabilitàTest di scalabilitàFondamentali per l'identificazione di alcuni problemi tecnici non visibili su scale più piccole
Concorrenza nell'accesso ai servizi condivisi (es: DB)
Maturata esperienza Nell'operare a scale comparabili con a quella finale:55 ROS, 35 SFI, 110 L2PU, 350 EFD
Nell'installazione del SW tramite “file image”Contiene una versione validata e autoconsistente delle 3 release che compongono il sw di selezione: TDAQ, HLT e offline (algoritmi)Distribuito sui nodi utilizzando il protocollo BitTorrent: 2GB x 600 nodi in < 45 min
In fase di implementazione le ottimizzazioni e migliorie evidenziate da questi test Fault tolerance, monitoraggio del sistema e automazione nella gestione degli errori, sviluppo di tools per la gestione delle farm, etc
L'obiettivo è il prossimo test di scalabilità (LST) previsto per l'autunno 2006 Ultima possibilità di verifica del DAQ/HLT sw prima dello startup
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
39ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Test di scalabilitàTest di scalabilitàFondamentali per l'identificazione di alcuni problemi tecnici non visibili su scale più piccole
Concorrenza nell'accesso ai servizi condivisi (es: DB)
Maturata esperienza Nell'operare a scale comparabili con a quella finale:55 ROS, 35 SFI, 110 L2PU, 350 EFD
Nell'installazione del SW tramite “file image”Contiene una versione validata e autoconsistente delle 3 release che compongono il sw di selezione: TDAQ, HLT e offline (algoritmi)Distribuito sui nodi utilizzando il protocollo BitTorrent: 2GB x 600 nodi in < 45 min
In fase di implementazione le ottimizzazioni e migliorie evidenziate da questi test Fault tolerance, monitoraggio del sistema e automazione nella gestione degli errori, sviluppo di tools per la gestione delle farm, etc
L'obiettivo è il prossimo test di scalabilità (LST) previsto per l'autunno 2006 Ultima possibilità di verifica del DAQ/HLT sw prima dello startup
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
Integrated partitions with dummy algorithms
05
1015202530354045
0 200 400 600 800Number of hosts
Sta
rtu
p T
ran
siti
on
Tim
es (
s)
BootConfigureWarm Start
40ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Test di scalabilitàTest di scalabilitàFondamentali per l'identificazione di alcuni problemi tecnici non visibili su scale più piccole
Concorrenza nell'accesso ai servizi condivisi (es: DB)
Maturata esperienza Nell'operare a scale comparabili con a quella finale:55 ROS, 35 SFI, 110 L2PU, 350 EFD
Nell'installazione del SW tramite “file image”Contiene una versione validata e autoconsistente delle 3 release che compongono il sw di selezione: TDAQ, HLT e offline (algoritmi)Distribuito sui nodi utilizzando il protocollo BitTorrent: 2GB x 600 nodi in < 45 min
In fase di implementazione le ottimizzazioni e migliorie evidenziate da questi test Fault tolerance, monitoraggio del sistema e automazione nella gestione degli errori, sviluppo di tools per la gestione delle farm, etc
L'obiettivo è il prossimo test di scalabilità (LST) previsto per l'autunno 2006 Ultima possibilità di verifica del DAQ/HLT sw prima dello startup
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
Integrated partitions with dummy algorithms
05
1015202530354045
0 200 400 600 800Number of hosts
Sta
rtu
p T
ran
siti
on
Tim
es (
s)
BootConfigureWarm Start
41ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Preserie tdaqPreserie tdaq
1 Switch rack
128port GEth for L2+EB
1 ROS rack
12 ROS48 ROBINs
1 Full L2 rack
30 HLT PCs
PartialSuperv’r
rack3 HE PCs
Partial EFIO rack10 HE PC(6 SFI, 2
SFO, 2 DFM)
Partial EF rack
12 HLT PCs
Partial ONLINE
rack4 HLT PC
(monitoring) 2 LE PC
RoIB rack50% of RoIB
PRESERIE:PRESERIE:Fetta verticale Fetta verticale completa della completa della catena TDAQcatena TDAQ
8 racks;8 racks;10% del 10% del
sistema finalesistema finale
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
42ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Fetta verticale completa della catena di trigger daq Sono attualmente in corso studi dettagliati sulle prestazioni delle varie componenti (LVL2, Event Bulding, EventFilter) e del sistema combinato
L'obiettivo è focalizzato sull'ottimizzazione delle performance
Es: ottimizzazione del protocollo di comunicazione tra EFD e SFI
Preserie tdaqPreserie tdaqEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
43ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Fetta verticale completa della catena di trigger daq Sono attualmente in corso studi dettagliati sulle prestazioni delle varie componenti (LVL2, Event Bulding, EventFilter) e del sistema combinato
L'obiettivo è focalizzato sull'ottimizzazione delle performance
Es: effetto degli algoritmi “reali” sulle prestazioni del sistema (es: scalabilità)
Preserie tdaqPreserie tdaqEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
44ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Fetta verticale completa della catena di trigger daq Sono attualmente in corso studi dettagliati sulle prestazioni delle varie componenti (LVL2, Event Bulding, EventFilter) e del sistema combinat
L'obiettivo è focalizzato sull'ottimizzazione delle performance
CPU power: La valutazione sul numero di computer necessari nell'HLT era stata fatta assumendo l'utilizzo di biprocessori e basandosi sulla legge di Moore: 8 Ghz per cpu nel 2007
Ciò non sarà disponibile, ma i dual core sembrano garantire la necessaria scalabilitàLe performance necessarie “per PC” sembrano raggiungibili utilizzando, al posto dei previsti biprocessori, macchine con 2 unità dual core
Preserie tdaqPreserie tdaq
Scaling of a dualcore dualCPU Processor
0
100
200
300
400
500
1 2 3 4 5 6Number of Processes
Achi
eved
LVL
2 Ra
te (H
z)Series1
AMD dualcore, dual CPU @ 1.8 GHz, 4 GB
EF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
45ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Design del sistema di EF basato su
Sicurezza dei dati e fault tolerance: ottenuti attraverso l'uso di memory mapped file e il disaccoppiamento tra le operazioni di processamento e le funzionalità di data flow
Scalabilità: permettere l'inserimento/rimozione “a caldo” di risorse di processamento anche eterogenee e geograficamente distribuite
Modularità e flessibilità: permette di sfruttare il sistema anche per compiti non puramente di selezione e classificazione
Sistema validato in differenti condizioni e attualmente in fase di commissioning
Ulteriori sviluppi
Integrazione delle differenti slice di selezione: µ, e/γ, jets, etc...
Ottimizzazione dei protocolli di comunicazione
Sviluppo di tools per il monitoraggio delle farm e per automazione dell'error recovery
Sfruttamento del sistema per operazioni di calibrazione e monitoring
ConclusioniConclusioniEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ
46ANDR
EA NEGRI
, UC Irvine
– IFAE
– Pa
via 20
Apr
ile 20
06
Design del sistema di EF basato su
Sicurezza dei dati e fault tolerance: ottenuti attraverso l'uso di memory mapped file e il disaccoppiamento tra le operazioni di processamento e le funzionalità di data flow
Scalabilità: permettere l'inserimento/rimozione “a caldo” di risorse di processamento anche eterogenee e geograficamente distribuite
Modularità e flessibilità: permette di sfruttare il sistema anche per compiti non puramente di selezione e classificazione
Sistema validato in differenti condizioni e attualmente in fase di commissioning
Ulteriori sviluppi
Integrazione delle differenti slice di selezione: µ, e/γ, jets, etc...
Ottimizzazione dei protocolli di comunicazione
Sviluppo di tools per il monitoraggio delle farm e per automazione dell'error recovery
Sfruttamento del sistema per operazioni di calibrazione e monitoring
ConclusioniConclusioniEF DESIGNEF DESIGN VALIDAZIONE EFVALIDAZIONE EF CONCLUSIONICONCLUSIONIINTRODUZIONEINTRODUZIONE ATLAS TDAQATLAS TDAQ