Computing per il DAQ di
ATLAS
Workshop CCR, Castiadas (CA)
27 Maggio 2004
Nell’ambito della CCR (come pure della CSN1) si
affronta spesso il problema dell’impatto del calcolo
per gli esperimenti LHC sull’attività nelle sezioni.
Si parla però principalmente di calcolo off-line.
Tuttavia anche l’ambito dell’on-line presenta
stimolanti problematiche di tipo strettamente
informatico che potrebbero beneficiare delle
competenze presenti nei servizi calcolo.
P. Morettini
27/5/2004
1
Il computing nel DAQ pre-LHC
Dal punto di vista del computing, il DAQ di un tipico esperimento
LEP consisteva in una cinquantina tra workstations (UNIX o VMS) e
processori FASTBUS, connessi da una rete a 10 Mb/s. A questi si
aggiungevano 20-30 processori per il Detector Control.
Il grosso della complessità era confinata all’elettronica custom di
DAQ.
P. Morettini
27/5/2004
2
Peculiarità dei DAQ di LHC
Gli esperimenti LHC devono fare i conti con tre fattori che
complicano in maniera notevole il sistema di data acquisition:
• Il rate di interazione: i fasci di LHC collidono ogni 25 ns,
ed ad ogni collisione vengono prodotte 25 interazioni
protone-protone. Prima che le particelle prodotte in una
interazione escano dal rivelatore si verifica una nuova
collisione.
• Le dimensioni del rivelatore: per ottenere la necessaria
risoluzione e copertura angolare i rivelatori per LHC sono
molto grandi. Questo implica che hanno un numero enorme
di canali indipendenti da acquisire (~107).
• La complessità degli eventi: gli eventi prodotti a LHC sono
molto complicati e nella maggior parte dei casi poco o nulla
interessanti. Serve quindi un sistema di selezione realtime (trigger) che riconosca, in pochi millisecondi, gli
eventi interessanti.
P. Morettini
27/5/2004
3
Struttura del DAQ di ATLAS
I
dati
rimangono
sul
rivelatore fino a che il
trigger di primo livello non
decide se accettare l’evento
Ci vogliono alcuni ms. Quindi
sul rivelatore ci sono buffers
dimensionati
in
modo
opportuno
Dopo il LVL1 accept i dati
vengono estratti dai buffers
e trasferiti al sistema di
DAQ attraverso ~20k links
ottici
a
40-80
Mb/s.
Vengono
I
frammenti
pre-trattati
degli eventi
da
processori aDSP
accettati
LVL2
sui vengono
ROD e
parcheggiati infiltrati
assemblati,
altri buffers
dalla
(ROB) di inevent
FARM
attesa
filter e,
della
se
decisione di LVL2
accettati,
passati
in 10 ms. al
permanent storage.
P. Morettini
27/5/2004
4
Il ROD crate
È il primo elemento del sistema di acquisizione che si trova fuori
dal rivelatore. Si tratta di un crate VME 9U che contiene 15
Read Out Drivers (RODs). Queste schede inviano configurazioni
e comandi ai front-ends, ricevono, elaborano ed assemblano i dati
provenienti dai FEs e li inviano ai Read Out Buffers attraverso
un link in fibra a 160 MB/s (ROL).
Avremo un centinaio di crates, 10k links verso il rivelatore, 20k
links dal rivelatore, 1600 links verso il DAQ.
Ogni crate possiede un Single Board Computer (SBC)
(essenzialmente una WS Linux diskless) che comunica con il
sistema di acquisizione, gestisce il trasferimento dei dati di
calibrazione e monitoring da/verso i DB servers e coordina le
attività dei RODs.
Va notato che il bus VME non viene utilizzato per il
trasferimento dati ma solo per il monitoring (qualche GB/giorno)
ed il caricamento delle configurazioni (10-50 MB per crate).
P. Morettini
27/5/2004
5
ROD Crate: front view
ROD
SBC
P. Morettini
27/5/2004
6
ROD Crate: back view
Detector
Control
link
Data output
to ROS
160 MB/s
Data input
from FEs
40-160 Mb/s
P. Morettini
27/5/2004
7
Read-Out Links and Buffers
P. Morettini
27/5/2004
ROBIN
ROBIN
ROBIN
I 1600 links che provengono dai RODs terminano in altrettanti
receivers implementati a gruppi di 3 su schede PCI a 64 bit-66
MHz dette ROBINs. Queste schede sono installate su pc detti
ROS.
Ogni ROBINs possiede abbastanza memoria per mantenere i dati
in arrivo dal rivelatore in attesa della decisione del sistema di
trigger di livello 2.
I dati in questi buffers possono venire richiesti sia dalla farm di
LVL2 sia dall’event builder. In questo caso i dati vengono
trasferiti via PCI e inviati al richiedente via GEth.
Per ridondanza anche i ROBINs
sono dotati di interfaccia GEth e
NIC
potrebbero
quindi
comunicare
PCI bus
direttamente con LVL2 e EB senza
impegnare i bus PCI del ROS. In
questo modo ci si svincola dai limiti
di throughput di PCI e si scarica il
problema di banda su una maggiore
GbEthernet
complessità degli switches.
L2 & Event Builder Networks
8
Prototipo di ROBIN
(solo receivers, niente buffers)
P. Morettini
27/5/2004
9
La Farm di Level2
Si stima siano necessari 500 bi-processori a 8 GHz
per mantenere la latenza di LVL2 sotto i 10 ms ad un
rate di input dal LVL1 di 100 kHz.
I 500 nodi saranno connessi ai 180 ROS attraverso
una switched network GEth.
Siccome i processori di LVL2 analizzano solo i dati
relativi alle “regioni di interesse” identificate al
LVL1, solo il 2-5% della banda in ingresso ai ROS
deve passare attraverso lo switch, quindi 3-8 GB/s. Il
sistema tuttavia richiede una messaggistica
complessa (identificazione dell RoI, selezione degli
algoritmi, decisione finale) e deve operare a 100 kHz
e con tempi di latenza molto bassi.
P. Morettini
27/5/2004
10
L’Event Builder
Gli eventi positivamente identificati dalla farm di
LVL2 (da 1 a 3 k al secondo) passano all’event builder
(SFI). Si tratta di un sistema di 100 single 8 GHz
processors che devono assemblare un evento completo
a partire dai 1600 frammenti presenti nei ROS.
La comunicazione tra ROS e SFI avviene attraverso
uno switch GEth da 250 porte con un aggregato di 5
GB/s.
Anche in questo caso eventuali difetti della rete,
specie in termini di latenza e di packet loss, possono
avere importanti effetti sulle prestazioni complessive
del sistema.
P. Morettini
27/5/2004
11
La Farm di Event Filter
Gli eventi costruiti dall’SFI vengono processati da
una farm di Event Filter che riduce ulteriormente il
rate a ~200 Hz.
Il tipo di processing è molto simile a quello delle farm
off-line, come pure il software di ricostruzione
usato. Per mantenere i tempi di processamento
intorno a 1 s/ev si prevede l’uso di 1500 bi-processori
a 8 GHz. È necessario un sistema di switches
adeguato ma il throughput resta intorno ai 5 GB/s.
Più critici, a questa scala, sono i problemi legati allo
scheduling in input a 3 kHz e alla availability.
Il rate di produzione di dati in uscita (che vanno
inviati al Tier 0 per lo storage) è di 30 TB al giorno.
P. Morettini
27/5/2004
12
ATLAS TDAQ: network connections
1600 links, 160 MB/s
Aggregato 160 GB/s
180 PC w 3 PCI bus
300 GEth
5 GB/s
100 8 GHz
processors
700 GEth
8 GB/s
1700 GEth
5 GB/s
500 dual 8 GHz
processors
P. Morettini
27/5/2004
1500 dual 8 GHz
processors
20 8 GHz
processors
13
Il sistema DCS
Accanto al sistema di acquisizione è necessario un sistema di controllo per
regolare e monitorare alcune centinaia di migliaia di parametri del
rivelatore (HV, LV, temperature, flussi e composizione di gas…).
Il Detector Control System utilizza la tecnologia CANbus per il
trasferimento dati dai sensori ai PC di controllo e software SCADA per il
controllo e l’archiviazione dei dati.
Sono previsti 50-70 PC per il sistema DCS, buona parte dei quali sotto
Windows (richiesto per il supporto di OPC come hardware abstraction layer
che è un prodotto basato su DCOM).
P. Morettini
27/5/2004
14
Problematiche: network
La rete è il collante dell’intero sistema di acquisizione e controllo.
Si tratta per lo più di una rete basata su hardware commerciale
e, almeno sulla carta, realizzabile con componenti già disponibili. È
tuttavia necessario controllare in modo attento le reali
prestazioni degli apparati di rete, non solo per quel che concerne
il throughput aggregato, ma anche la latenza e la percentuale di
pacchetti persi. A differenza di quanto avviene su una rete di
trasmissione dati generica qui c’è un sistema di messaggistica a
100 kHz che deve rispondere in meno di un millisecondo.
Packet loss vs trafic
P. Morettini
27/5/2004
Latency vs trafic
15
Messaggistica del TDAQ
P. Morettini
27/5/2004
16
Problematiche: system
management
Inutile dire che un sistema di 2500 nodi connessi a 3-4
switched networks pone problemi di management. Tanto più se
si pensa alla necessità di operare senza alcun tipo di
inefficienza durante il data-taking.
Il primo problema che osserviamo (lo abbiamo già al test beam
combinato) è l’installazione e la gestione centralizzata dei pc.
• Per gli SBC usiamo da tempo “root-over-NFS” e questo
richiede la manutenzione di un immagine per nodo sul
server.
• Al test beam combinato usiamo per tutti i processori una
root su ram-disk che viene passata ai nodi al boot via PXE o
etherboot assieme al kernel.
Entrambe le soluzioni sono un po’ rigide e fanno soffrire se si
devono gestire HW eterogenei e/o configurazioni differenti.
Una soluzione più flessibile potrebbe utilizzare un disco locale
come cache dei dati specifici di configurazione. C’è comunque
bisogno di sviluppo.
P. Morettini
27/5/2004
17
Problematiche: security
Ovviamente la sicurezza è un aspetto critico: un
attacco al sistema di DAQ e controllo di un
esperimento può causare non solo un blocco della presa
dati, ma anche un danneggiamento dell’ apparato e un
rischio per gli operatori (controllo delle alte tensioni,
della distribuzione dei gas etc.).
Quindi la soluzione ovvia sarebbe isolare in modo
radicale il sistema TDAQ/DCS dal modo esterno.
Tuttavia ci sono obiettive necessità di accesso remoto,
legata all’impossibilità di mantenere permanentemente
al CERN un gran numero di esperti. Sarà quindi
necessario studiare soluzioni adeguate che mantengano
elevati standard di sicurezza e al tempo stesso
possibilità di accesso e diagnostica remota.
P. Morettini
27/5/2004
18
Problematiche: monitoraggio e
fault tolerance
Un sistema informatico come quello del TDAQ/DCS di ATLAS
possiede un elevato numero di componenti critici il cui
malfunzionamento impedisce la presa dati o degrada in modo
inaccettabile le prestazioni.
Il livello di criticità è decisamente maggiore di quello dei sistemi
off-line: se il Tier0 non funziona gli esperimenti possono prendere
dati per un paio di giorni; se invece si ferma la farm di LVL2 si
ferma l’esperimento.
Sono quindi indispensabili le migliori tecnologie disponibili di:
• Network analysis (identificazione di faults, intrusioni, virus, …)
• Network and data storage redundancy
• Service redundancy (servizi di rete, disk servers, DB servers)
P. Morettini
27/5/2004
19
Conclusioni
La complessità del sistema di acquisizione e controllo
di ATLAS, come pure di ALICE, CMS ed LHCb, è
senza precedenti.
A differenza del passato, le parti critiche (e quindi
challenging e quindi divertenti) non sono limitate
all’hardware custom, sviluppato in modo specifico per
l’esperimento, ma riguardano anche le reti di
trasmissione ed acquisizione basate su componenti e
tecnologie di tipo informatico.
Sembra quindi necessario ed auspicabile un
coinvolgimento in questi progetti da parte degli
esperti del calcolo INFN.
P. Morettini
27/5/2004
20