Projektowanie architektur systemów filtracji i akwizycji danych z wykorzystaniem modelowania w domenie zdarzeń dyskretnych Krzysztof Korcyl.

Prezentacja na temat: "Projektowanie architektur systemów filtracji i akwizycji danych z wykorzystaniem modelowania w domenie zdarzeń dyskretnych Krzysztof Korcyl."— Zapis prezentacji:

1 Projektowanie architektur systemów filtracji i akwizycji danych z wykorzystaniem modelowania w domenie zdarzeń dyskretnych Krzysztof Korcyl

2 Plan Modelowanie i symulacje – zdarzenia dyskretne Drugi poziom systemu filtracji eksperymentu ATLAS – wymagania – parametryzacja sparametryzowany model przełącznika – porównanie wyników modelowania z pomiarami w eksperymencie System budowy przypadków dla eksperymentu PANDA – wymagania – parametryzacja – wyniki symulacji Podsumowanie

3 Modelowanie i symulacje Modelowanie – iteracyjna budowa uproszczonego (sparametryzowanego) modelu przypominającego rzecz lub reprezentującego dynamikę procesu z rzeczywistego świata – w celu rozwiązania problemu – w celu głębszego poznania dynamiki procesu Odpowiedni dobór parametrów decyduje o przydatności modelu Symulacje – wielokrotne obserwacje działającego modelu Analiza/wizualizacja – interpretacja i prezentacja wyników zebranych w symulacjach – symulatory urządzeń technicznych

4 Zdarzenia dyskretne Techniki modelowania dynamiki procesu w czasie rzeczywistym – Metoda stałego kroku – Metoda zdarzeń dyskretnych Analiza stanu prowadzi do wyznaczenia nowego zdarzenia w przyszłości t t Pomiędzy zdarzeniami stan systemu nie ulega zmianie zdarzenia

5 Wdrożenie modelu Model architektury oraz komponentów napisane w języku C++ Wykorzystanie środowiska opartego o zdarzenia dyskretne wspomagającego zarządzanie czasem i współbieżnością – MODSIM (pakiet komercyjny) – Ptolemy, Ptolemy II (Java) (UC Berkeley EECS Dept.) – OPNET (pakiet komercyjny) – własny moduł (C++) zarządzania czasem Inne metodologie: – Sieci Petriego – wykorzystują teorie grafów do analitycznego wyznaczenia cech badanych programów i systemów współbieżnych niepraktyczne dla systemów o wielkiej skali

6 Organizacja systemu filtracji ATLAS

7 Modelowanie ATLAS-a - założenia Dane z detektorów: dane przypadku, po akceptacji na poziomie pierwszym, napływają do buforów ze średnią częstotliwością 100 kHz i są dostępne za pośrednictwem 160 systemów ROS (program na PC) lub ok. 500 modułów ROBIN podłączonych bezpośrednio do sieci komputerowej. System filtracji : część danych całego przypadku (1.5 MB) pobierana do przetwarzania na poziomie drugim (ROI) nie powinna przekraczać 2 %, co wyznacza 3 GB/s (1.5 MB * 0.02 * 100 kHz) jako wymaganą przepustowość sieci dla drugiego poziomu filtracji. średni czas przetwarzania przypadku nie powinien przekroczyć 40 ms co wymaga użycia 4000 rdzeni CPU; zakładając procesory ośmio-rdzeniowe oznacza to 500 komputerów PC.

8 Modelowanie ATLAS-a – założenia – c.d. System budowy przypadków: średnia częstotliwość zaakceptowanych przypadków 3.5 kHz, co wyznacza wymaganą przepustowość sieci na poziomie (3.5 kHz * 1.5 MB) 5.3 GB/s. dane zaakceptowanych przypadków będą scalane przez <100 procesorów SFI Łączna przepustowość sieci dla ruchu na drugim poziomie filtracji oraz dla systemu scalania przypadków wynosi 8.3 GB/s (3.0 GB/s + 5.3 GB/s). Architektura powinna być oparta o ogólnie dostępne komponenty (COTS) – Sieć oparta o standard Ethernet – najbardziej rozpowszechniony wraz z perspektywą rozwoju (1Gb/s, …40 Gb/s, …) – Procesy wykonywane na komputerach klasy PC pod systemem Linux

