6 e l i A P E A F I ATLAS trigger/daq -...

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


4ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06


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


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


8ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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


LVL2


Storage: ~ 300 MB/s


EF farm~1000 CPUs

1 evento


EF

CM energy 14 TeV



Event size ~ 1.6 MB



9ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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


LVL2


Storage: ~ 300 MB/s


EF farm~1000 CPUs

1 evento


EF

CM energy 14 TeV



Event size ~ 1.6 MB



10ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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


LVL2


Storage: ~ 300 MB/s


EF farm~1000 CPUs

1 evento


EF

CM energy 14 TeV



Event size ~ 1.6 MB


Region Of Interest


11ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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


LVL2


Storage: ~ 300 MB/s


EF farm~1000 CPUs

1 evento


EF

CM energy 14 TeV



Event size ~ 1.6 MB



12ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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


LVL2


Storage: ~ 300 MB/s


EF farm~1000 CPUs

1 evento


EF

CM energy 14 TeV



Event size ~ 1.6 MB



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


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


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)


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)


Storage

Read out system


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)


Storage

Read out system


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


Storage

Read out system


19ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06












Farm remota

SFI

SFO

SFI

SFO

SFI

SFO

SFI

SFO


Storage

Read out system


20ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06












Farm remota

SFI

SFO

SFI

SFO

SFI

SFO

SFI

SFO


Storage

Read out system


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


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


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


24ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06







Processa l'evento





Node n

EFD

SFO

PT #1

PTIO

PT #n

PTIO

SFI

100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111

10100110100111000101000111

Evy

SharedHeap

Evx

Evz


25ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06







Processa l'evento





Node n

EFD

SFO

PT #1

PTIO

PT #n

PTIO

SFI

100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111

10100110100111000101000111

Evy

SharedHeap

Evx

Evz

RO map


26ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06







Processa l'evento





Node n

EFD

SFO

PT #1

PTIO

PT #n

PTIO

SFI

100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111

10100110100111000101000111

Evy

SharedHeap

Evx

Evz

RO map


27ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06







Processa l'evento


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


Node n

EFD

SFO

PT #1

PTIO

PT #n

PTIO

SFI

100111010100010010010001000101000111101000100101001000100101000100001000100101010111100000101110011001001001001010011010101000100010001000100100010010100010000100010010101011110000010111001100100100100101001101010100010001000101010101010100010111

10100110100111000101000111

Evy

SharedHeap

Evx

Evz

RO map


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


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


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


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


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


34ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06


(muon slice)µFast


RPCRPC

TGCTGC

µµCTPICTPI CTPCTP

MuId SAMuId SA

MuId COMBMuId COMB


pROS

LocalLVL2 farm

ROS

ROS

ROS

ROS

ROS

DFM

SFI

data

net

work

Local EF farm

LVL1LVL1 µComb

µIsol

σ = 61 µm

mm


in muon chambers


HLTSSW@EFHLTSSW@EF


35ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06


(muon slice)µFast


RPCRPC

TGCTGC

µµCTPICTPI CTPCTP

MuId SAMuId SA

MuId COMBMuId COMB


pROS

LocalLVL2 farm

ROS

ROS

ROS

ROS

ROS

DFM

SFI

data

net

work

Local EF farm

LVL1LVL1 µComb

µIsol

σ = 61 µm

mm


in muon chambers


HLTSSW@EFHLTSSW@EF


36ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06


(muon slice)µFast


RPCRPC

TGCTGC

µµCTPICTPI CTPCTP

MuId SAMuId SA

MuId COMBMuId COMB


pROS

LocalLVL2 farm

ROS

ROS

ROS

ROS

ROS

DFM

SFI

data

net

work

Local EF farm

LVL1LVL1 µComb

µIsol

σ = 61 µm

mm


in muon chambers


HLTSSW@EFHLTSSW@EF


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)


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


39ANDR

EA NEGRI

, UC Irvine

– IFAE

– Pa

via 20

Apr

ile 20

06








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








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


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


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


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


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

6 e l i A P E A F I ATLAS trigger/daq -...

Documents

Transcript of 6 e l i A P E A F I ATLAS trigger/daq -...