27/5/2004 P. Morettini 1 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.

27/5/2004 P. Morettini 2 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 processori per il Detector Control. Il grosso della complessità era confinata all’elettronica custom di DAQ.

27/5/2004 P. Morettini 3 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 (~10 7 ). 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 real- time (trigger) che riconosca, in pochi millisecondi, gli eventi interessanti.

27/5/2004 P. Morettini 4 I dati rimangono sul rivelatore fino a che il trigger di primo livello non decide se accettare l’evento Ci vogliono alcuni  s. Quindi sul rivelatore ci sono buffers dimensionati in modo opportuno Struttura del DAQ di ATLAS Dopo il LVL1 accept i dati vengono estratti dai buffers e trasferiti al sistema di DAQ attraverso ~20k links ottici a Mb/s. Vengono pre-trattati da processori DSP sui ROD e parcheggiati in altri buffers (ROB) in attesa della decisione di LVL2 in 10 ms. I frammenti degli eventi accettati a LVL2 vengono assemblati, filtrati dalla FARM di event filter e, se accettati, passati al permanent storage.

27/5/2004 P. Morettini 5 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).

27/5/2004 P. Morettini 6 ROD Crate: front view ROD SBC

27/5/2004 P. Morettini 7 ROD Crate: back view Detector Control link Data output to ROS 160 MB/s Data input from FEs Mb/s

27/5/2004 P. Morettini 8 Read-Out Links and Buffers 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 potrebbero quindi comunicare 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 complessità degli switches. PCI bus ROBIN GbEthernet L2 & Event Builder Networks NIC Increased scalability if/when needed

27/5/2004 P. Morettini 9 Prototipo di ROBIN (solo receivers, niente buffers)

27/5/2004 P. Morettini 10 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.

27/5/2004 P. Morettini 11 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.

27/5/2004 P. Morettini 12 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.

27/5/2004 P. Morettini 13 ATLAS TDAQ: network connections 1600 links, 160 MB/s Aggregato 160 GB/s 500 dual 8 GHz processors 1500 dual 8 GHz processors 180 PC w 3 PCI bus 700 GEth 8 GB/s 300 GEth 5 GB/s GHz processors 1700 GEth 5 GB/s 20 8 GHz processors

27/5/2004 P. Morettini 14 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 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).

27/5/2004 P. Morettini 15 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 traficLatency vs trafic

27/5/2004 P. Morettini 16 Messaggistica del TDAQ

27/5/2004 P. Morettini 17 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.

27/5/2004 P. Morettini 18 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.

27/5/2004 P. Morettini 19 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)

27/5/2004 P. Morettini 20Conclusioni 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.