9 Generalny schemat architektury drugiego poziomu systemu filtracji

10 Parametryzacja przełącznika Hierarchiczna architektura Przesłanie między-modułowePrzesłanie wewnątrz-modułowe Model zakodowany w języku C++, współpracujący z różnymi środowiskami zarządzania czasem, oparty o 10 mierzalnych parametrów z wykorzystaniem PC i kart sieciowych: głębokość kolejek w portach wejściowych i wyjściowych przepustowość między modułem czołowym a bazowym przepływność transmisji między-modułowej i wewnątrz-modułowej stałe opóźnienie dla transmisji między-modułowej i wewnątrz-modułowej Moduł bazowy Moduł czołowy

11 Parametryzacja komponentów Modele procesów wykonywanych na komputerach PC pod systemem Linux oparte o rzeczywisty kod sparametryzowane przy pomocy znaczników czasowych w kodzie L2SV – nadzorca drugiego poziomu filtracji L2PU – proces filtrujący DFM – nadzorca systemu budowy przypadków SFI – proces scalania danych przypadku ROS – system zarządzania buforami danych (model interfejsu ROBIN)

12 Modelowanie architektur dla LVL2 i EB skalowalność (ROBIN) niezawodność liczba i typ przełączników granularność ruchu sieciowego potencjalne miejsca przeciążeń Switch basedBus based

13 Foundry EI Foundry FastIron 800 SFI(O)1 - 16 ROS19 L2P01 L2P22 ….. L2SV06 … L2SV01 pROS DFM ROS01 ROS18 … … ROS24 … … BATM T6 Konfiguracja stanowiska badawczego Kompletny system drugiego poziomu filtracji przypadków i akwizycji danych w małej skali. 24 bufory z symulowanymi danymi podłączone są do sieci systemu filtracji (L2Pxx) przez przełącznik BATM oraz do sieci budowy przypadków (SFOxx) przez przełącznik Foundry. Jednym z pomiarów jest wyznaczenie maksymalnej częstotliwości budowy przypadków w funkcji liczby procesów filtracji

14 Weryfikacja modelu poprzez symulacje stanowiska badawczego Porównanie maksymalnej częstotliwości budowy zaakceptowanych przypadków w funkcji dostępnych procesów filtracji dla stanowiska badawczego i jego modelu przy dwóch współczynnikach redukcji: 3.5% oraz 5%.

15 Symulacje dla porównania trybów pracy Wykorzystanie wyników modelowania do podjęcia decyzji o ujednoliceniu dostępu do danych dla obu systemów: filtracji i scalania danych przypadku

16 Model a rzeczywisty system Łączny czas pobierania danych od ROS przez L2PU (run 191190) Ewolucja średniego czasu oczekiwania na decyzje L2 Rozkład czasu scalania danych zaakceptowanych przypadków (run 191190) Ewolucja czasu scalania danych zaakceptowanych przypadków

17 Analiza ustawień parametrów Potencjalna możliwość wystąpienia oscylacji dla błędnie dobranych parametrów modułu DFM odpowiedzialnego za nadzór nad procesami scalania przypadków

18 Wyniki modelowania dla switch based Ustabilizowana częstotliwość budowy przypadków na poziomie 4 kHz wskazuje na stabilną pracę systemu. Symulacje wykonano dla 2% danych pobieranych do procesów filtracji i dla różnych wartości parametru liczba aktywnych zapytań (TS) wykorzystywanego przez moduły SFI w procesie budowy przypadków.

19 Detektory eksperymentu PANDA Detektory śladowe: Micro Vertex Detector Central Tracker Gas Electron Multiplier Stations Forward Tracker Identyfikacja cząstek: DIRC (Detection of Internally Reflected Cherenkov) Time of Flight System Muon Detection System Ring Imaging Cherenkov Detector Kalorymetr elektromagnetyczny Eksperyment na HESR (High Energy Storage Ring) w kompleksie FAIR (Facility for Antiproton and Ion Research ) w GSI, Darmstadt.

20 Wymagania dla systemu DAQ częstotliwość oddziaływań: 20 MHz (świetlność: 2* 10 32 cm -2 s -1 ) typ. rozmiar przypadku : ~4 kB szacunkowa przepustowość: 80 GB/s (100 GB/s) brak sprzętowego sygnału systemu filtracji moduły elektroniki pracujące w ciągłym reżimie próbkowania różnorodny program fizyczny wymaga elastyczności w doborze algorytmów filtrujących

21 Architektura push-only systemu budowy przypadków SODA Time Distribution System system pasywnych linków optycznych w formie drzewa rozsyłający informacje (zegar) od modułu głównego do kilkuset odbiorników z precyzją lepszą niż 20 ps SODA Dwupoziomowa architektura (FFE stage oraz CPU stage) systemu budowy przypadków zapewniająca połączenie pomiędzy dowolnym portem wejściowym od koncentratora danych a portem wyjściowym do komputerów farmy wykonujących procesy filtracji.

22 Kaseta ATCA oraz moduł Compute Node Moduł w standardzie ATCA zaprojektowany w Uniw. Giessen dla eksp. BESIII, HADES oraz PANDA. Wyposażony w 5 programowalnych układów FPGA f-my Xilinx (Virtex 5V4-FX60) Moduł bazowy: połączenie każdy- z-każdym (full mesh) ATCA – Advanced Telecommunications Computing Architecture

23 Projekt połączeń między-kasetowych Moduł na stanowisku N na poziomie FEE ma połączenia (dwoma światłowodami) z 4-ma modułami na stanowiskach N na poziomie CPU 416 Na poziomie FEE pakiety z nieparzystym znacznikiem są kierowane do modułu bazowego; z parzystym do odpowiedniej pary światłowodów łączącej z poziomem CPU

24 Animacja transmisji miedzy poziomami 205 366

25 Połączenia między układami FPGA Virtex Uwzględnienie w modelu połączeń pomiędzy programowalnym układami FPGA pozwala monitorować ewolucję kolejek wewnątrz FPGA oraz oszacować ilość pamięci potrzebnej na buforowanie pakietów oczekujących na dostęp do portu.

26 Budowa modelu Sparametryzowane modele komponentów w C++; SystemC jako biblioteka zarządzania czasem, współbieżnością, kanałami komunikacyjnymi oraz interfejsami: – zalety: standard otwarty, opracowany przez OSCI (Open SystemC Initiative), zaakceptowany przez IEEE (1666-2005) możliwa automatyczna konwersja modeli do języka opisu sprzętu VHDL wraz z wdrożeniem sprzętowym – wady: duża szczegółowość (zależna od stopnia sparametryzowania modeli) wymaga czasu CPU oraz dużej pamięci operacyjnej RAM symulacja 1 sec pełnej architektury PANDY zajmuje ok. 5 godzin 2.4 GHz CPU

27 Parametryzacja portów Szybkość transmisji jest parametrem – w symulacjach ustawionym na 6.5 Gb/s (RocketIO) SendFifo – może się napełniać w sytuacji wielu równoległych wpisów z płyty lub jeśli później wpisane pakiety są mniejsze od wcześniej wpisanych RecvFifo – może się napełniać jeśli pierwszy pakiet nie może być przetransmitowany z powodu zajętego portu docelowego lub gdy wcześniej przysłane pakiety mają większy rozmiar od później przysłanych.

28 Uproszczone modele Data Concentrator oraz CPU Data Concentrator (źródło danych): – wyznacza momenty interakcji z rozkładu Poisson-a o średniej częstotliwości 20 MHz oraz sumuje rozmiar pakietu danych Burst: 2 µs zderzeń przedzielone 400 ns przerwą Super-burst : 10 burstów – dokonuje konwersji 8b/10b, oznacza pakiet znacznikiem i wysyła do systemu scalania – moduł bez danych wysyła pakiet z nagłówkami CPU: – modeluje pracę procesu scalania danych oczekuje na 416 fragmentów z tym samym znacznikiem

29 Opóźnienie w systemu budowy przypadków Stała wartość opóźnienia budowy przypadków wskazuje na stabilną pracę systemu. Symulacje wykonano dla dwóch różnych wielkości przypadku wymagających odpowiednio przepustowości 100 oraz 177 GB/s oraz dla dwóch różnych liczb burstów kierowanych do tego samego portu wyjściowego architektury.

30 Rozkład obciążenia pomiędzy portami wyjściowymi architektury Port wyjściowy w poziomie CPU do którego kierowane są wszystkie fragmenty z tym samym znacznikiem czasowym wybierany jest z wykorzystaniem równania: N t+1 = mod (N t + 79), 415)

31 Monitorowanie kolejek Maksymalna zarejestrowana długość kolejek w portach wejściowych na poziomie FEE uśredniona pomiędzy portami na tej samej pozycji w różnych modułach. Po pierwszych 2-3 sekundach maks. długość nie wzrasta – fluktuacje kolejek nie wykraczają poza zarejestrowane maksima.

32 Monitorowanie obciążenia połączeń Obciążenie światłowodów łączących poziom FEE z poziomem CPU. Monitorowanie dokonywane było co 100 ms. Wszystkie światłowody są jednakowo obciążone i dla wymaganej łącznej przepustowości 100 GB/s ich wykorzystanie nie przekracza 40% nominalnej przepustowości.

33 Monitorowanie kolejek Maksymalna długość kolejek w portach wejściowych na poziomie CPU uśredniona pomiędzy portami na tej samej pozycji w różnych modułach

34 Monitorowanie obciążenia połączeń Monitorowanie obciążenia połączeń między układami Virtex na poziomie CPU Na poziomie CPU pakiety do portów nieparzystych kierowane są przez moduł bazowy do modułu z portem docelowym

35 Podsumowanie - przykłady Architektura TDAQ ATLAS-a – wyniki symulacji systemu w pełnej skali pokazały że proponowane architektury spełniają wymagania a przewidywane wydajności (opóźnienie) zostały potwierdzone przez pomiary w rzeczywistym systemie pozwoliły oszacować liczbę komponentów w pełnym systemie; umożliwiły podjęcie decyzji dotyczących organizacji i wykonywania zadań w systemie ( np. mixed – not mixed ); planowane rozszerzenie modelu do unowocześnionej architektury TDAQ pozwoli oszacować jej przydatność i wzrost wydajności; Architektura EB PANDY – wyniki symulacji systemu w pełnej skali pokazują, że proponowana architektura spełnia wymagania i zapewnia przesyłanie 100 GB/s danych (aż do ok. 170 GB/s) dostarczając kompletne przypadki do systemu filtracji dostarczają cennych informacji o wielkości buforów koniecznych do zainstalowania w projektowanym sprzęcie. model umożliwia weryfikowanie modyfikacji i oceny wpływu parametrów na wydajność.

36 Podsumowanie - modelowanie Parametryzacja jest kluczową operacją stanowiącą o przydatności modelu. – precyzyjnie sformułowane pytania pozwalają dobrać odpowiedni zestaw parametrów mających wpływ na przygotowanie modelu jakie jest opóźnienie w procesie scalania danych przypadku ? ile pamięci jest potrzebne przy buforowaniu danych oczekujących w kolejkach ? Symulacje w domenie zdarzeń dyskretnych są przydatnym narzędziem do oceny skalowalności proponowanych architektur na poziomie wymiany komunikatów. Weryfikowanie poprawności modelu dokonuje się poprzez porównanie wyników symulacji stanowisk pomiarowych i pomiarów, ale nie dają one pewności działania systemu w pełnej skali.