Diplomarbeit. Konzeption und Entwicklung eines echtzeitfähigen Lastgenerators für Multimedia-Verkehrsströme in IP-basierten Rechnernetzen

Transkript

1 Universität Hamburg Department Informatik Arbeitsgruppe TKRN Telekommunikation und Rechnernetze Diplomarbeit Konzeption und Entwicklung eines echtzeitfähigen Lastgenerators für Multimedia-Verkehrsströme in IP-basierten Rechnernetzen Vorgelegt von: Studienfach: Anschrift: Andrey W. Kolesnikov Informatik Gaußstr. 192, Hamburg Erstbetreuung: Zweitbetreuung: Prof. Dr. Bernd E. Wolfinger Prof. Dr. Bernd Page Hamburg, September 2007

2

3 Kurzfassung Experimente zur Leistungsanalyse von dienstintegrierten Rechnernetzen sind stets unter Last durchzuführen. Der Einsatz von künstlichen (synthetischen) Lasten bringt hier signifikante Vorteile. Demzufolge wächst auch der Bedarf nach entsprechenden geeigneten Spezialwerkzeugen zur Lastgenerierung in existierenden Netzen. In der vorliegenden Arbeit wird eine Architektur für einen echtzeitfähigen Lastgenerator basierend auf einer dedizierten Lastspezifikationstechnik skizziert und einige zu berücksichtigende Realisierungsaspekte werden aufgezeigt. Ausgehend von einem existierenden Prototyp eines Lastgenerators (UniLoG) wird eine echtzeitfähige Version des bestehenden Lastgenerierungswerkzeuges erstellt, die ein breites Anwendungsspektrum besitzt. Der realisierte Lastgenerator wird überdies auf seine Realitätsnähe hin überprüft.

4

5 Inhaltsverzeichnis KAPITEL 1: EINFÜHRUNG MOTIVATION STAND DER BISHERIGEN FORSCHUNG... 3 GENSYN ZIELSETZUNG UND ABGRENZUNGSFRAGEN STRUKTUR UND AUFBAU DER ARBEIT... 7 KAPITEL 2: GRUNDLAGEN DER LASTGENERIERUNG EINFÜHRUNG UND BEGRIFFSDEFINITIONEN EINE FORMALE LASTBESCHREIBUNGSTECHNIK Formale Beschreibung des Lastgenerierungsprozesses Formale Beschreibung der einzelnen Aufträge ALLGEMEINE ANSÄTZE ZUR SPEZIFIKATION DER MODELLPARAMETER Einsatz von Traces Einsatz von Wahrscheinlichkeitsverteilungen MÖGLICHKEITEN FÜR DIE PARAMETRISIERUNG DER HAUPTKOMPONENTEN DER LASTBESCHREIBUNGSTECHNIK Spezifikation der Zustandsübergänge Spezifikation der Dauer von Verzögerungen in den D- und Ď-Zuständen Spezifikation der Werte für Auftragsattribute KAPITEL 3: AUSGANGSSITUATION UND RANDBEDINGUNGEN DIESER STUDIE EINE ARCHITEKTUR ZUR LASTGENERIERUNG IN RECHNERNETZEN WERKZEUG LOADSPEC ZUR SPEZIFIKATION VON LASTEN Auftragstyp WERKZEUG LOADTRAFO ZUR TRANSFORMATION VON LASTEN ANFORDERUNGEN AN EINEN ECHTZEITFÄHIGEN LASTGENERATOR KAPITEL 4: ENTWURF FÜR EINEN ECHTZEITFÄHIGEN LASTGENERATOR I -

6 4.1 ÜBERBLICK ÜBER DIE GESAMTARCHITEKTUR GENERATOR ABSTRAKTER AUFTRÄGE DER ADAPTER SICHERE KONTROLLÜBERGABE ZWISCHEN DEM GENERATOR UND DEM ADAPTER EXPERIMENTAL EVALUATION MODULE KAPITEL 5: ASPEKTE DER REALISIERUNG DES LASTGENERATORS REALISIERUNG MIT THREADS UNTER WINDOWS DER GENERATOR-THREAD DER ADAPTER-THREAD SYNCHRONISATION ZWISCHEN DEM GENERATOR-THREAD UND DEM ADAPTER- THREAD KLASSEN ZUR BESCHREIBUNG DES PARAMETRISIERTEN BVA KAPITEL 6: VALIDIERUNG DES REALISIERTEN LASTGENERATORS EXPERIMENTE MIT DEM UDP-ADAPTER Experimente mit CBR-Verkehr Experimente mit VBR-Verkehr EXPERIMENTE MIT DEM TCP-ADAPTER Experimente mit CBR-Verkehr Experimente mit VBR-Verkehr KAPITEL 7: ZUSAMMENFASSUNG UND AUSBLICK LITERATURVERZEICHNIS ANHANG A: SPEZIFIKATION DER WERKZEUGE UND TOOLS ANHANG B: FEHLERCODES VON SEND() UND SENDTO() ANHANG C: INSTALLATIONS- UND BEDIENUNGSANLEITUNG FÜR DAS LOADSPEC-TOOL II -

7 Abkürzungsverzeichnis ADAPT API BSD BVA BVG CPU E EEM ELM EQ FTP GAR GPRS GOP GUI HTTP ICMP IF IP LG LT MLLG MPEG MTU NetEmu PBVA PLM PUBA RQ S SAP SP STL SU TCP TKRN UBA UDP UMTS UniLoG VoIP VU XML ZAZ Adapter Application Programming Interface Berkeley Software Distribution Benutzerverhaltensautomat Benutzerverhaltensgraph Central Processing Unit Environment Experimental Evaluation Module Executable Load Models Event Queue File Transfer Protocol Generator for Sequences of Abstract Requests General Packet Radio Service Group of Pictures Graphic User Interface Hypertext Transfer Protocol Internet Control Message Protocol Interface Internet Protocol Lastgenerator Lasttransformator Multi-layered Load Generator Moving Picture Experts Group Maximum Transmission Unit Network Emulator Parametrisierter Benutzerverhaltensautomat Prerequisites for Load Models Parameterised User Behaviour Automaton Request Queue (Service) System Service Access Point Service Pack Standard Template Library Service User Transmission Control Protocol Telekommunikation und Rechnernetze User Behaviour Automaton User Datagram Protocol Universal Mobile Telecommunications System Unified Load Generator Voice over IP Virtual User Extensible Markup Language Zwischenankunftszeit - III -

8

9 Abbildungsverzeichnis Abbildung 2.1: Das Konzept der Last an einer wohldefinierten Schnittstelle IF betrachtet am Beispiel der Lastmodellierung für den TCP/IP- Protokollstapel Abbildung 2.2: Die Menge φ der M-Zustände und die Menge T φ der Übergänge zwischen den M-Zuständen Abbildung 2.3: Eine exemplarische Verfeinerung der Makrozustände eines BVA Abbildung 2.4: Allgemeine Vorgehensweise beim Einsatz von Traces zur Spezifikation der Lastparameter (vgl. [Lan92, S. 160]). Der Trace ist exemplarisch für die Spezifikation der Attributwerte der Aufträge r i aufbereitet Abbildung 2.5: Allgemeine Vorgehensweise beim Einsatz von Wahrscheinlichkeitsverteilungen zur Spezifikation der Lastparameter (vgl. [Lan92, S. 159]) Abbildung 2.6: Eine Sequenz von Aufträgen und Auftragstypen Abbildung 2.7: Ein BVA-Modell für eine MPEG-codierte Videosequenz unter Anwendung des GOP-Musters IBBPBB (modifiziert entnommen aus [Bai99]) Abbildung 3.1: Hauptkomponenten eines verallgemeinerten Lastgenerators UniLoG (Grobsicht der Architektur) Abbildung 3.2: Konstruktion eines exemplarischen BVA-Modells einer MPEG- Videoquelle mit GOP-Muster IBBPBB in der PLM-Komponente von LoadSpec Abbildung 3.3: Modellierung der Transformation einer MPEG-codierten Videosequenz durch die Schichten eines IP-basierten Rechnernetzes in LoadTrafo Abbildung 4.1: Architektur eines echtzeitfähigen Lastgenerators Abbildung 4.2: LG gestartet um τ 0 = 10 Uhr physikalischer Zeit; (a) Abstrakte Aufträge (t i, r i ) mit physikalischen Übergabezeitpunkten t i generiert von dem Generator zu den realen Zeitpunkten τ i ; (b) Reale Aufträge (t i, r* i ) generiert von dem Adapter zu den realen Zeitpunkten t i V -

10 Abbildung 4.3: Sichere Kontrollübergabe zwischen dem Generator und dem Adapter Abbildung 4.4: Eine mögliche Kontrollübergabe zwischen dem Generator und dem Adapter als Sequenzdiagramm in UML-Notation Abbildung 5.1: Hauptschleife des Generator-Threads Abbildung 5.2: Hauptschleife des Adapter-Threads Abbildung 5.3: Kontrollübergabe in dem Generator-Thread Abbildung 5.4: Kontrollübergabe in dem Adapter-Thread Abbildung 5.5: Klassen zur Beschreibung des parametrisierten PBVA Abbildung 6.1: Schritte bei der Validierung des realisierten verallgemeinerten Lastgenerators UniLoG Abbildung 6.2: Übergabe eines Auftrags an einer UDP- oder TCP-Schnittstelle und Messungen der faktisch erzielten Übergabezeitpunkte der Aufträge. 67 Abbildung 6.3: BVA-Modell für einen Benutzer des Transportdienstes an der UDP- Schnittstelle Abbildung 6.4: Mittlere Differenz T MEAN der spezifizierten und der faktischen Übergabezeitpunkte der UDP-Aufträge bei L 1 = 10000, L 2 = 1472, L 3 = 50 [Byte] Abbildung 6.5: λ=1666,67[pakete/s], E[ZAZ]=600[µs] Abbildung 6.6: λ=2500[pakete/s], E[ZAZ]=400[µs] Abbildung 6.7: λ=3333,33[pakete/s], E[ZAZ]=300[µs] Abbildung 6.8: λ=5000[pakete/s], E[ZAZ]=200[µs] Abbildung 6.9: λ=5555,56[pakete/s], E[ZAZ]=180[µs] Abbildung 6.10: λ=6666,67[pakete/s], E[ZAZ]=150[µs] Abbildung 6.11: λ=5000[pakete/s], E[ZAZ]=200[µs] Abbildung 6.12: λ=6666,67[pakete/s], E[ZAZ]=150[µs] Abbildung 6.13: λ=10000[pakete/s], E[ZAZ]=100[µs] Abbildung 6.14: λ=20000[pakete/s], E[ZAZ]=50[µs] Abbildung 6.15: Mittlere Differenz T MEAN der spezifizierten und der faktischen Übergabezeitpunkte der UDP-Aufträge bei L 4 = 1472 und L 5 = 50 [Byte], VBR-Verkehr VI -

11 Abbildung 6.16: BVA-Modell für einen Benutzer des Transportdienstes an der TCP- Schnittstelle Abbildung 6.17: Mittlere Differenz T MEAN der spezifizierten und der faktischen Übergabezeitpunkte der TCP-Aufträge bei L 6 = 10000[Byte], L 7 = 1460[Byte] und L 8 = 50[Byte] Abbildung 6.18: λ=3333,33[pakete/s], E[ZAZ]=300[µs] Abbildung 6.19: λ=5000[pakete/s], E[ZAZ]=200[µs] Abbildung 6.20: λ=5555,56[pakete/s], E[ZAZ]=180[µs] Abbildung 6.21: λ=6666,67[pakete/s], E[ZAZ]=150[µs] VII -

12

13 Tabellenverzeichnis Tabelle 3.1: Exemplarische Parametrisierung der Auftragsattribute und der Zwischenankunftszeiten für ein Modell einer MPEG-Videoquelle mit dem GOP-Muster IBBPBB Tabelle 3.2: Eine exemplarische Parametrisierung der elementaren Lasttransformatoren bei der Modellierung der Transformation einer MPEG-Videosequenz durch die Schichten eines IP-basierten Rechnernetzes Tabelle 6.1: Experimentserie 1, L 1 = 10000[Byte], ZAZ = [µs], τ(l 1 )~706[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.2: Experimentserie 2, L 2 = 1472[Byte], ZAZ = [µs], τ(l 2 )~54[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.3: Experimentserie 3, L 3 = 50[Byte], ZAZ = [µs], τ(l 3 )~14[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.4: Experimentserie 4, L 4 = 1472[Byte], E[ZAZ] = [µs], τ(l 4 )~54[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.5: Experimentserie 5, L 5 = 50[Byte], E[ZAZ] = [µs], τ(l 5 )~14[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.6: Experimentserie 6, L 6 = 10000[Byte], ZAZ = 5[ms] 900[µs], τ(l 6 )~706[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.7: Experimentserie 7, L 7 = 1460[Byte], ZAZ = 1[ms] 125[µs], τ(l 7 )~ 51[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.8: Experimentserie 8, L 8 = 50[Byte], ZAZ = [µs], τ(l 8 )~14[µs], Lastgenerierungsdauer 30[sek.] Tabelle 6.9: Experimentserie 9, L 9 = 1460[Byte], E[ZAZ] = [µs], τ(l 9 )~51[µs], Lastgenerierungsdauer 30[sek.] IX -

14

15 Kapitel 1 Einführung 1.1 Motivation Die Telekommunikationsbranche befindet sich seit einigen Jahren in einem rasanten Wandel, hervorgerufen durch herausragende technologische Fortschritte in der Übertragungstechnik einerseits und andererseits durch aktuelle Entwicklungen neuartiger Multimedia-Anwendungen mit immer weiter steigenden Anforderungen an Übertragungs- und Netzdienste. Eine deutliche Erhöhung der erreichbaren Datenraten in den Netzen wurde sowohl durch den Einsatz fortschrittlicher glasfaserbasierter Übertragungstechnologien als auch durch die Einführung neuer Standards erzielt, wie z.b. des Asynchronen Transfermodus (ATM) oder der aktuellen Standards für 10- Gigabit/s-Ethernet wie IEEE 802.3ae für die Glasfaserübertragung bzw. IEEE 802.3ak und IEEE 802.3an für Kupferleitungen. In derselben Zeit hat sich die Komplexität moderner Netze und Kommunikationsdienste enorm erhöht, hervorgerufen durch die kontinuierlich steigende Anzahl der Netzknoten und der Benutzer (z.b. im Internet bzw. in den Mobilnetzen), eine deutliche Tendenz zur Integration verschiedener Kommunikationsdienste sowie eine breite Vielfalt von neuartigen Anwendungen mit z. T. sehr unterschiedlichen Leistungsanforderungen (z.b. Echtzeitanforderungen). So wurden in den letzten Jahren im Rahmen der angestrebten Konvergenz verschiedener Netztechnologien in einem Netz der nächsten Generation (engl. next generation network) zahlreiche Kommunikationsdienste wie z.b. die Telephonie-, die Videokonferenz-, die Fernsehübertragungs- sowie diverse Video-On-Demand-Dienste aus den bestehenden dedizierten Netzen mit vorhandenen Dienstgütegarantien (engl. Quality of Service, QoS) in die Netze mit einer IP (Internet Protocol)-basierten (Netz-)Infrastruktur übertragen ([Cha07]). Die neueren Entwicklungen im Bereich der Web-Anwendungen ("Web 2.0", vgl. [Rei05]) erlauben es, die einzelnen Kommunikations- und Informationsdienste nicht mehr getrennt zu nutzen, sondern die Webinhalte verschiedener Dienste über offene Programmierschnittstellen nahtlos zu neuen Diensten zu verbinden (sog. Mashups ), die zu komplexeren Lasten für das zugrundeliegende Netz führen können. Die in einem Rechnernetz unterstützten Dienste und Anwendungen resultieren damit in entsprechend komplexen Lasten, die einen signifikanten Einfluss auf das Verhalten dieses Netzes haben. Der Entwurf von geeigneten Netzarchitekturen und effizienten Kommunikationsprotokollen ist daher von essentieller Bedeutung. Aus diesem Grund sind Leistungsanalysen und Verhaltensprognosen unter verschiedenen Lastszenarien in den Rechnernetzen sehr wichtig, um z.b. die potentiell möglichen (Leistungs-)Engpässe zu erkennen. Die entsprechenden Untersuchungen und Experimente zur Leistungsanalyse und Erstellung von Verhaltensprognosen in Netzen werden daher üblicherweise bei verschiedenen Belastungsniveaus durchgeführt, so dass eine geeignete Methode zur - 1 -

16 Kapitel 1 Lastmodellierung von hoher Bedeutung ist ([CaS93]). Dabei stehen insbesondere folgende Alternativen zur Auswahl: (a) Verwendung von realen Lasten (d.h. solchen Lasten, die aus bereits vorhandenen Anwendungen oder Diensten und dort typischen Operationen in einem Netz resultieren), (b) Verwendung von künstlichen (synthetischen) Lasten (d.h. solcher Lasten, die nicht aus einer typischen Operation in einem Netz resultieren, sondern zur Modellierung des Verhaltens weiterer Benutzer in dem Netz und/oder zur Generierung von dedizierten Hintergrundlasten oder Lastspitzen in das Netz eingespeist werden, vgl. [Con06]). Generell können künstliche Lasten mit verschiedenen Realitätsgraden erzeugt werden. Zur Charakterisierung künstlicher Last können z.b. Messergebnisse (insbesondere in Form von sog. Traces) verwendet werden, die aus Messungen des Verkehrs an Schnittstellen in realen Netzen gewonnen werden und somit hinreichend repräsentativ sind. Der Einsatz von Traces zur Lastcharakterisierung bei veränderten Randbedingungen ist allerdings erschwert dadurch, dass Traces meist ein bestimmtes Lastszenario darstellen und auf andere Lastsituationen bedingt bzw. gar nicht übertragbar sind. Als eine mögliche Alternative zu Traces können Lastmodelle zur Lastcharakterisierung eingesetzt werden, die mithilfe von statistischen Analysen, Abstraktions- und Aggregationstechniken aus Messungen abgeleitet werden. Dabei werden die für den gegebenen Modellierungsfall besonders relevanten Lastaspekte hervorgehoben, so dass Lastmodelle - im Vergleich zu Traces - zu einem tieferen Verständnis der Lastcharakteristika und einem höheren Erkenntnisgewinn führen können ([LMW98]). Der Einsatz von künstlichen Lasten besitzt somit gegenüber den Lasten aus einer realen Anwendung die Vorteile der Reproduzierbarkeit, Skalierbarkeit und Flexibilität in der Parametrisierung sowie einer vergleichsweise aufwandsarmen Realisierung. Die Experimente mit den Lasten wie sie von realen Anwendungen direkt erzeugt werden, sind hingegen i.d.r. mit hohen Kosten verbunden und häufig nur eingeschränkt bzw. gar nicht möglich (wenn z.b. die benötigten Anwendungen bzw. Dienste noch gar nicht existieren) ([BSc00], [SWS03]). Aus diesen Gründen werden bei Untersuchungen zur Leistungsanalyse von Netzen reale Anwendungen bzw. Dienste häufig teilweise oder vollständig durch künstliche Lasten modelliert, indem sie durch künstliche modell-basierte Lastquellen ersetzt werden. Somit ergibt sich ein Bedarf nach entsprechenden Werkzeugen zur Lastcharakterisierung und Lastgenerierung an verschiedenen Schnittstellen in Netzen. Als Generatoren künstlicher Last (engl. artificial load generators), kurz Lastgeneratoren, werden in diesem Zusammenhang solche Software- und Hardware-Komponenten bezeichnet, mit denen künstliche Lasten in einem oder mehreren Netzknoten generiert und an verschiedenen wohldefinierten Schnittstellen an das Netz übergeben werden können. Lastgeneratoren können sowohl bei der Leistungsanalyse von Netzen (z.b. zur Herstellung von speziellen Lastsituationen) als auch bei der Leistungsanalyse von verschiedenen Kommunikations- und Informationsdiensten (z.b. zur Generierung von Hintergrundlasten oder zur Modellierung des Verhaltens von realen (Dienst-)Benutzern) in Netzen eingesetzt werden. Darüber hinaus ist der Einsatz von Lastgeneratoren in verschiedenen Netzemulationsstudien (z.b. zur Modellierung der (Netz-)Benutzer) sehr - 2 -

17 Einführung nützlich, wenn das untersuchte Netz sich noch in der Entwurfs- oder Planungsphase befindet. 1.2 Stand der bisherigen Forschung Es wurden bereits verschiedene Lastgeneratoren zur Leistungsanalyse von Kommunikations- und Rechnernetzen in Industrie und Forschung vorgeschlagen. Die künstlichen Lasten, die mithilfe von solchen Lastgeneratoren generiert werden können, können sowohl nach dem angestrebten Verwendungszweck bzw. Einsatzgebiet (z.b. Testverkehr für Testumgebungen, Stress-Tests, Netzwerkanalyse, etc.) als auch nach dem Typ der generierten Aufträge (z.b. Lastgenerator für IP-Verkehr, Web-Verkehr, FTP-Verkehr, etc.) unterschieden werden. Eine mögliche Klassifikation von Lastgeneratoren nach dem Verwendungszweck des generierten Verkehrs wurde z.b. in [Con06] eingeführt: 1) Lastgeneratoren für Testverkehr Die Aufgabe von solchen Lastgeneratoren besteht in der Generierung einer Sequenz von Testaufträgen für eine spezifische beobachtete Netzumgebung oder Netzkomponente gemäß einer vorgegebenen Teststrategie oder Testszenario, z.b. wurde in [CCG04] ein Lastgenerator PackMime-HTTP für die Generierung von synthetischem HTTP-Testverkehr in dem Netzemulator ns-2 entwickelt. 2) Lastgeneratoren für Stress-Tests Die Hauptaufgaben beim Einsatz von Lastgeneratoren für sog. Massen- bzw. Stress- Tests sind die Messung von Durchsatz sowie die Ermittlung von Leistungsgrenzen und Engpässen in untersuchten Netzen. In [NTJ05] wurde z.b. ein Lastgenerator für Stress- Tests in einem UMTS/GPRS-Backbone entwickelt, in dem Dateneinheiten mithilfe von Nachrichten des GPRS Tunneling Protocols (GTP-U) ausgetauscht werden. 3) Analysatoren des Netzverkehrs Die Hauptfunktion von Analysatoren ist die Beobachtung und die Analyse des bestehenden Verkehrs während des Betriebs eines Netzwerkes. Lastgeneratoren können in solchen Tools als eine Komponente zur Generierung von verschiedenen Hintergrundlasten verwendet werden. So verfügt z.b. der Netzwerkanalysator OmniPeek ([OmP], [CAIDA]) neben den Funktionen zur Aufzeichnung und Analyse des Verkehrs ebenfalls über eine Funktion zur Lastgenerierung für IP-basierte Rechnernetze. 4) Universelle Lastgeneratoren Universelle Lastgeneratoren werden nicht für einen bestimmten Verwendungszweck oder eine spezifische Testumgebung (wie z.b. der Netzemulator ns-2) entwickelt und eignen sich meist zur Generierung von verschiedenen Typen des Verkehrs (z.b. FTP- Datentransfer, VoIP-Sprachkommunikation, Web-Verkehr, etc.) mit unterschiedlichen Realitätsgraden. Das Verhalten eines solchen universellen Lastgenerators wird meist in einem zugrunde liegenden Lastmodell spezifiziert, das aus umfangreichen (Last-)Messungen in realen Netzen abgeleitet wird. Viele verschiedene modell-basierte Lastgeneratoren zur Erzeugung von künstlichen Lasten mit verschiedenen Realitätsgraden wurden bereits vorgeschlagen, z.b. SURGE [BaC98] bzw. GISMO [JiB01], Brute [BGP05], ProWGen - 3 -

18 Kapitel 1 [BuW02], GenSyn [Hee00], MLTG [MoG03], LiTGen [RRB07], Harpoon [SoB04], MediSyn [TFCV03], von denen einige im Folgenden exemplarisch vorgestellt werden. SURGE / GISMO Ein Lastgenerator Surge (Scalable URL Reference Generator) wurde in [BaC98] für den Einsatz zur Leistungsanalyse von Web-Servern in der Anwendungsschicht entworfen und in [JiB01] als ein Tool Gismo (A Generator of Internet Streaming Media Objects and Workloads) zur Generierung von Streaming-Media-Objekten im Internet weiter entwickelt. Mithilfe von Surge können realitätsnahe Web-Verkehrslasten auf der Basis von analytischen Modellen der realen Web-Benutzer, die auf einen Web-Server zugreifen, generiert werden. Das Verhalten der einzelnen Benutzer wird durch ein sog. ON/OFF- Modell beschrieben, in dem die Dauer von aktiven Dateitransfers (hervorgerufen durch den Aufruf einer entsprechenden URL) als ON-Phasen und die inaktiven Phasen des Web-Benutzers als OFF-Phasen modelliert werden. Für die detaillierte Beschreibung des Benutzerverhaltens in den ON-Phasen werden weitere Modellparameter verwendet, wie z.b.: - Dateigröße: die Größe der Dateien bzw. Objekte auf dem Web-Server, auf die Benutzer zugreifen können, - Auftragslänge: die Größe der aufgerufenen und übertragenen Dateien bzw. Objekte (infolge eines entsprechenden URL-Aufrufs), - Popularität: die relative Häufigkeit für den Zugriff auf die einzelnen Dateien und Objekte auf dem Web-Server, - Eingebettete Verweise: Anzahl der in einem aufgerufenen Objekt enthaltenen Verweise auf andere Objekte, - Lokalität der Zugriffe: die Wahrscheinlichkeit dafür, dass ein Objekt nach einer bestimmten Zeit wieder aufgerufen wird (dieser Modellparameter wurde für die Leistungsanalyse von Cache-Funktionen in Web-Servern berücksichtigt). In Gismo [JiB01] wurde das zugrunde liegende ON/OFF-Modell der Web-Benutzer um weitere Modellparameter erweitert (wie z.b. die Popularität der Streaming-Objekte, die zeitliche Korrelation und die seasonale Abhängigkeit der Zugriffe, etc.) um einen noch höheren Realitätsgrad der generierten künstlichen Web-Verkehrslasten zu erreichen. GENSYN GenSyn wurde für QoS-Untersuchungen von neuen Anwendungen und Netzwerktechniken im Interner entwickelt und stellt ein flexibles und skalierbares Rahmenwerk für Lastmodellierung zur Verfügung [Hee00]. Das Verhalten von verschiedenen Lastquellen (wie z.b. von einer FTP-Anwendung oder von einem Benutzer eines VoIP-Kommunikationsdienstes) wurde durch einen stochastischen Markov-Prozess mit einem diskreten Zustandsraum in kontinuierlicher Zeit beschrieben. Mithilfe von speziellen Schnittstellenmodulen, die den GenSyn-Prozess an den zugrunde liegenden Internet-Protokollstapel in einem Netzknoten binden, können künstliche TCP- und UDP-Auftragsströme generiert werden. HARPOON Harpoon [SoB04] ist ein universeller Lastgenerator zur Erzeugung von realitätsnahen Verkehrslasten in IP-basierten Rechnernetzen. Mithilfe von Harpoon können gemäß - 4 -

19 Einführung einem vorgeschlagenen zweischichtigen Verkehrsmodell künstliche TCP- und UDP- Auftragsströme generiert werden, so dass die resultierenden Verkehrsströme auf der IP- Ebene bestimmte vorgegebene Charakteristika (wie z.b. die Nutzdatenlänge, die Paketanzahl und die Anzahl der gleichzeitig aktiven Verkehrsströme) aufweisen, die anhand von Messungen des realen Verkehrs in den Routern eines Netzes (z.b. im Internet) ermittelt werden. In dem zugrunde liegenden Verkehrsmodell werden solche Modellparameter wie die Dateigröße, die Zwischenankunftszeiten der einzelnen Verkehrsströme, die Adressenbereiche für die IP-Adressen des Senders und des Empfängers sowie die Anzahl der aktiven Sitzungen unterstützt. Die Werte der Modellparameter können entweder manuell spezifiziert oder aus den Verkehrsaufzeichnungen in Form von NetFlow-Logdateien ([NetFlow]) oder Packet-Traces abgeleitet und für die Konfiguration von Harpoon übernommen werden. Die Anzahl der aktiven Sitzungen kann in dem Verkehrsmodell variiert werden, um die statistischen Eigenschaften der generierten künstlichen IP-Verkehrsströme den vorgegebenen Charakteristika - über verschiedene Zeitintervalle betrachtet - anzunähern. Auf diese Weise können in Harpoon die Veränderungen im Verkehrsaufkommen in einem Netz (wie z.b. im Internet) zu verschiedenen Tageszeiten modelliert werden. Die betrachteten Lastgeneratoren sind durch einige wesentliche Einschränkungen und Nachteile gekennzeichnet (vgl. [Con06]), wie z.b.: - geringe Flexibilität bei der Erzeugung verschiedener Lastprofile (resultierend im Wesentlichen aus der starken Orientierung an einem konkreten Modellierungsfall), - fehlende Unterstützung einer formalen Lastspezifikationstechnik und einer Funktion zur Erzeugung von Lastmodellen (die bestehenden Lösungen sind häufig nur Programme, die lediglich ein bestimmtes Modell implementieren), - keine saubere Trennung zwischen der Lastbeschreibung (im Sinne einer Spezifikation der möglichen Aufträge) und der Lastgenerierung, - keine Möglichkeit zur Anpassung an die verschiedenen Netzschnittstellen und Vernachlässigung der Abhängigkeit des Benutzerverhaltens von dem Netzzustand bei der Lastmodellierung. Neben den vorgestellten Lastgeneratoren wurde bereits eine Reihe von Techniken zur formalen Spezifikation des Verhaltens von lastgenerierenden Benutzern in Rechnersystemen und Kommunikationsnetzen vorgeschlagen. Beim Entwurf von universellen modell-basierten Lastgeneratoren werden solche formalen Lastspezifikationstechniken zur Beschreibung von Lastmodellen benötigt, die bei der Lastgenerierung eingesetzt werden. DOMENICO FERRARI systematisierte in [Fer84] die methodologischen Grundlagen der Lastmodellierung und führte probabilistische Graphen (sog. Benutzerverhaltensgraphen BVG, engl. User Behaviour Graphs) zur Spezifikation von interaktiven künstlichen Lasten erstmalig ein. Ein Knoten eines BVG stellt einen Zustand eines lastgenerierenden Benutzers dar, in dem Kommandos von einem bestimmten Typ generiert werden können. Die Übergänge zwischen den Benutzerzuständen erfolgen gemäß Wahrscheinlichkeiten, die an den Kanten des BVG notiert werden. Der von Ferrari vorgeschlagene Benutzerverhaltensgraph wird nur durch die möglichen Kommandotypen und Übergangswahrscheinlichkeiten spezifiziert, während die Überga

20 Kapitel 1 bezeitpunkte der Kommandos an das System und die potentielle Abhängigkeit des Benutzerverhaltens von dem Systemzustand unberücksichtigt bleiben. CALZAROSSA und SERAZZI haben in [CaS94] Benutzerverhaltensgraphen verwendet um mithilfe von sog. Cluster-Techniken eine Vergröberung bzw. Verfeinerung der Lastmodelle durch die Aggregation bzw. Disaggregation von entsprechenden Knoten im BVG vorzunehmen. MAGOTT und WOLFINGER haben in [MaW94] eine Lastspezifikationstechnik vorgeschlagen, die auf erweiterten Petri-Netzen (genauer auf zeitbehafteten, stochastischen, gefärbten Petri-Netzen) basiert. Die vorgeschlagene Beschreibungstechnik ermöglicht die Konstruktion von komplexen Benutzermodellen mithilfe sequentieller, alternativer, iterativer oder paralleler Kombination elementarer Benutzermodelle und bietet insbesondere bei der parallelen Kombination sowie bei der Verfeinerung und Vergröberung der Lastmodelle erhebliche Vorteile. Für die Lastcharakterisierung in einem Lastgenerator erscheint dieser recht allgemeine und komplexe Ansatz allerdings als sehr aufwändig. Eine weitere formale Lastspezifikationstechnik, die an der Arbeitsgruppe TKRN in [Wol99], [Bai99] erarbeitet und in [CoW06] aktuell erweitert wurde, wird in Kapitel 2 dieser Arbeit präsentiert. 1.3 Zielsetzung und Abgrenzungsfragen Wie bei der Betrachtung der bereits existierenden Lastgeneratoren in Abschnitt 1.2 bereits erwähnt, sind die existierenden Lösungen durch eine Reihe von nicht zu vernachlässigenden Einschränkungen und Nachteilen gekennzeichnet. Aus diesem Grund wurde an der Arbeitsgruppe TKRN ein Konzept für den Entwurf eines verallgemeinerten Lastgenerators UniLoG entwickelt ([CoK05], [Con06]), in dem - verschiedene Lastmodelle mithilfe einer formalen automatenbasierten Lastspezifikationstechnik von den Benutzern des Lastgenerators erstellt werden können, - eine strukturierte Methode zur Lastspezifikation an verschiedenen Netzschnittstellen unterstützt wird, - die Lastparameter gemäß Traces oder analytischen Modellen konfiguriert werden können, - dynamische Lastgenerierung durch Berücksichtigung von netzbedingten Wartezuständen der Benutzer ermöglicht wird. Die vorliegende Arbeit ist in den Kontext der laufenden Arbeiten der Arbeitsgruppe TKRN im Bereich Traffic-Engineering eingebettet. Auf der Basis einer automatenbasierten Lastspezifikationstechnik [Wol99], [Bai99], [CoW06] soll eine in [Con06] entworfene Architektur zur Lastgenerierung in IP-basierten Rechnernetzen prototypisch realisiert werden, die eine Generierung von Multimedia-Verkehrsströmen in Echtzeit ermöglicht. Für eine solche Architektur sind funktionale Komponenten zu entwerfen sowie Schnittstellen zu definieren, die maximale Flexibilität und Leistungsfähigkeit gewährleisten. Im praktischen Teil der Arbeit sind alle entworfenen Komponenten exemplarisch zu implementieren, um die Funktionsfähigkeit der gegebenen Architektur zu zeigen. Dabei - 6 -

21 Einführung sind in dem zu entwickelnden Lastgenerator die folgenden vier Schritte des Lastgenerierungsprozesses abzubilden: (1) Eingabe eines Lastmodells für einen Benutzer an einer wohldefinierten Schnittstelle und Spezifikation der entsprechenden Modellparameter, (2) Generierung von zunächst abstrakten Aufträgen gemäß den Parametern des gewählten Lastmodells und Übergabe dieser Aufträge entsprechend den spezifizierten Übergabezeitpunkten an die auftragsausführenden Komponenten, (3) Optionale Transformation der generierten Aufträge in Aufträge an einer in der Schnittstellenhierarchie weiter unten liegenden Schnittstelle IF, die vom Experimentator zur Lastgenerierung gewählt wurde, (4) Ausführen von Aufträgen und Übergabe der generierten Lasten an das Netz. Bei der Modellierung des Verhaltens von auftragsgenerierenden Benutzern soll die Möglichkeit zur Blockierung durch netzbedingte Wartezustände in dem Lastgenerator berücksichtigt werden. Als besondere Randbedingungen werden die Anforderungen an die Leistungsfähigkeit und Präzision bei der Übergabe der generierten Auftragssequenzen an das Netz betrachtet. Die Möglichkeit zur Aggregation mehrerer Verkehrsströme in dem Lastgenerator wird als wünschenswerte Erweiterung des geplanten Entwurfs angestrebt. In der Arbeit soll ein software-basierter Ansatz für die Realisierung von Lastgeneratoren gewählt werden. Ein hardware-basierter Ansatz stellt aufgrund relativ hoher Hardwarekosten, langer Entwicklungszeiten sowie zusätzlicher Aufwendungen bei evtl. erforderlichen Aktualisierungen keine gute Alternative dar. Bei der Realisierung als Software können die Kosten für dedizierte Hardware erspart und die ggf. erforderlichen Aktualisierungen mit i.d.r. geringerem Aufwand durch Modifikationen des Quellcodes durchgeführt werden. Die Entwicklung und Validierung von Lastmodellen, die zur Spezifikation des Benutzerverhaltens in dem zu entwickelnden Lastgenerator verwendet werden, stehen nicht im Fokus der vorliegenden Arbeit. In weiteren Kapiteln werden allerdings diverse Lastmodelle zur Veranschaulichung der verwendeten Lastspezifikationstechnik sowie zur Validierung des realisierten Lastgenerators in dem experimentellen Teil exemplarisch vorgestellt. 1.4 Struktur und Aufbau der Arbeit Nach dieser Einführung werden in Kapitel 2 zunächst die grundlegenden Begriffe aus dem Gebiet der Lastmodellierung und -generierung eingeführt und erläutert. Weiter werden eine allgemeine Vorgehensweise bei der Lastgenerierung in Kommunikationsund Rechnernetzen und eine formale Methode zur Lastspezifikation präsentiert, die an verschiedenen Schnittstellen in Netzen Anwendung finden kann und zur Beschreibung von Lastmodellen in dem Lastgenerator in dieser Arbeit verwendet wurde. Danach werden die grundlegenden Verfahren zur Spezifikation von Modellparametern vorgestellt und die Anwendungsmöglichkeiten dieser Verfahren zur Parametrisierung der einzelnen Komponenten von Lastmodellen diskutiert. In Kapitel 3 wird zunächst eine auf der Basis der allgemeinen Vorgehensweise zur Lastgenerierung in Kommunikations- und Rechnernetzen in [Con06] vorgeschlagene Archi

22 Kapitel 1 tektur eines verallgemeinerten Lastgenerators UniLoG als Ausgangssituation für diese Studie vorgestellt. Die Werkzeuge LoadSpec zur Spezifikation von Lasten und LoadTrafo zur Transformation von Auftragsströmen, die zur Veranschaulichung von Einsatzmöglichkeiten der vorgeschlagenen formalen Lastbeschreibungstechnik in der Lehre entwickelt wurden und (Teil-)Realisierungen von einigen Komponenten der Architektur von UniLoG enthalten, werden in weiteren Abschnitten präsentiert. Anschließend wird die bestehende Architektur von UniLoG auf die erforderlichen Erweiterungen und Modifikationen für die Lastgenerierung in Echtzeit überprüft und die entsprechenden Anforderungen an einen neuen echtzeitfähigen Lastgenerator erarbeitet. In Kapitel 4 werden zunächst die kritischen Probleme und Einflussfaktoren einer Echtzeitumgebung aufgezeigt und die entsprechenden Lösungsansätze in dem neuen Entwurf eines Lastgenerators vorgeschlagen. Nach einem Überblick über die Gesamtarchitektur des neuen echtzeitfähigen Lastgenerators werden die einzelnen Hauptkomponenten, insbesondere der Generator von Sequenzen abstrakter Aufträge und der Adapter, detailliert betrachtet. Um eine möglichst hohe Präzision bei der Übergabe der generierten Aufträge an das Netz zu erreichen, wird eine Synchronisationsfunktion für die Steuerung der Kontrollübergabe zwischen dem Generator und dem Adapter entworfen und in einem separaten Abschnitt beschrieben. Anschließend werden die Möglichkeiten für die statistischen Auswertungen und Analysen des generierten Auftragsverkehrs in den Experimenten aufgezeigt. In Kapitel 5 wird zunächst die Entscheidung für die Realisierung des neuen Lastgenerators mithilfe von Threads unter Microsoft Windows begründet und die benötigten Betriebssystemprimitiven zur Thread- und Prozessverwaltung, Interprozesskommunikation und Synchronisation sowie die Uhrprimitiven kurz vorgestellt. Danach werden die wichtigsten Aspekte der Realisierung der einzelnen Komponenten des Lastgenerators, der Ablauf in dem Generator-Thread und in dem Adapter-Thread betrachtet und die Operationen zur Auswertung eines Benutzermodells erläutert. Die Beschreibung des verwendeten Objektmodells zur Darstellung der Komponenten eines parametrisierten Benutzermodells schließt das Kapitel ab. In Kapitel 6 werden zunächst die zu einer umfassenden Validierung des realisierten Lastgenerators notwendigen Schritte vorgestellt. Danach werden im Rahmen von verschiedenen Experimentserien systematische Analysen der Leistungsfähigkeit und der Präzision des neuen Lastgenerators in Verbindung mit dem realisierten UDP- und dem TCP-Adapter anhand von exemplarischen Modellen eines Benutzers von Transportdiensten an der UDP- bzw. TCP-Schnittstelle durchgeführt. Das abschließende siebte Kapitel enthält eine Zusammenfassung und kritische Würdigung der Resultate, die aus den Experimenten in Kapitel 6 gewonnen wurden. Im Anschluss wird ein Ausblick über die möglichen Richtungen für weitergehende Forschungsaktivitäten sowie über die geplanten Erweiterungen des realisierten Prototypen gegeben, die das UniLoG-Tool zu einem sehr praxisrelevanten Werkzeug mit einem breiten Anwendungsspektrum machen können

23 Kapitel 2 Grundlagen der Lastgenerierung Für die Gewinnung von zuverlässigen Prognosen des Verhaltens von Kommunikationssystemen und Rechnernetzen bei den Untersuchungen zwecks einer Leistungsanalyse dieser Systeme unter verschiedenen Lastszenarien ist eine hinreichend realitätsnahe Lastgenerierung von großer Bedeutung. Die Generierung von entsprechenden Lasten ist dabei sowohl für die Simulationsstudien als auch für die Messuntersuchungen in realen Netzen unter verschiedenen Randbedingungen (z.b. bei einer Kombination von künstlichen und realen Lasten) relevant. In diesem Kapitel wird eine verallgemeinerte Vorgehensweise zur Lastgenerierung basierend auf einer formalen Lastbeschreibungstechnik präsentiert, die an verschiedenen Schnittstellen in den modernen Kommunikationssystemen und Rechnernetzen Anwendung finden kann. Dafür werden zunächst in Abschnitt 2.1 die grundlegenden Begriffe aus dem Gebiet der Lastmodellierung und -generierung eingeführt und erläutert. Eine Möglichkeit zur Beschreibung des Lastgenerierungsprozesses in einem Last- bzw. Benutzermodell mithilfe einer automatenbasierten Lastbeschreibungstechnik wird in Abschnitt 2.2 präsentiert. In Abschnitt 2.3 werden die grundlegenden Verfahren zur Spezifikation von Modellparametern vorgestellt. Die Anwendungsmöglichkeiten dieser Verfahren zur Parametrisierung der einzelnen Komponenten von Lastmodellen, die zur Lastgenerierung mithilfe eines Lastgenerators in dieser Arbeit eingesetzt werden, werden in Abschnitt 2.4 diskutiert. 2.1 Einführung und Begriffsdefinitionen Der Grundbegriff der Last stellt ein fundamentales Konzept im Gebiet der Lastmodellierung und Lastgenerierung für Kommunikations- und Rechensysteme dar. In Rechensystemen wird die (Arbeits-)Last üblicherweise als die Menge aller Eingaben von Benutzern an das System betrachtet (vgl. [HaK95]). Der Lastgenerierungsprozess ist hier zurückzuführen auf das Ausführen von Programmen (einschließlich Anwendungs- und Systemprogramme) oder auf die (menschlichen) Benutzer, die bestimmte Kommandosequenzen erzeugen und sie dann an das Rechensystem übergeben. Die Programme und/oder Kommandos werden anschließend in dem System ausgeführt. Diese grundlegende Sicht bei der Lastmodellierung für herkömmliche Rechensysteme wird in [CoW04] verallgemeinert und für die Erarbeitung einer allgemeinen Vorgehensweise bei der Lastmodellierung für andere Datenverarbeitungssysteme, wie z.b. Kommunikationssysteme, Rechnernetze, Datenbanksysteme, etc., angewendet. Die meisten solchen Systeme sind nach dem Prinzip der funktionalen Schichtung aufgebaut ([Ker95], [KrR02]). Dabei werden die zusammengehörenden Funktionen jeweils in einer Schicht S N gekapselt und zusammen mit den Diensten aller darunterliegenden Schichten S N-1, S N-2,..., S 1 an Dienstzugangspunkten (engl. service access point, SAP) mithilfe von Dienstelementen (engl. service primitive) der nächsthöheren Schicht S N+1 als Dienst der Schicht S N zur Verfügung gestellt

24 Kapitel 2 Zwischen den die Aufgaben der jeweiligen Schicht implementierenden Instanzen werden dabei zwei Arten von Beziehungen unterschieden: - eine vertikale, aus der Inanspruchnahme von Diensten resultierend, und - eine horizontale, durch Kommunikationsprotokolle geregelt. Sowohl für die Protokolle jeder Schicht als auch für die von den Schichten erbrachten Dienste gibt es entsprechende Standards. Jeder Schicht-Standard enthält ein Paar aus Dienst-Spezifikation und Protokoll-Spezifikation. In der Dienst-Spezifikation werden die Art und Weise der Nutzung des Dienstes sowie die Kommunikationsabläufe an den Dienstzugangspunkten festgelegt. In der Protokoll-Spezifikation werden der zeitliche Ablauf der Kommunikation zur Realisierung eines Dienstes sowie das Format und die Semantik der auszutauschenden Dateneinheiten festgelegt. Aus diesen Gründen empfiehlt sich für die Lastmodelleirung eine (methodisch sinnvolle) Dekomposition des gesamten Datenverarbeitungssystems in ein Subsystem - im Weiteren Umgebung genannt - in dem Aufträge (z.b. Dienstelemente zur Inanspruchnahme von Kommunikationsdiensten im Fall von Rechnernetzen bzw. Transaktionen zur Manipulation von Datenobjekten im Fall von Datenbanken) durch Komponenten, die als (Dienst-)Benutzer (engl. service user, SU) bezeichnet werden, erzeugt werden. Das auftragsausführende System wird als (Bedien-)System bezeichnet, da die Ausführung von Aufträgen als Erbringung von bestimmten Diensten an die Benutzer betrachtet werden kann. Die Ausführung von Aufträgen ruft typischerweise Reaktionen hervor, die von der Umgebung beobachtet werden können (z.b. die Zustellung von Dateneinheiten an einen Empfänger in Kommunikationsnetzen bzw. die Übergabe der Ergebnisse der Ausführung einer Transaktion an einen Datenbankbenutzer, etc.). Für eine klare Abgrenzung zwischen dem Bediensystem S und der Umgebung E wird vorausgesetzt, dass S und E durch eine wohldefinierte Schnittstelle (engl. interface, IF) getrennt sind, an der Aufträge an S übergeben und Systemreaktionen von E beobachtet werden können (vgl. [CoW04]). Benutzer des Transportdienstes Umgebung E Dienstbenutzer SU 1 SU 2 SU 3 SU 4 E Aufträge VU 1,2 S IF 1 IF 2 TCP UDP Diensterbringer IF Reaktionen VU 3 IF IP Ethernet Dekomposition des Systems (Bedien-)System S Lastmodellierung VU 4 Netzwerkknoten Komponenten des Lastmodells Abbildung 2.1: Das Konzept der Last an einer wohldefinierten Schnittstelle IF betrachtet am Beispiel der Lastmodellierung für den TCP/IP-Protokollstapel

25 Grundlagen der Lastgenerierung Zur Veranschaulichung der direkten Anwendbarkeit des vorstehenden Modellierungsansatzes im Kontext moderner Rechnernetze wird eine typische Erbringung von Kommunikationsdiensten in einem Knoten eines TCP/IP-basierten Rechnernetzes betrachtet (vgl. Abb. 2.1, linker Teil). In diesem Beispiel wird die Erbringung von Nachrichtentransportdiensten von der Transportschicht (und anderen weiter unten in der Schichtenhierarchie liegenden Schichten) an der Transportdienstschnittstelle IF betrachtet. Die Komponenten der höheren Schichten werden durch die Dekomposition auf die Menge der (Dienst-)Benutzer (SUs) abgebildet. Die Menge der in der Schichtenhierarchie weiter unten liegenden Schichten (die IP- und die Ethernet-Schicht), die zusammen mit der Transportschicht den Dienst der Transportschicht erbringen, stellt das (Bedien-)System dar (vgl. Abb. 2.1, mittlerer Teil). Im Weiteren sind die (Dienst-)Benutzer an der Schnittstelle IF auf die Menge der virtuellen Benutzer (engl. virtual users, VU) abzubilden, die bereits Komponenten des entsprechenden Lastmodells repräsentieren. Dabei kann die Abbildung der SUs auf die VUs 1:1 (ein SU auf einen VU), 1:n (ein SU auf mehrere VUs) bzw. n:1 (mehrere SUs auf einen VU) in Abhängigkeit von dem Detaillierungsgrad der auszuführenden Lastmodellierung erfolgen. Durch die Abbildung von mehreren SUs auf einen VU kann beispielsweise die Superposition (die Überlagerung) der Auftragssequenzen von mehreren Benutzern im Lastmodell abgebildet werden (in der Abb. 2.1 sind beispielsweise die Dienstbenutzer SU 1 und SU 2 auf denselben virtuellen Benutzer VU 1,2 abgebildet). Zusammenfassend soll an dieser Stelle die allgemeine Definition des Grundbegriffs Last in Orientierung an [Bai99] und [Wol99] gegeben werden: Definition Die (angebotene) Arbeitslast oder Last L = L(E, S, IF, T) ist die gesamte Sequenz der Aufträge, die von Seiten der Umgebung E an ein (Bedien-)System S über die wohldefinierte Schnittstelle IF in einem Zeitintervall T übergeben werden. In der vorstehenden schnittstellenbezogenen Lastdefinition werden folgende für die Lastmodellierung in Rechnernetzen bzw. Kommunikationssystemen konzeptionell besonders wichtige Aspekte hervorgehoben: (1) Trennung des Gesamtsystems an der Schnittstelle IF in die Umgebung E (bestehend aus der Menge der lasterzeugenden Benutzer an IF) und das (Bedien-)System S (zuständig für die Bearbeitung bzw. Ausführung von Aufträgen, die von E an IF generiert werden). Die Beziehung zwischen dem (Bedien-)System S und der Umgebung E ist in der Abbildung 2.1 (rechter Teil) schematisch dargestellt. Man beachte dabei die Übergabe von Aufträgen von den VUs in E an S (bzw. Reaktionen von S an E) an der Schnittstelle IF. (2) Zeitpunktbezug der Aufträge innerhalb der Auftragssequenz. Die Last wurde als Funktion von (E, S, IF, T) definiert. Ist die Schnittstelle IF festgelegt, kann die Last als Funktion der Zeit t (t T) betrachtet und als Vektor von Tupeln (Zeitpunkt,Auftrag) dargestellt werden. Sei τ i ein Zeitpunkt (τ i R) und r i ein Auftrag (r i R, wobei R die Menge aller möglichen Aufträge an der gewählten Schnittstelle IF darstellt), so kann der entsprechende Auftragsstrom (bzw. die Auftragssequenz) an IF als ein Vektor von Tupeln X i = X(τ i ) = (τ i, r i ), i N und τ i τ j für i < j, dargestellt werden. Für die präzise und realitätsnahe Beschreibung der Last an IF werden somit Angaben bzgl. der

26 Kapitel 2 Übergabezeitpunkte τ i der Aufträge (τ i, r i ) benötigt. Die möglichen Sequenzen der an IF übergebenen Aufträge können generell aus der entsprechenden Dienst- Spezifikation (falls vorhanden) abgeleitet werden. In [Bai99], [Wol99] wurde vorgeschlagen, jeden Auftrag r i durch einen eindeutigen Auftragstyp (engl. request type) und eine Menge von Attributen, die dem Auftragstyp mit Angabe der entsprechenden Attributwerte zugeordnet sind, zu charakterisieren. (3) Abhängigkeit der Menge der zu modellierenden Auftragstypen von IF. Die Menge R der möglichen Aufträge und die Menge der möglichen Auftragstypen werden durch die Wahl der Schnittstelle IF festgelegt. Jeder Auftragstyp kann aus einem oder mehreren Auftragsattributen bestehen, die während der Ausführung eines Auftrags von diesem Auftragstyp in dem (Bedien-)System die erforderlichen Parameter angeben. Seien - R I = {RT 1, RT 2,..., RT γ } die Menge der Auftragstypen an IF (I, γ N), - A i1, A i2,..., A ij die Attribute des Auftragstyps RT i (RT i R I ), wobei j = j(i), - υ ik der Wert des Attributs A ik und - d ik die Wertedomäne (z.b. Integer, String, Real) für das Attribut A ik, 1 k j. Dann bezeichnet RT i (A i1, A i2,..., A ij ) den Auftragstyp RT i mit den zugehörigen Auftragsattributen A i1, A i2,..., A ij und r(υ i1, υ i2,..., υ ij ) bezeichnet einen bestimmten Auftrag vom Typ RT i mit den konkreten Werten υ ik für die entsprechenden Attribute A ik ( k 1 k j). (4) Betrachtung der Last in einem Zeitintervall T. Die Betrachtung der Last an der gewählten Schnittstelle zu einem Zeitpunkt ist für die Leistungsanalyse eines Kommunikationssystems offensichtlich überhaupt nicht aussagefähig. Daher werden die an der Schnittstelle IF übergebenen Aufträge stets in einem Zeitintervall T beobachtet. Die Länge dieses Zeitintervalls hängt allerdings sehr stark von der Zielsetzung des Experimentierenden ab und kann von relativ kurzen Intervallen von z.b. 10 Minuten oder 1 Stunde bis zu (vergleichsweise) sehr langen Intervallen von z.b. mehreren Tagen reichen. Untersuchungen zur Ermittlung von Leistungsgrenzen der Rechnernetze (sog. Stress-Tests) werden eher in kürzeren Beobachtungsintervallen durchgeführt. Dagegen sind die Untersuchungen des stationären Netzverhaltens mithilfe eines Netzemulators bei tendenziell längeren Beobachtungsintervallen aussagekräftig (siehe z.b. [Sch06], [RRB07] [NGKR06]). Für die Generierung von realistischen künstlichen Lasten mithilfe eines Lastgenerators ist somit eine geeignete Spezifikation des Verhaltens von Benutzern an verschiedenen Schnittstellen in Kommunikations- und Rechensystemen erforderlich, die - die möglichen Typen von Aufträgen, die von Benutzern an einer wohldefinierter Schnittstelle generiert werden, - den Auftragsankunftsprozess an IF im Zeitintervall T, d.h. die Reihenfolge und die Übergabezeitpunkte der Aufträge, - sowie den Betriebsmittelbedarf und die weiteren relevanten Attribute der Aufträge in der Beschreibung reflektieren sollte

27 Grundlagen der Lastgenerierung 2.2 Eine formale Lastbeschreibungstechnik In diesem Abschnitt soll eine formale Lastspezifikationstechnik, die an der Arbeitsgruppe TKRN in [Wol99], [Bai99] erarbeitet und in [CoW06] aktuell erweitert wurde, präsentiert werden. Eine solche Technik erlaubt die Spezifikation des Verhaltens von den einzelnen elementaren Benutzern für die Lastgenerierung. Zunächst betrachten wir die Beschreibung der Auftragsströme (z.b. die Reihenfolge und die Übergabezeitpunkte der Aufträge an einer Schnittstelle) und danach die Beschreibung der einzelnen Aufträge (z.b. die entsprechenden Auftragstypen und die zugehörigen Auftragsattribute). Anschließend werden Details der Modellierung von Auftragsströmen und die Möglichkeiten für die Parametrisierung der einzelnen Modellkomponenten präsentiert Formale Beschreibung des Lastgenerierungsprozesses Im Hinblick auf den Prozess der Auftragsgenerierung und die Kommunikationsabläufe zwischen der Umgebung und dem (Bedien-)System in realen Netzen können folgende Varianten des Benutzerverhaltens unterschieden werden (vgl. [CoW04]): - Initialisierung oder Erzeugung einer ersten Interaktion mit dem (Bedien-)System, - Generierung von Aufträgen, - Warten auf die Reaktion(en) des (Bedien-)Systems, - Terminierung der Auftragsgenerierung bzw. Beenden der Verbindung zwischen dem Benutzer und dem (Bedien-)System. Diese Varianten des Benutzerverhaltens werden im Folgenden in einem automaten-basierten Benutzermodell abgebildet. Definition Ein Benutzermodell, auch als Benutzerverhaltensautomat (BVA) bezeichnet (engl. user behaviour automaton, UBA), U = {φ i, φ a, φ b, φ t, T φ } ist ein erweiterter endlicher Automat bestehend aus der Menge der Makrozustände φ = {φ i, φ a, φ b, φ t } und der Menge T φ der Transitionen (Übergänge) zwischen diesen Makrozuständen, kurz: M-Zuständen (vgl. Abb. 2.2). ϕ a Warten auf Reaktionen Reaktionen ϕ b Auftragsgenerierung Blockierung der Auftragsgenerierung ϕ t Termination Initialisierung (nicht blockiert) ϕ i Initialisierung (zuerst blockiert) Abbildung 2.2: Die Menge φ der M-Zustände und die Menge T φ der Übergänge zwischen den M- Zuständen

28 Kapitel 2 Die einzelnen M-Zustände sind dabei wie folgt definiert: φ i : M-Zustand der Initialisierung, in dem der Benutzer vor dem Start der Lastgenerierung residiert. Der Lastgenerierungsprozess beginnt immer in diesem Zustand (wenn der BVA in einem Lastgenerator eingesetzt wird, wird φ i genau in dem Zeitpunkt verlassen, zu dem der entsprechende Lastgenerator gestartet werden soll). φ b : blockierter M-Zustand, in dem das Warten des Benutzers auf die Reaktionen des (Bedien-)Systems explizit modelliert wird. φ b kann leer sein, wenn die Abhängigkeit des Lastgenerierungsprozesses von den Reaktionen des (Bedien-)Systems nicht gegeben ist. φ a : aktiver M-Zustand, bestehend aus einer Menge von weiteren, bei Modellverfeinerung sichtbaren, Elementarzuständen, in denen Aufträge generiert werden können. φ t : terminierter M-Zustand, der Lastgenerierungsprozess wird immer in diesem Zustand beendet (wenn der BVA in einem Lastgenerator eingesetzt wird, wird beim Erreichen von φ t die weitere Auftragserzeugung in dem entsprechenden Lastgenerator sofort beendet). vom bel.rm oder Dmb ϕ b ϕ a Reaktion nach bel. Rm ϕa S a Ďca Dii R i Dij ET1 ET1 ET2 Da Nach ϕ a S c ET2 Db Dik R j ET2 ET1 Djk S b Ďcb ϕ t R k Dkj S ω von bel. Rm ϕa Dkk nach bel. Rm oder Dmn ϕa (Initialisierung) S α ϕ i Initialisierung (wenn zuerst blockiert) Abbildung 2.3: Eine exemplarische Verfeinerung der Makrozustände eines BVA. Jeder M-Zustand besteht aus einer Menge von weiteren Elementarzuständen (genannt auch LG-Zustände oder einfach Zustände), in denen das Verhalten des Benutzers weiter präzisiert werden kann. Eine detaillierte Sicht der M-Zustände ist in der Abbildung 2.3 an einem Beispiel exemplarisch dargestellt. Für die Verfeinerung der Menge der M- Zustände werden weitere Komponenten mit folgender Bedeutung eingeführt: - R-Zustände: die Zustände der Auftragsgenerierung. Jeder R-Zustand ist zuständig für die Generierung von Aufträgen exakt eines bestimmten Typs. Nach der Generierung des nächsten Auftrags wird der Zustand sofort verlassen. R-Zustände sind nur in dem aktiven M-Zustand ϕ a enthalten. - S-Zustände: die Zustände, in denen eine Blockierungssituation aufgetreten ist. Ein Ereignis muss abgewartet werden, um einen S-Zustand zu verlassen. Mögliche Erei

29 Grundlagen der Lastgenerierung gnistypen sind die Initialisierung (im einzigen Zustand S α des M-Zustands ϕ i vorkommend) und die Termination des Lastgenerierungsprozesses (im einzigen Zustand S ω des M-Zustands ϕ t vorkommend). Der dritte Ereignistyp bezieht sich auf eine Reaktion, die von dem (Bedien-)System gemeldet wird, wenn das erwartete Ereignis auftritt. Die Reaktionen können in dem blockierten M-Zustand ϕ b modelliert und interpretiert werden. Ähnlich wie bei den Aufträgen, werden die möglichen Reaktionen in Reaktionstypen ET 1, ET 2,..., ET n klassifiziert. In jedem S-Zustand innerhalb von ϕ b wird das Warten des Benutzers auf die Reaktion eines bestimmten Reaktionstyps modelliert. - D-Zustände: die nicht-unterbrechbaren Zustände zur Modellierung der Verzögerung zwischen zwei aufeinander folgenden Aufträgen in φ a (also der Zwischenankunftszeiten der Aufträge) bzw. der Zeit, die für die Verarbeitung der letzten Systemreaktion in einem der S-Zustände innerhalb von φ b benötigt wird. Die Dauer der Verzögerung ist zum Zeitpunkt des Wechsels in einen D-Zustand bekannt. Falls die Reaktion des (Bedien-)Systems in φ b einen anderen Reaktionstyp hat, als in dem entsprechenden S-Zustand erwartet, verbleibt der Benutzer weiterhin im blockierten M-Zustand φ b. - Ď-Zustände: dienen zur Modellierung derselben Arten von Verzögerungen in φ a und φ b wie die D-Zustände, können aber infolge von asynchronen (unerwarteten) Reaktionen des (Bedien-)Systems unterbrochen werden. Beim Auftreten eines entsprechenden asynchronen Ereignisses wird der aktuelle Ď-Zustand im BVA sofort verlassen und ein R- bzw. ein S-Zustand mithilfe einer Prozedur (siehe Abschnitt 2.3) zum Nachfolgerzustand gewählt. - T k : die Transitionen zwischen den R-, S-, D- und Ď-Zuständen, sowohl innerhalb eines M-Zustands als auch zwischen zwei verschiedenen M-Zuständen. Mit diesen weiteren Komponenten (Zuständen und Transitionen) können die M-Zustände φ a und φ b als Mengen der Form {R, S, D, Ď, T k } verfeinert dargestellt werden (R bezeichnet dabei die Menge der entsprechenden R-Zustände, S die Menge der S-Zustände, u.s.w.). Die Eingabedaten für einen BVA sind somit die externen Ereignisse in den S- Zuständen, welche die Systemreaktionen an den BVA signalisieren. Die Ausgabedaten des BVA liegen als eine Sequenz von Aufträgen vor, die in den R-Zuständen generiert werden. Das präsentierte BVA-Modell wird zur Beschreibung des Lastgenerierungsprozesses verwendet. Der Fortschritt dieses Prozesses erfolgt gemäß einer lokalen Zeit (im Weiteren auch logische Zeit genannt), die von der globalen Zeit (genannt auch physikalische Zeit) im realen System zu unterscheiden ist. Bei der Anwendung eines BVA-Modells zur Generierung von realen Lasten ist somit eine Konvertierung der lokalen Zeit (oder der logischen Zeit) in die globale Zeit (oder die physikalische Zeit) erforderlich. Darüber hinaus stellen die in einem BVA-Modell spezifizierten Zeiten (z.b. die Übergabezeitpunkte der Aufträge resultierend aus den Werten der Verzögerungen / Zwischenankunftszeiten in den D- und Ď-Zuständen) stets relative Zeiten dar, die für die Generierung von realen Lasten auf die absoluten Zeiten abzubilden sind. Die für diese Abbildung erforderlichen Informationen können von dem Experimentator (über die Angaben in den S-Zuständen, wie z.b. in dem Initialisierungszustand S α ) und/oder von dem jeweiligen (Bedien-)System als Reaktionen (über die Ereignisse in den blockierten S-Zuständen) geliefert werden

30 Kapitel Formale Beschreibung der einzelnen Aufträge Nachdem die Beschreibung des zu generierenden Auftragsstroms X(t) = (τ i, r i ) in einem automaten-basierten BVA-Modell präsentiert wurde, soll in diesem Abschnitt eine Methode zur formalen Beschreibung der einzelnen Aufträge r i gewählt werden. Wie bereits erläutert, wird jeder Auftrag r i durch einen eindeutigen Auftragstyp RT i (A i1, A i2,..., A ij ) und eine Menge von zugehörigen Auftragsattributen A ij mit den wohldefinierten Wertedomänen d ik, i,j,k N charakterisiert. Die Wertedomänen der Auftragsattribute können entweder durch einen der Basisdatentypen Integer, Char, Real oder durch erweiterte Datentypen (wie z.b. String, IP_Address, PortNumber, BitPattern, etc.) gegeben sein. Zur Ermittlung der möglichen Auftragstypen kann die Dienst-Spezifikation an der gewählten Schnittstelle IF als Ausgangsbasis verwendet werden, wobei nur die für den gegebenen speziellen Modellierungsfall relevanten Auftragstypen und Auftragsattribute zu berücksichtigen sind. Die Definition der Auftragstypen kann z.b. mithilfe von Strukturen erfolgen (wie dies in [CoW04] vorgeschlagen wurde). Dabei ist für jeden Auftragstyp RT i (A i1, A i2,..., A ij ) mit einer eindeutigen Auftragstypbezeichnung (bzw. Auftragstypnamen) requesttypename eine entsprechende Struktur nach dem folgenden Muster zu definieren (die Anzahl der Felder in der Struktur entspricht der Anzahl j = j(i) der zugehörigen Auftragsattribute von RT i (A i1, A i2,..., A ij )): struct requesttypename /* Name bzw. Bezeichnung des Auftragstyps*/ { }; A 1 : d 1 ; /* Auftragsattribut 1 vom Typ d 1 */ A 2 : d 2 ; /* Auftragsattribut 2 vom Typ d 2 */... A j : d j ; /* Auftragsattribut j vom Typ d j */ Für die Erzeugung eines neuen Auftrags r i vom Typ RT i (mit der eindeutigen Bezeichnung requesttypename) im Lastgenerierungsprozess ist zunächst eine neue Instanz der entsprechenden Struktur requesttypename zu erzeugen. Nach der Belegung der Felder der neuen Instanz mit den konkreten Werten υ ik für die entsprechenden Attribute A ik ( k 1 k j) ist der neue Auftrag r i (υ i1, υ i2,..., υ ij ) vom Typ RT i vorbereitet. Zur Veranschaulichung soll hier die Modellierung von Aufträgen an einen verbindungslosen Dienst der Transportschicht (erbracht z.b. mithilfe des UDP-Protokolls) in einem Knoten eines TCP/IP-basierten Rechnernetzes präsentiert werden. Der entsprechende Auftragstyp habe für das BVA-Modell eine eindeutige Auftragstypbezeichnung SEND_DATA: struct SEND_DATA /* Name bzw. Bezeichnung des Auftragstyps*/ { }; source_addr : IP_Address; /* Name bzw. Adresse des Senders */ dest_addr : IP_Address; /* Name bzw. Adresse des Empfängers */ data_len : Integer; /* Länge zu übermittelnden Nutzdaten */ Die Attribute source_addr und dest_addr enthalten jeweils die IP-Adressen des Sender- und des Empfänger-Knotens, die Länge der durch das Transportsystem zu übertragenden (Nutz-)Dateneinheit wird im Attribut data_len festgelegt

31 Grundlagen der Lastgenerierung 2.3 Allgemeine Ansätze zur Spezifikation der Modellparameter In den vorangehenden Abschnitten 2.1. und 2.2 wurden Ansätze zur Spezifikation des zu generierenden Auftragsstroms (durch einen BVA) sowie der einzelnen Aufträge skizziert. Zur Vervollständigung der präsentierten Lastbeschreibungstechnik sind noch weitere Details (insbesondere die Möglichkeiten für die Parametrisierung) der einzelnen Modellkomponenten festzulegen. Bevor diese Detailentscheidungen getroffen werden können, werden zunächst in diesem Abschnitt die grundlegenden Verfahren zur Parameterspezifikation mit ihren Vor- und Nachteilen vorgestellt. Danach werden im nächsten Abschnitt 2.4 die Anwendungsmöglichkeiten dieser Verfahren für die Parametrisierung der Hauptkomponenten der Lastbeschreibungstechnik präsentiert. Bei der Spezifikation von Modellparametern unterscheidet z.b. [Lan92] im Allg. zwischen den Verfahren, die mit repräsentativen (d.h. aus Messungen an einer realen Anwendungsschnittstelle resultierenden) Daten operieren, von den Verfahren, die mit zufälligen (z.b. gemäß einer Verteilung generierten) Daten arbeiten. Die Wahl einer geeigneten Methode zur Parametrisierung der Modellkomponenten ist generell stark abhängig von der Zielsetzung des Experimentierenden. Im Idealfall sollte diese Wahl für jede einzelne Komponente des Benutzermodells (d.h. für jedes einzelne Auftragsattribut, jeden einzelnen Verzögerungszustand, etc.) getroffen werden können (z.b. können die Werte der Auftragsattribute source_addr, dest_addr und data_len des Auftragstyps SEND_DATA aus Abschnitt aus einem Trace und die Zwischenankunftszeiten der Aufträge SEND_DATA gemäß einer Verteilung spezifiziert werden). Durch die Kombination von verschiedenen Methoden zur Parameterspezifikation kann ein hoher Grad an Universalität und Realitätsnähe des erstellten Benutzermodells erreicht werden. Im Folgenden wird zunächst der Einsatz von Traces zur Spezifikation der Lastparameter vorgestellt, dabei wird auf die Vor- und Nachteile der Technik eingegangen. Danach wird der Einsatz von Verteilungen präsentiert, gängige Verteilungen (im Zusammenhang mit Lastmodellierung) werden definiert und die Generierung der Folgen von Zufallszahlen gemäß diesen Verteilungen erläutert Einsatz von Traces Eine exakte Protokollierung (z.b. durch Messmonitore) der Aufträge, die von einer realen Anwendung an einer betrachteten Schnittstelle übergeben werden, und die Verwendung der gemessenen Werte zur Spezifikation der Parameter eines entsprechenden Modells dieser Anwendung ist eine gängige Methode in der Praxis der Simulation (z.b. [Pag91], [Lan92]) und der Lastmodellierung (z.b. [Bai99], [Con06], [RRB07]). Das Ergebnis von Messungen ist zunächst eine zeitlich geordnete Folge von Ereignissen (allg. Zustandsänderungen), die in einer Spurverfolgungsdatei (engl. Trace) gespeichert ist. Der auf diese Weise gewonnene Trace wird in ggf. aufbereiteter Form in einer Trace-Datei oder einer Datenbank gespeichert und kann für die Spezifikation verschiedener Parameter des Benutzermodells beim Einsatz in einem Lastgenerator verwendet werden. Die allgemeine Vorgehensweise bei diesem Trace-basierten Ansatz ist in der Abbildung 2.4 schematisch dargestellt (vgl. [Lan92, S. 160]). Dabei wurde eine exemplarische Aufbereitung der Daten für die Spezifikation der Werte von Auftragsattributen der Aufträge r i skizziert

32 Kapitel 2 Messungen an einem realen System Auswahlregeln Spurverfolgungsdaten (Trace-Datei) Aufbereitung (Selektionsfilter, Aufteilung) Gespeicherte Eingabedaten (Aufträge und Attribute) r1 r2 r3, Lastgenerator Auftragsstrom X(t) = (τi,ri) Abbildung 2.4: Allgemeine Vorgehensweise beim Einsatz von Traces zur Spezifikation der Lastparameter (vgl. [Lan92, S. 160]). Der Trace ist exemplarisch für die Spezifikation der Attributwerte der Aufträge r i aufbereitet. Die geeignete Methode zur Aufbereitung des ursprünglichen Rohdatenmaterials ist von dem gesetzten Ziel der Untersuchung abhängig. Oftmals wird eine Vergröberung des Trace vorgenommen, indem einige für die Untersuchung irrelevante Parameter 1 weggelassen werden (siehe z.b. [Bai99], [RRB07]). Für die Lastmodellierung kann eine Aufteilung des gesamten Datenbestands in mehrere Traces nützlich sein (z.b. jeweils ein Trace für Aufträge eines bestimmten Auftragstyps). Nach der Aufbereitung stehen die relevanten Daten in den Zeilen einer entsprechenden Trace-Datei zur Verfügung, die zur Spezifikation der Lastparameter in einem BVA-Modell verwendet werden kann. Der Einsatz von Traces kann eine sehr realitätsnahe Methode zur Spezifikation der Lastparameter darstellen, sofern die repräsentativen Daten aus Messungen an realen Schnittstellen in existierenden Rechnernetzen oder Kommunikationssystemen gewonnen werden. Weitere Vorteile dieser Methode sind: Reproduzierbarkeit der Experimentergebnisse: Das Verhalten des Modells wird durch den Trace vollständig deterministisch festgelegt. Wiederholung der Experimente zur Lastgenerierung führt somit bei konstanter Parametrisierung stets zu gleichen Ergebnissen. Geringer Erstellungsaufwand: Die für die Erstellung von Traces erforderlichen Messwerkzeuge sind für heutige Rechnernetze leicht verfügbar. Das können sowohl die Hardware-Netzwerkanalysatoren (verfügbar von zahlreichen Herstellern in der Industrie) als auch die Software-Netzwerkanalysatoren wie z.b. Ethereal (siehe [Ethereal]) sein. Geringer Berechnungsaufwand: Die Daten aus den aufbereiteten Traces können i.d.r. ohne weitere Verarbeitung bei der Lastgenerierung verwendet werden. Dadurch beschränkt sich der Betriebsmittelbedarf während der Auswertung des Lastmodells im Lastgenerator lediglich auf den Speicherplatzbedarf für die erfassten Werte und die für den Zugriff auf den nächsten Wert durchschnittlich benötigte Rechenzeit. Allerdings besitzen die Trace-basierten Verfahren eine ganze Reihe von nicht vernachlässigbaren Nachteilen (siehe z.b. [Lan92] oder [Büh00] für weitere Analysen): 1 Ggf. können die in den Trace eingeflossenen externen Informationen (wie z.b. Statusmeldungen der Protokolle, Konfigurationsoptionen des Systems) aber auch die für den gegebenen Modellierungsfall nicht relevanten Aufträge solche irrelevante Parameter sein

33 Grundlagen der Lastgenerierung Das reale System muss existieren: Die Trace-basierten Verfahren operieren mit Ergebnissen der Messungen am realen Kommunikationssystem bzw. Rechnernetz, welches dann bereits vorhanden sein muss. Darüber hinaus muss die beobachtete Schnittstelle zugänglich und das System für die gesamte Dauer der Messungen verfügbar sein. Keine Berücksichtigung des dynamischen Verhaltens der Benutzer: Trace-basierte Verfahren sind in ihrer Natur statisch, d.h. es besteht keine Möglichkeit zur Berücksichtigung einer Reaktion des Benutzers auf veränderte Systemzustände. Insbesondere bei kontinuierlichen Medien (z.b. PCM-codierten Audiosequenzen oder MPEG-codierten Videosequenzen) ist es häufig der Fall, dass die Anwendung die generierte Last an die momentane Leistungsfähigkeit des Kommunikationssystems anpasst. Geringer Erkenntnisgewinn: Traces erfassen das Verhalten einer realen Anwendung (oder eines realen Benutzers) unter speziellen Bedingungen in einem bestimmten Zeitintervall. Die Übertragung der Erkenntnisse auf andere Anwendungen, Schnittstellen oder Benutzer unter veränderten Randbedingungen ist somit erschwert oder nicht möglich. Von den Traces, die aus den Messungen an einem realen Kommunikationssystem oder Rechnernetz gewonnen werden, sind noch solche künstliche Traces zu unterscheiden, die infolge der Auswertung eines Modells eines Kommunikationssystems oder eines Rechnernetzes ([Sch06], [SBW05]) entstanden sind. Solche Traces sind in den Situationen nützlich, in denen Messungen an einem realen System nicht möglich sind Einsatz von Wahrscheinlichkeitsverteilungen Wie bereits erläutert, stellt der Einsatz von Traces eine relativ realitätsnahe aber sehr unflexible (insbesondere im Hinblick auf die Übertragung der Erkenntnisse auf andere Modellierungsfälle) Methode zur Spezifikation der Lastparameter dar. Um diesen Nachteil auszugleichen, können bestimmte Wahrscheinlichkeitsverteilungen angenommen werden (z.b. eine Verteilung der Zwischenankunftszeiten für die Beschreibung des Ankunftsverhaltens der Aufträge bzw. eine Verteilung der Bedienzeiten für die Beschreibung der Dauer der systembedingten Wartezustände der Benutzer). Das Verhalten des Benutzers wird in diesem Fall durch einen stochastischen Prozess modelliert und die entsprechenden Modellparameter werden durch Zufallsvariablen beschrieben. Der Hauptvorteil des Einsatzes von Wahrscheinlichkeitsverteilungen liegt in deren Flexibilität (zurückzuführen auf die vollständig bekannten Eigenschaften der gängigen Verteilungen) und in der relativ aufwandsarmen Realisierung. Wird in einem Benutzermodell z.b. die Verteilung der Zwischenankunftszeiten der Aufträge variiert, dann kann das Verhalten des beobachteten (Bedien-)Systems bei unterschiedlichen Belastungsniveaus untersucht werden. Die Güte der Approximation muss aber stets überprüft werden, d.h. es ist zu untersuchen, mit welcher Genauigkeit die angewendeten Verteilungen die empirisch gewonnenen Häufigkeitsverteilungen annähern. Darüber hinaus müssen die Eigenschaften des zu untersuchenden (Bedien-)Systems statistisch charakterisiert werden (im Hinblick auf die Korrelation, Stationarität, Unabhängigkeit der Parameterwerte, siehe z.b. [Lan92])

34 Kapitel 2 Analytische Verteilungen Auswahlregel Zufallszahlengenerator Gleichverteilte Zufallszahlen in (0,1) Erzeugung der Eingabedaten τ 1, τ 2, τ 3, Lastgenerator Auftragsstrom X(t) = (τ i,r i) Abbildung 2.5: Allgemeine Vorgehensweise beim Einsatz von Wahrscheinlichkeitsverteilungen zur Spezifikation der Lastparameter (vgl. [Lan92, S. 159]). In der Abbildung 2.5 wurde eine allgemeine Vorgehensweise beim Einsatz von Wahrscheinlichkeitsverteilungen für die Approximation der Werte von Lastparametern präsentiert. Dabei wurde die Verwendung von den Zufallszahlen, die einer vorgegebenen Verteilung genügen, für die Approximation der Übergabezeitpunkte τ i der Aufträge skizziert. Für die Generierung von Zufallszahlen, die einer bestimmten Verteilungsfunktion genügen, sind spezielle Transformationen (Berechnungsvorschriften) auf die gleichverteilten Zufallszahlen in dem Intervall (0,1) anzuwenden. Die Zufallszahlen, die von den meisten internen (Pseudo-)Zufallszahlengeneratoren moderner Betriebssysteme geliefert werden, sind i.d.r. gleichverteilt. Die gleichverteilten Zufallszahlen sind für die Generierung von Zufallszahlen, die anderen Verteilungen genügen, von besonderer Bedeutung. Im Weiteren werden einige wichtige Verteilungstypen vorgestellt, die für die Spezifikation der Parameter eines Benutzermodells am häufigsten benötigt werden. Rechteck (a, b)-verteilung (Gleichverteilte Zufallszahlen) Als gleichverteilte Zufallszahlen werden solche Zufallszahlen bezeichnet, deren Dichtefunktion f (x) über einem Intervall (a, b) konstant ist. f ( x) = 1 b a 0 a < x < b sonst Die entsprechende Verteilungsfunktion ist gegeben durch: F( x) = 0 x a b a 1 x a a < x < b x b

35 Grundlagen der Lastgenerierung Der Erwartungswert liegt mit + a + b E [ X ] = x f ( x) dx = genau in der Mitte des Inter- 2 2 ( b a) valls (a,b), die Varianz ergibt sich zu Var[ X ] = E[( X E[ X ]) ] =. 12 Zur Generierung von gleichverteilten (Pseudo-)Zufallszahlen gibt es zahlreiche Methoden, so z.b. die Kongruenzmethode. Eine Folge von Zufallszahlen x i ist definiert durch die rekursive Berechnungsvorschrift xi+ 1 = ( A xi ) mod P, i N 0. Dabei ist P eine frei wählbare, möglichst große Primzahl, x 0 und A natürliche Zahlen aus dem Intervall [1, P- 1]. Die generierte Zahlenfolge ist periodisch, d.h. wenn ein bereits generiertes x i erneut erzeugt wird, so wiederholt sich die gesamte Folge von dem x i an periodisch. Der Wertebereich der generierten Folge sind natürliche Zahlen aus dem Intervall [1, P-1]. Durch die Wahl eines sehr großen Wertes für P kann der Wertebereich der Zahlenfolge sehr weit ausgedehnt werden. Um die gleichverteilten Zahlen auf dem Intervall (0,1) zu erhalten, sind die generierten x i durch P zu dividieren. Wurden gleichverteilte Zufallszahlen y i im Intervall (0,1) gewonnen, so lassen sich hieraus auf (a,b) gleichverteilte Zufallszahlen z i durch die Berechnungsvorschrift zi = a + ( b a) yi erzeugen. Weitere Verfahren zur Generierung gleichverteilter Zufallszahlen finden sich z.b. in [Pag91] oder [Lan92]. Zur unmittelbaren Charakterisierung von typischen Lastparametern sind gleichverteilte Zufallszahlen eher selten geeignet (z.b. hat die Verteilung der Zwischenankunftszeiten der Aufträge bei den gängigen lastgenerierenden Anwendungen häufig andere Charakteristika). Gleichverteilte Zufallszahlen werden jedoch zur Generierung von Zufallszahlen anderer Verteilungen benötigt. Negative Exponentialverteilung Die negative Exponentialverteilung eignet sich in vielen Fällen gut dazu, unterschiedliche Lastparameter, wie z.b. die Zwischenankunftszeiten der Aufträge, zu approximieren. Aufgrund der speziellen Eigenschaften dieser Verteilung, vor allem wegen der einfachen Ausdrücke für Mittelwert und Varianz, ist sie insbesondere für die analytische Auswertungen gut geeignet. Eine stetige Zufallsvariable X heißt negativ exponentiell verteilt mit dem Parameter λ > 0, falls ihre Dichte gegeben ist durch: λ e f ( x) = 0, λx, x > 0 x 0 Die Verteilungsfunktion ist dann gegeben durch: 1 e F( x) = 0, λx Der Erwartungswert ist und das k-te Moment, x 0 x < 0 E [ X ] = 1/ λ, die Varianz E ] 2 2 Var X ] = E[( X E[ X ]) ] = 1/, [ λ k k [ X ] = k! E[ X. Der Variationskoeffizient ist gegeben durch

36 Kapitel 2 Var[ X ] cx = und ist somit stets gleich 1. Die negative Exponentialverteilung ist E[ X ] gedächtnislos, das heißt, es gilt: P [ X > t + k X > t] = P[ X > k] t, k > 0. Wegen dieser Eigenschaft, die die mathematisch-analytische Behandlung von Modellen häufig stark vereinfacht oder überhaupt erst ermöglicht, ist die Exponentialverteilung für die Lastmodellierung von großer Bedeutung. Beschreibt die Zufallsvariable X die Wartezeit auf ein bestimmtes Ereignis, dann hat diese Gleichung die folgende Bedeutung: Wurden bereits t Zeiteinheiten auf das Ereignis gewartet, dann ist die Wahrscheinlichkeit dafür, höchstens weitere k Zeiteinheiten zu warten, völlig unabhängig von t. Es existiert keine Erinnerung daran, wie lange schon gewartet wurde. Exponentialverteilte Zufallszahlen können generiert werden, indem die inverse Funktion F -1 (X) = -1/λ * ln(1-z) der Verteilungsfunktion F(x) auf die im Intervall (0,1) gleichverteilten Werte z i von Z angewendet wird (inverse Transformation, siehe [Pag91]). Erlang-k-Verteilung Eine Zufallsvariable X heißt erlangverteilt mit den Parametern k und µ, falls für ihre Dichte gilt: f ( x) = k 1 µ ( µ x) e ( k 1)! 0, µ x, x > 0 x 0 Eine Erlang-k-Verteilung besteht aus einer Reihe von k nacheinander ausgeführten Exponentialverteilungen, jede mit der Bedienrate k µ. Die Verteilungsfunktion ist gegeben durch k kµ x F( x) = 1 e i ( k x) i! 1 i µ, x 0, k N. 1 Jede der k einzelnen exponentialverteilten Phasen hat einen Erwartungswert von, k µ k-mal hintereinander ausgeführt ergibt sich dementsprechend E [ X ] = 1/ µ, die Varianz 2 Var[ X ] 1 beträgt Var [ X ] = 1/ kµ, der Variationskoeffizient cx = = und somit für E[ X ] k alle k > 1 kleiner als 1, dem Variationskoeffizienten bei der Exponentialverteilung. Für die Simulation einer Erlang-k-verteilten Zufallsvariablen sind (nach Definition der Erlang-k-Verteilung) k negativ-exponentiell verteilte Zufallszahlen zu erzeugen und ihr arithmetisches Mittel zu bilden. Die Erlang-k-Verteilung ist eine direkte Verallgemeinerung der Exponentialverteilung, für k=1 entspricht sie der Exponentialverteilung. Die Erlang-k-Verteilung bietet sich insbesondere dann zur Approximation der Lastparameter an, wenn die Struktur der Häufigkeitsverteilung dieser Parameter ähnlich der Struktur der Exponentialverteilung ist, die Varianz jedoch höher ausfällt

37 Grundlagen der Lastgenerierung 2.4 Möglichkeiten für die Parametrisierung der Hauptkomponenten der Lastbeschreibungstechnik In diesem Abschnitt werden die Anwendungsmöglichkeiten der in Abschnitt 2.3 vorgestellten Basisverfahren zur Parametrisierung der einzelnen Komponenten eines BVA- Modells diskutiert, dabei sind insbesondere folgende Festlegungen zu treffen (siehe [Con06, S. 47]): Spezifikation der Zustandsübergänge in dem BVA. Diese Entscheidung ist nur in den R-, S- und Ď-Zuständen des BVA zu treffen. Für die nicht-unterbrechbaren D-Zustände wird vereinbart, dass sie einen einzigen Nachfolgezustand besitzen können. Die (infolge von unerwarteten Systemreaktionen) unterbrechbaren Ď-Zustände können hingegen mehrere Nachfolgezustände besitzen, von denen ein Zustand in Abhängigkeit vom Typ der letzten Systemreaktion mithilfe einer Prozedur (siehe weiter in diesem Abschnitt) zum Nachfolgezustand gewählt werden kann. Die Festlegung der Dauer von Verzögerungen in den D- und Ď-Zuständen. Die Spezifikation der Werte von Auftragsattributen für jeden Auftragstyp (in den R- Zuständen) Spezifikation der Zustandsübergänge Die Möglichkeiten für die Spezifikation der Zustandsübergänge (Transitionen), die zu einer bestimmten Reihenfolge der Zustände bei der Ausführung des BVA führen, sind durch Traces, Übergangswahrscheinlichkeiten, deterministische Zustandsübergänge sowie Prozeduren gegeben. a) Trace Ein Trace T r zur Spezifikation der Zustandsübergänge in einem BVA ist in der Form einer endlichen Auftragsliste T r = (r i ), i Ν, aufzubereiten, so dass die Reihenfolge der generierten Aufträge an der betrachteten Schnittstelle aus dieser Liste exakt reproduzierbar ist. Durch die Auftragsliste T r = (r 1, r 2, r 3, r 4, r 5, r 6, r 7, r 8, r 9 ) wird z.b. folgende Auftragssequenz spezifiziert (siehe Abbildung 2.6): r 1(RT 1) r 2(RT 4) r 3(RT 2) r 4(RT 3) r 5(RT 4) r 6(RT 5) r 7(RT 3) r 8(RT 4) r 9(RT 2) τ 1 τ 2 τ 3 τ 4 τ 5 τ 6 τ 7 τ 8 τ 9 t Abbildung 2.6: Eine Sequenz von Aufträgen und Auftragstypen Die r i (i Ν, 1 i 9) bezeichnen dabei die einzelnen Aufträge, die vom Benutzer an einer wohldefinierten Schnittstelle generiert werden und RT j (j Ν, 1 j 5) sind die entsprechenden Auftragstypen. Der entsprechende Trace zur Spezifikation der Nachfolgezustände des Zustands R 4 (in dem die Generierung der Aufträge vom Auftragstyp RT 4 stattfindet) würde für das Beispiel aus der Abb. 2.6 wie folgt aussehen: (R 2, R 5, R 2 ). In der zu beschreibenden Auftragssequenz folgt auf das erste Vorkommen (r 2 ) des Auftrags vom Typ RT 4 zunächst ein Auftrag r 3 vom Typ RT 2, auf das zweite Vorkommen

38 Kapitel 2 des Auftrags vom Typ RT 4 folgt ein Auftrag vom Typ RT 5 und auf das dritte Vorkommen wieder ein Auftrag vom Typ RT 2. b) Übergangswahrscheinlichkeiten Für die Ermittlung des Nachfolgezustands werden in diesem Fall die Übergangswahrscheinlichkeiten verwendet, die relative Häufigkeiten für einen Wechsel aus dem gegebenen Zustand zu den anderen Zuständen des BVA repräsentieren. Diese Übergangswahrscheinlichkeiten können als Ergebnis statistischer Analysen aus den entsprechenden Messungen in realen Systemen gewonnen werden. Sind R j (1 j n) die Zustände des BVA, dann repräsentieren die p ji (1 i n, 0 p ji 1) die Wahrscheinlichkeiten für den Übergang aus dem Zustand R j in die Zustände R 1, R 2,..., R n, und die Menge der Zustandsübergänge aus dem Zustand R j kann dargestellt werden als ein Vektor von Tupeln (R i, p ji ), (1 j n, 1 i n, 0 p ji 1). Die Summe der Übergangswahrscheinlichkeiten p ji an den Übergängen aus einem Zustand Z j in die anderen Zustände Z i (1 i n) muss offensichtlich 1,0 betragen: n i= 1 p ji = 1,(0 p ji 1) c) Deterministische Zustandsübergänge Deterministisch bedeutet in diesem Fall, dass der Nachfolgezustand des aktuellen Zustands eindeutig bestimmt ist (d.h. der aktuelle Zustand besitzt nur einen einzigen Nachfolger im BVA). Deterministische Zustandsübergänge können somit als Spezialfall von Zustandsübergängen nach Wahrscheinlichkeiten (mit einer Wahrscheinlichkeit von 1.0 für den einzigen Zustandsübergang aus dem gegebenen aktuellen Zustand) betrachtet werden. Sei I, B, B, P, B, B, I, B, B, P, B, B, I,... eine MPEG-codierte Videosequenz, die von einem MPEG-Codierer unter Anwendung des entsprechenden GOP-Musters (engl. group of pictures) IBBPBB generiert und an einer Transportdienstschnittstelle (z.b. UDP) an das Kommunikationssystem übergeben wird. In einer solchen Sequenz folgt auf einen I-Frame bzw. einen P-Frame stets ein B-Frame. Wird die Generierung von den I-, B- und P-Frames in dem entsprechenden BVA-Modell jeweils durch die Auftragstypen SEND_I_FRAME (z.b. im R-Zustand R I ), SEND_B_FRAME (im R-Zustand R B ) und SEND_P_FRAME (im R-Zustand R P ) modelliert (vgl. [Bai99]), so haben die Zustände R I und R P einen einzigen Folgezustand R B. Der Zustandsübergang von R I bzw. R P in R B erfolgt somit deterministisch. d) Prozeduren Der Folgezustand im BVA kann auch (in Ergänzung der in [Wol99] vorgeschlagenen Lastbeschreibungstechnik) mithilfe einer Prozedur (siehe z.b. [CoW04]) generiert werden, falls dies deterministisch bzw. mithilfe von Übergangswahrscheinlichkeiten oder Traces nicht möglich ist. Eine solche Prozedur kann nur für einen bestimmten Zustand definiert werden und verfügt über einen Prozedurnamen, ggf. mehrere Prozedurargumente und einen Rückgabewert, der den Folgezustand darstellt. Im einfachen Fall kann von der Prozedur eine bestimmte Bedingung ausgewertet werden, um einen Folgezustand auszuwählen. Für die Spezifikation von solchen Bedingun

39 Grundlagen der Lastgenerierung gen an den Zustandsübergängen werden Definitionen von entsprechenden historischen Variablen in den Zuständen des BVA und eine Menge von elementaren Operatoren, z.b. den Vergleichsoperatoren "=", "<", ">", " ", " " vorausgesetzt. Der Zugriff auf die historischen Variablen, die in einem Zustand Z i definiert sind, kann in einem der beiden Modi erfolgen (vgl. [Con06]): a) read/write -Modus: die Prozeduren, die in dem Zustand Z i sowie den benachbarten Zuständen definiert sind, dürfen den Wert der Variable lesen und schreiben. b) read only -Modus: die Prozeduren, die in dem Zustand Z i sowie den benachbarten Zuständen von Z i definiert sind, dürfen den Wert der Variable lesen, aber nicht schreiben. Folgende historischen Variablen können z.b. definiert werden: a) In den R-Zuständen: - gvtotreq(r j ): Die Gesamtanzahl der im Zustand R i generierten Aufträge (vom Auftragstyp RT i ), - gvnumreq(r j ): Die Anzahl der im Zustand R i direkt hintereinander generierten Aufträge desselben Auftragstyps RT i (d.h. nach der Generierung eines Auftrags vom Auftragstyp RT i wurde der aktuelle Zustand R i beibehalten). b) In den S-Zuständen: - gvd(s j ): Die Dauer der letzten systembedingten Verzögerung im Zustand S j, - gvet(s j ): Der Typ der letzten Systemreaktion im Zustand S j. Die entsprechenden Zustandsübergänge aus dem Zustand R j bzw. S j in einen anderen Zustand Z i können dann als Tupel (Z i, gvtotreq(r j ), OP(R j, gvtotreq(r j )), gvnumreq(r j ), OP(R j, gvnumreq(r j )) bzw. (Z i, gvet(s j ), OP(S j, gvet(s j )), gvd(s j ), OP(S j, gvd(s j )), (1 i n, n: Anzahl der Zustände im BVA), dargestellt werden. Dabei bezeichnen die OP(R j, gvtotreq(r j )) bzw. OP(S j, gvd(s j )) die entsprechenden Vergleichsoperatoren, die jeweils auf die Werte der Variablen gvtotreq(r j ) bzw. gvd(s j ) angewendet werden und zu TRUE (1) bzw. FALSE (0) auswerten. Die Vergleichsoperatoren sind bei der Spezifikation der Zustandsübergänge aus dem Zustand R j bzw. S j aus der Menge der vorhandenen Vergleichsoperatoren auszuwählen. Ein Zustand Z i wird zum Nachfolgezustand gewählt, wenn alle Bedingungen an dem Zustandsübergang von R j bzw. S j zu diesem Zustand Z i den Wert TRUE (1) liefern. Im Folgenden betrachten wir erneut das in [Bai99] vorgeschlagene BVA-Modell für eine MPEG-codierte Videosequenz I, B, B, P, B, B, I, B, B, P, B, B, I,... als ein Beispiel für die Verwendung von Prozeduren zur Spezifikation der Zustandsübergänge in einem BVA (siehe Abb. 2.7)

40 D BI b 3 Kapitel 2 ϕ i S α b 0 b 2 ϕ a R I X D IB b 10 b 4 b 5 R B Y D IB D BP ϕ t R P Z b 6 D PB S ω Abbildung 2.7: Ein BVA-Modell für eine MPEG-codierte Videosequenz unter Anwendung des GOP- Musters IBBPBB (modifiziert entnommen aus [Bai99]). Um die Anwendung des entsprechenden GOP-Musters IBBPBB in dem MPEG-Codierer zu modellieren, werden die Variablen x (die Anzahl der generierten Aufträge im Zustand R I ), y (die Anzahl der generierten Aufträge im Zustand R B ) und z (die Anzahl der generierten Aufträge im Zustand R P ) definiert und folgende Bedingungen b k an den Zustandsübergängen T k des BVA-Modells spezifiziert: - b 0 : deterministischer Zustandsübergang aus S α in R I, Start der Generierung einer MPEG-Sequenz, x:= 1, - b 2 : Zustandsübergang mit einer Prozedur von R I nach R B ; danach wird y:= y+1 gesetzt ( read/write -Modus), - b 3 : Zustandsübergang mit einer Prozedur von R B nach R I, wenn y mod 4 = 0; danach wird x:= x+1 gesetzt ( read/write -Modus), - b 4 : Zustandsübergang mit einer Prozedur von R B nach R B, wenn y mod 4 = 1 oder y mod 4 = 3; danach wird y:= y+1 gesetzt ( read/write -Modus), - b 5 : Zustandsübergang mit einer Prozedur von R B nach R P, wenn y mod 4 = 2; danach wird z:= z+1 gesetzt ( read/write -Modus), - b 6 : Zustandsübergang mit einer Prozedur von R P nach R B, danach wird y:= y+1 gesetzt ( read/write -Modus), - b 10 : Zustandsübergang mit einer Prozedur von R I nach S ω (wenn die MPEG-Sequenz beendet ist, d.h. x x max in R I zu testen); danach werden x:= 0, y:= 0 und z:= 0 gesetzt ( read/write -Modus) Spezifikation der Dauer von Verzögerungen in den D- und Ď-Zuständen Die Dauer der Verzögerungen in den D-Zuständen (zur Modellierung der Übergabezeitpunkte der Aufträge in ϕ a ) bzw. in den Ď-Zuständen (zur Modellierung der Reaktionszeiten des (Bedien-)Systems in ϕ b ) kann als Konstante oder mithilfe von Traces, Wahrscheinlichkeitsverteilungen oder Prozeduren spezifiziert werden

41 Grundlagen der Lastgenerierung a) Konstante Falls die Dauer der Verzögerung t = τ i+1 - τ i (i N) zwischen den Aufträgen r i+1 und r i für jedes i konstant gleich c ist, kann die Dauer der Verzögerung als t = c spezifiziert werden. Ist t stets 0, kann der entsprechende D-Zustand entfernt werden. Die Zwischenankunftszeiten zwischen den I-, B- und P-Frames in einer MPEG-codierten Videosequenz sind z.b. konstant ( t = 1/ν, ν ist die Bildwiederholfrequenz, eine konfigurierbare Größe in dem entsprechenden MPEG-Codierer, z.b. bei ν = 50 Hz ergibt sich t = 20 ms). Bei der digitalen Audiokommunikation können die Zwischenankunftszeiten der Aufträge an die Transportschicht zur Übermittlung der Audiodaten ebenfalls konstant sein (wie z.b. im Fall der Sprachübertragung bei VoIP). b) Trace Ein geeigneter Trace zur Spezifikation der Dauer der Verzögerungen in den D- Zuständen sollte z.b. als eine endliche Liste T τ = (τ i ) der Zwischenankunftszeiten τ i (τ i R, τ i 0, i N) der Aufträge r i aufbereitet sein. Die entsprechenden Tracedaten können entweder aus Messungen an einem realen Kommunikationssystem gewonnen oder aus einem Systemmodell abgeleitet werden. c) Wahrscheinlichkeitsverteilungen Verschiedene Wahrscheinlichkeitsverteilungen (z.b. die Exponential-, die Lognormal-, die Pareto-Verteilung, etc.) können zur Approximation der statistischen Eigenschaften der Zwischenankunftszeiten der Aufträge (z.b. der ermittelten Häufigkeitsverteilung), die aus Messungen an einem realen Kommunikationssystem gewonnenen bzw. aus einem Systemmodell abgeleiteten wurden, verwendet werden. Dabei ist die Güte der Approximation in jedem konkreten Fall zu untersuchen (siehe Abschnitt 2.3.2). Verschiedene Möglichkeiten zur Approximation der Zwischenankunftszeiten der Aufträge für verschiedene Typen von Auftragsverkehr wurden vorgeschlagen (siehe z.b. [Bai99], [CoR01], [JiB01], [RRB07], [TSM04], [Zad01]). d) Prozeduren Die Dauer von Verzögerungen in den D- und Ď -Zuständen kann mithilfe einer Prozedur spezifiziert werden, falls dies als Konstante bzw. mithilfe von Traces oder Wahrscheinlichkeitsverteilungen nur eingeschränkt oder nicht möglich ist. Die Definition einer solchen Prozedur erfolgt analog wie für die Zustandsübergänge in Abschnitt bereits beschrieben. Die Prozedur liefert die nächste Zwischenankunftszeit (in ϕ a ) bzw. Reaktionszeit (in ϕ b ) t in dem Rückgabewert vom Datentyp real ( t R + {0}) zurück Spezifikation der Werte für Auftragsattribute In Abschnitt wurde eine Methode zur formalen Beschreibung der einzelnen Aufträge r i präsentiert. Jeder Auftrag r i wird durch einen eindeutigen Auftragstyp RT i (A i1, A i2,..., A ij ) und eine Menge der zugehörigen Auftragsattribute A ij mit den wohldefinierten Wertedomänen d ik, i,j,k N charakterisiert. Die Attribute eines Auftrags können somit verschiedene Wertedomänen haben (z.b. Integer, Real, IP_Address, String, etc.). Für die Spezifikation der Attributwerte können Konstanten, Traces, Wahrscheinlichkeitsverteilungen oder Prozeduren verwendet werden. Dabei sollten die

42 Kapitel 2 Werte verschiedener Attribute unabhängig voneinander festgelegt werden können, um einen möglichst hohen Grad an Universalität und Realitätsnähe des Benutzermodells zu erreichen. a) Konstante Ein Auftragsattribut wird als konstant bezeichnet, wenn der Wert dieses Attributs während des gesamten Lastgenerierungsprozesses unverändert bleibt. Die Attribute source_addr und dest_addr eines Auftrags vom Auftragstyp SEND_DATA zur Modellierung des Datentransfers mithilfe eines verbindungslosen Dienstes an der Transportschicht aus Abschnitt können z.b. solche konstanten Attribute sein. b) Trace Ein geeigneter Trace zur Spezifikation der Werte für Auftragsattribute AT 1, AT 2,...AT j könnte als eine endliche Liste T υ = (υ i1, υ i2,..., υ ij ), (i,j N) von Werten υ ij aus den entsprechenden wohldefinierten Wertedomänen d ik, (k N) aufbereitet werden. Andere Varianten für den Aufbau der Traces sind möglich (z.b. jeweils ein Trace für jedes Auftragsattribut, etc.). c) Wahrscheinlichkeitsverteilungen Bei der Spezifikation der Werte der Auftragsattribute können (wie bei der Spezifikation von Zwischenankunftszeiten der Aufträge, vgl. Abschnitt c)) verschiedene Wahrscheinlichkeitsverteilungen zum Einsatz kommen, z.b. die Normalverteilung zur Approximation der Längen von MPEG-Frames (siehe [Bai99]) oder die Lognormal-Verteilung zur Approximation der Größe der zu übertragenden Streaming-Objekte (siehe z.b. [JiB01]). d) Prozeduren Eine in dem R-Zustand definierte Prozedur liefert den nächsten Wert eines Auftragsattributs aus der entsprechenden wohldefinierten Wertedomäne. Die Definition von Prozeduren ist ähnlich der in den Abschnitten d) und d) beschriebenen Vorgehensweise. In den vorstehenden Abschnitten 2.3 und 2.4 wurden zunächst die allgemeinen Verfahren zur Spezifikation der Lastparameter vorgestellt und danach die Möglichkeiten für die Anwendung dieser Verfahren bei der Parametrisierung eines BVA-Modells aufgezeigt. Eine formale Methode zur Beschreibung eines parametrisierten Benutzerverhaltensautomaten PBVA (engl. parameterized UBA, PUBA) mithilfe einer Grammatik in Backus-Naur Form wurde in [Con06] vorgestellt. Damit ist die Definition einer formalen Lastbeschreibungstechnik, die zur Beschreibung von parametrisierten Benutzermodellen (PBVA) für den Einsatz in einem Lastgenerator (zur Lastgenerierung an einer wohldefinierten Schnittstelle IF, z.b. an einer Transportdienstschnittstelle in einem Knoten eines IP-basierten Rechnernetzes) in dieser Arbeit verwendet wird, abgeschlossen

43 Kapitel 3 Ausgangssituation und Randbedingungen dieser Studie Basierend auf der in Kapitel 2 präsentierten allgemeinen Vorgehensweise bei der Lastgenerierung in Kommunikations- und Rechnernetzen wird in diesem Kapitel zunächst eine entsprechende in [CoK05] vorgeschlagene Architektur eines verallgemeinerten Lastgenerators UniLoG vorgestellt. In den Abschnitten 3.2 und 3.3 werden die Werkzeuge LoadSpec zur Spezifikation von Lasten und LoadTrafo zur Transformation von Auftragsströmen präsentiert, die zur Veranschaulichung von Einsatzmöglichkeiten der vorgeschlagenen formalen Lastbeschreibungstechnik in der Lehre (z.b. in den Lehrveranstaltungen zum Schwerpunkt "Rechnernetze und Telematik") entwickelt wurden. Anschließend werden in Abschnitt 3.4 die Anforderungen an einen neuen software-basierten, echtzeitfähigen Lastgenerator zur Generierung von verschiedenen Verkehrsströmen in IP-basierten Rechnernetzen erarbeitet und die bei der Realisierung einer entsprechenden Architektur zu lösenden Probleme und Aufgaben erläutert. 3.1 Eine Architektur zur Lastgenerierung in Rechnernetzen Lastgeneratoren sind ein wichtiges Werkzeug bei der Durchführung von Experimenten zur Leistungsanalyse und zur Ermittlung von Verhaltensprognosen für Kommunikations- und Rechnernetze unter verschiedenen Lastszenarien. Mit fortschreitender Entwicklung der Netztechnik und verschiedenartigen neuen Anwendungen wird die Entwicklung von entsprechenden auf einen bestimmten Modellierungsfall zugeschnittenen Lastgeneratoren zunehmend aufwändiger. Damit steigt der Bedarf nach einer allgemeinen und universellen Lösung, mit der die für die Realisierung von speziellen Lastgeneratoren für jeden einzelnen Modellierungsfall benötigte Entwicklungszeit verkürzt werden kann. Eine Architektur für den Aufbau eines verallgemeinerten Lastgenerators unter Anwendung der in Kapitel 2 präsentierten Lastbeschreibungstechnik wurde in [CoK05] vorgeschlagen. Um eine möglichst breite Anwendbarkeit des verallgemeinerten Lastgenerators in verschiedenen Experimenten zu erreichen, wurden insbesondere folgende Schlüsselanforderungen berücksichtigt: Modularisierung, eine funktionale Aufteilung der Gesamtarchitektur in Teilkomponenten, um verschiedene Kombinationen der einzelnen Komponenten zur Realisierung von bestimmten Funktionen zu ermöglichen und die Implementierung sowie die Fehlersuche zu vereinfachen. Strikte Trennung der Lastspezifikation von der Lastgenerierung. Die Bedienungsschnittstelle (GUI) eines verallgemeinerten Lastgenerators soll z.b. von der Auftragsgenerierung komplett getrennt werden, um eine flexible Schnittstelle zur graphischen Spezifikation von Lastmodellen und weiteren Parametern eines Experiments zu ermöglichen

44 Kapitel 3 Unabhängigkeit von der Realisierungssprache, d.h. die Komponenten der Architektur müssen in einer der gängigen Programmiersprachen (z.b. Java, C++) realisiert werden können. Universalität bezüglich der Schnittstelle für die Lastgenerierung, d.h. für den Benutzer eines verallgemeinerten Lastgenerators muss es möglich sein, bestimmte Lasten an verschiedenen Schnittstellen in realen oder emulierten Kommunikations- und Rechnernetzen in verschiedenen Experimenten zu erzeugen. Basierend auf diesen Anforderungen und auf der in Kapitel 2 vorgestellten Lastbeschreibungstechnik kann der Lastgenerierungsprozess mithilfe eines verallgemeinerten Lastgenerators wie folgt dargestellt werden: Schritt 1: Erstellen von Lastmodellen an einer wohldefinierten Schnittstelle in Form eines BVA und Spezifikation der entsprechenden Modellparameter in einem parametrisierten BVA (PBVA). Schritt 2: Generierung von abstrakten Aufträgen gemäß den Parametern des Lastmodells und Übergabe der Aufträge entsprechend den spezifizierten Übergabezeitpunkten an die auftragsausführenden Komponenten. Schritt 3: Transformation der abstrakten Aufträge in Aufträge an einer in der Schnittstellenhierarchie weiter unten liegenden Schnittstelle IF, die vom Experimentator zur Lastgenerierung gewählt wurde (falls das verwendete Lastmodell nicht dem Lastmodell entspricht, welches zur Generierung von Aufträgen an der Schnittstelle IF benötigt wird). Schritt 4: Ausführen von Aufträgen und Übergabe der realen Lasten an das Netz. Eine entsprechende Architektur für einen verallgemeinerten Lastgenerator wurde in [CoK05] vorgeschlagen (siehe Abb. 3.1). GUI Prerequisites for Load Models (PLM) (BVA-Modellbank, Parameterbank) Executable Load Models (ELM) (PBVA-Modellbank) Load Transformers (LTs) Generator for Sequences of Abstract Requests (GAR) Experimental Evaluation Module (EEM) abstrakte Aufträge Adapter (ADAPT) abstrakte Aufträge reale Aufträge Schnittstelle IF Datenfluss von der GUI Lastgenerierungsprozess Fluss von Systemreaktionen Bericht von Lastgeneratoren Abbildung 3.1: Hauptkomponenten eines verallgemeinerten Lastgenerators UniLoG (Grobsicht der Architektur)

45 Ausgangssituation und Randbedingungen dieser Studie In dem Entwurf wird das grundlegende Prinzip der Trennung zwischen der Lastspezifikation (resultierend in den abstrakten Aufträgen) und der Lastgenerierung (resultierend in den konkreten bzw. realen Aufträgen an der vom Experimentator gewählten Schnittstelle IF) eingehalten. Im Folgenden werden die Funktionen der einzelnen Hauptkomponenten der Architektur eines verallgemeinerten Lastgenerators erläutert. PLM (Prerequisites for Load Models) Die Funktion der PLM-Komponente ist die Erstellung und die Modifikation von Lastmodellen in Form eines BVA sowie die Speicherung von verschiedenen Modellparametern (z.b. die zur Parametrisierung benötigten Traces). ELM (Executable Load Models) In der ELM-Komponente werden die vollständigen parametrisierten Benutzermodelle als PBVA (parametrisierter BVA) gespeichert, um ihre wiederholte Nutzung in den Experimenten zu ermöglichen und zu vereinfachen. Im Unterschied zu den BVA-Modellen in der PLM-Komponente sind in den PBVA-Modellen in der ELM-Komponente die Werte aller Modellparameter vollständig spezifiziert. GAR (Generator for Sequences of Abstract Requests) Die GAR-Komponente ist zuständig für die Generierung einer Sequenz von abstrakten Aufträgen entsprechend dem ausführbaren Lastmodell (PBVA), das von dem Experimentator ausgewählt wurde. LT (Load Transformer) Die in der GAR-Komponente generierten abstrakten Aufträge können entweder direkt an die Adapter-Komponente (ADAPT) oder zunächst an die Lasttransformatoren (LTs) übergeben werden. Die LT-Komponenten sind zuständig für die Modellierung der lasttransformierenden Wirkung des Systems wie in [CWZ03] in dem Konzept eines Multilayered Load Generators (MLLG) vorgeschlagen wurde. Die Aufträge, die von der GAR-Komponente generiert oder von den LT-Komponenten transformiert werden, sind abstrakte Aufträge. ADAPT (Adapter) Die Adapter-Komponente übernimmt die Konvertierung der generierten abstrakten Aufträge in die konkreten Aufträge und die Übergabe der resultierenden realen Lasten an einer Schnittstelle IF eines Kommunikations- oder eines Rechnernetzes. Die Adapter- Komponente kann generell in Software oder Hardware realisiert sein. EEM (Experimental Evaluation Module) Die EEM-Komponente stellt Funktionen für die statistische Analyse und Auswertung der Experimentergebnisse in Form von Berichten und Statistiken bereit, die von dem Benutzer des Lastgenerators in Abhängigkeit vom Ziel der Untersuchung angepasst werden können. Die Berichte können Ergebnisse benutzerdefinierter Messungen während des Lastgenerierungsprozesses in textueller oder graphischer Form enthalten. GUI (Graphic User Interface) Für eine benutzerfreundliche Bedienung wird der Lastgenerator mit einer graphischen Bedienungsoberfläche ausgestattet, in der die einzelnen Teilkomponenten über Menübefehle und Kommandos integriert werden. Vor dem Start der Lastgenerierung kann der

46 Kapitel 3 Experimentator die einzelnen Komponenten des Lastgenerators über die GUI konfigurieren (siehe gestrichelte Pfeile in Abbildung 3.1): - PLM: Erstellen, Modifizieren, Parametrisieren und Entfernen von BVA-Modellen, - ELM: Erstellen, Modifizieren und Entfernen von PBVAs, - GAR: Auswählen eines PBVAs für die Lastgenerierung, - EEM: Anpassen von benutzerdefinierten Berichten, - LT: Auswählen von bestimmten Arten der Lasttransformation (z.b. die Fragmentierung oder die Überlagerung mehrerer Auftragsströme), - ADAPT: Auswählen einer geeigneten Adapter-Komponente (z.b. UDP-Adapter oder TCP-Adapter) in Abhängigkeit von der betrachteten Schnittstelle IF, die von dem Experimentator für die Lastgenerierung gewählt wurde. In der Bedienungsoberfläche sind somit die Kontroll- und die Steuerungsfunktionen für die einzelnen Hauptkomponenten des Lastgenerators integriert. Diese Kontroll- und Steuerungsfunktionen sind in der Abbildung 3.1 mit gestrichelten Pfeilen dargestellt. Die grauen Blockpfeile repräsentieren den Prozess der Lastgenerierung und die dünnen grauen Pfeile bezeichnen die Rückgabe von benutzerdefinierten Berichten und Statistiken von den Komponenten des Lastgenerators an den Experimentator. Basierend auf der vorgeschlagener Architektur wurde ein erster Prototyp für einen Lastgenerator erstellt und in [CoK05] präsentiert. Das prototypisch implementierte Werkzeug zur Lastgenerierung UniLoG beinhaltet Komponenten zur graphischen Spezifikation des Benutzermodells (als BVA in PLM), dessen Parametrisierung (als PBVA in ELM) sowie zur Generierung von abstrakten Aufträgen (in GAR) und ermöglichte zunächst nur die Generierung von abstrakten Aufträgen anhand von elementaren Benutzermodellen, in denen die Abhängigkeit des Benutzerverhaltens von den Systemreaktionen nicht berücksichtigt wird (d.h. der entsprechende BVA enthält keine netzbedingten Blockierungszustände der Benutzer und der blockierte Makrozustand ϕ b im BVA ist leer). Mithilfe einer schnittstellen-spezifischen Adapterkomponente ADAPT können aus den abstrakten Aufträgen konkrete (um die schnittstellen-spezifischen Attribute ergänzte) Aufträge zunächst an der Transportdienstschnittstelle UDP in einem Knoten eines IPbasierten Rechnernetzes generiert werden (siehe Abb. 3.1). Der prototypisch realisierte Lastgenerator lieferte für zahlreiche Testszenarien sehr gute Ergebnisse bezüglich der Präzision bei der Übergabe generierter Aufträge (siehe [CoK05]) und konnte in verschiedenen Diplomarbeiten an der Arbeitsgruppe TKRN zur Lastgenerierung (z.b. [Gai05], [Bre05]) sowie in einer erweiterten Umgebung zur verteilten Lastgenerierung (z.b. [Swe06]) eingesetzt werden. 3.2 Werkzeug LoadSpec zur Spezifikation von Lasten Im Rahmen des Projektes TeleMuM wurde an der Arbeitsgruppe TKRN das Werkzeug LoadSpec entwickelt mit dem Ziel, die Verfahren und Techniken der Lastbeschreibung und Lastspezifikation mithilfe von erweiterten Benutzerverhaltensautomaten (BVA) für die Studierenden zu veranschaulichen [FHW04]

47 Ausgangssituation und Randbedingungen dieser Studie Das Werkzeug LoadSpec stellt dem Benutzer eine Arbeitsumgebung zur Verfügung, in der Modelle des Benutzerverhaltens spezifiziert und Sequenzen von abstrakten Aufträgen gemäß diesen Modellen generiert werden können. LoadSpec ermöglicht dem Benutzer die Bearbeitung folgender Aufgabenstellungen: (1) Vollständige Spezifikation eines Benutzermodells als BVA, (2) Flexible Parametrisierung des Benutzermodells, (3) Generierung von abstrakten Aufträgen gemäß dem Benutzermodell, (4) Analyse generierter Auftragssequenzen mithilfe von Zeitdiagrammen. LoadSpec wurde in der Programmiersprache C++ realisiert und besitzt eine graphische Bedienungsoberfläche, in der die einzelnen Teilkomponenten der Architektur eines verallgemeinerten Lastgenerators mit folgenden Funktionen integriert sind: - PLM: graphische Konstruktion von Benutzermodellen als BVA mithilfe eines Assistenten zur Definition von Auftragstypen, Hinzufügen von Zuständen und Zustandsübergängen (Transitionen) in den BVA. - ELM: umfangreiche Parametrisierungsmöglichkeiten für BVA-Modelle. Spezifikation der Zustandsübergänge ist deterministisch oder mithilfe von Übergangswahrscheinlichkeiten möglich. Die Werte der Auftragsattribute und die Dauer der Verzögerungen in den D-Zuständen können als Konstante bzw. mithilfe von Wahrscheinlichkeitsverteilungen (z.b. Rechteck-, Exponential-, Erlang- oder Normalverteilung) oder Traces (die z.b. aus Messungen an einer realen Schnittstelle in einem Knoten eines IP-basierten Rechnernetzes gewonnen werden können) angegeben werden. - GAR: Ausführung des Lastgenerierungsprozesses für eine bestimmte Lastgenerierungsdauer. Dabei werden abstrakte Aufträge gemäß den Spezifikationen in dem ausgewählten PBVA generiert und in einer Auftragsdatei für weitere Untersuchungen gespeichert. Die Auftragsgenerierung ist reproduzierbar, d.h. eine generierte Auftragssequenz kann später jederzeit wiederholt werden. - EEM: Graphische Visualisierung der generierten Auftragssequenz (mit Angabe der Übergabezeitpunkte und der Länge der Aufträge) in einem Zeitdiagramm mit erweiterten Möglichkeiten zur Betrachtung der generierten Last in einem ausgewählten Zeitintervall. Das Werkzeug LoadSpec kann in verschiedenen Experimenten zur Modellierung der gängigen Lastquellen in IP-basierten Rechnernetzen eingesetzt werden. Dabei wird die Last von einer realen Anwendung durch eine Sequenz von abstrakt spezifizierten Aufträgen modelliert. Mithilfe einer integrierten universellen Lastbeschreibungstechnik, die in Kapitel 2 dieser Arbeit vorgestellt wurde, können in der PLM-Komponente von LoadSpec BVA-Modelle für verschiedene Lastquellen vorbereitet und in der ELM-Komponente als ausführbare PBVA-Modelle für Experimente zur Verfügung gestellt werden, z.b.: - eine MPEG-Videoquelle (Alternativmodelle für verschiedene GOP-Muster sind möglich), - einen VoIP-Sprachbenutzer (Alternativmodelle mit oder ohne Pausenunterdrückung sind möglich), - eine UDP-Datenquelle,

48 Kapitel 3 - eine FTP-Datenquelle (auf der Senderseite). In der Abbildung 3.2 ist die Konstruktion eines exemplarischen BVA-Modells für eine MPEG-Videoquelle unter Verwendung des GOP-Musters IBBPBB mithilfe von LoadSpec dargestellt (dieses BVA-Modell wurde bereits in Kapitel 2, Abschnitt erläutert, vgl. auch [Bai99]). Die Übertragung von den I-, B- und P-Frames der ursprünglichen MPEG-Videosequenz wird durch die Generierung von abstrakten Aufträgen der Auftragstypen SEND_I_FRAME (data_len), SEND_B_FRAME (data_len) und SEND_P_FRAME (data_len) modelliert, wobei das Attribut data_len die Framelänge bezeichnet. Abbildung 3.2: Konstruktion eines exemplarischen BVA-Modells einer MPEG-Videoquelle mit GOP- Muster IBBPBB in der PLM-Komponente von LoadSpec. Der entsprechende PBVA kann in der ELM-Komponente von LoadSpec z.b. wie in der Tabelle 3.1 parametrisiert werden (der Trace T I enthält die Übergabezeitpunkte der I- Frames in Spalte 1 und die entsprechenden Framelängen in Spalte 3). Auftragstyp ZAZ der Aufträge [ms] data_len [Byte] SEND_I_FRAME Trace T I, Spalte 1 Trace T I, Spalte 3 SEND_B_FRAME Konstant 40[ms] Normalverteilt(µ B =3913,75; σ B =299,94) SEND_P_FRAME Konstant 40[ms] Normalverteilt(µ P =4703; σ P =310,58) Tabelle 3.1: Exemplarische Parametrisierung der Auftragsattribute und der Zwischenankunftszeiten für ein Modell einer MPEG-Videoquelle mit dem GOP-Muster IBBPBB. Die graphische Visualisierung der generierten Auftragssequenz in einem Zeitdiagramm unterstützt den Experimentator bei der Betrachtung und Beurteilung des Auftragsan

49 Ausgangssituation und Randbedingungen dieser Studie kunftsprozesses während der Lastmodellierung in LoadSpec. Die Aufträge desselben Auftragstyps werden in einer Farbe dargestellt, so lässt sich z.b. in dem Modell der MPEG-Videoquelle das zugrundeliegende GOP-Muster deutlich nachvollziehen. Die Auswirkungen von systematischen Veränderungen der Parameterwerte (z.b. der Zwischenankunftszeit der Pakete in dem Modell der MPEG-Videoquelle) auf die interaktive Kommunikation lässt sich mithilfe der EEM-Komponente nachvollziehen. Die mithilfe von LoadSpec generierten Auftragssequenzen können an weitere auftragsausführende bzw. auftragsbearbeitende Komponenten oder andere Werkzeuge übergeben werden, z.b.: - an einen Netzemulator wie NetEmu (siehe z.b. [SBW05] bzw. [Sch06]) für die Untersuchungen des Verhaltens eines beobachteten Kommunikations- oder Rechnernetzes unter verschiedenen Lastszenarien, - an einen Lasttransformator wie LoadTrafo für die Generierung von Lasten an einer weiter unten in der Schnittstellenhierarchie liegenden Schnittstelle IF, - an einen exemplarisch implementierten UDP-Adapter für die Generierung von den entsprechenden Aufträgen an einer realen UDP-Schnittstelle. Durch die Aggregation mehrerer BVA-Modelle für verschiedene elementare Lastquellen (z.b. einer MPEG-Videoquelle, einer oder mehreren PCM-codierten Audioquellen sowie einer FTP-Datenquelle) lassen sich viel komplexere Lastquellen aus der Anwendungsumgebung eines Knotens in einem IP-basierten Rechnernetz, wie z.b. eine Videokonferenz-Anwendung, modellieren. 3.3 Werkzeug LoadTrafo zur Transformation von Lasten Als Ergebnis weiterer Forschungsarbeiten im Rahmen des Projektes TeleMuM ist an der Arbeitsgruppe TKRN u.a. ein weiteres Lernwerkzeug LoadTrafo zur Modellierung und Demonstration der lasttransformierenden Wirkung eines auftragsausführenden (Kommunikations-)Systems entstanden [FHW04]. Mit dem Werkzeug LoadTrafo sollte demonstriert werden können, dass die komplexen Transformationsprozesse in einem realen Kommunikations- oder Rechnernetz (z.b. in einem IP-basierten LAN oder WLAN) für die meisten Fälle hinreichend genau durch die Kombination relativ einfacher Lasttransformatoren (LTs) approximiert werden können. Das Werkzeug LoadTrafo stellt dem Benutzer eine Arbeitsumgebung zur Verfügung, in der verschiedene Transformationstypen von Rechnerlasten, die als Sequenzen von Aufträgen in Form von (Last-)Traces vorliegen, ausgeführt und visualisiert werden können. Die (Last-)Traces können im Rahmen einer Messung an einem realen System oder einer Auswertung in einem Netzemulator (wie z.b. NetEmu) entstanden bzw. durch einen Lastgenerator (wie z.b. LoadSpec) erstellt worden sein. Das Programm LoadTrafo wurde in der Programmiersprache C++ implementiert und mit einer graphischen Bedienungsoberfläche ausgestattet, in der die einzelnen Transformationstypen als Bausteine integriert worden sind. Das Werkzeug LoadTrafo verfügt in der aktuellen Version über folgende Funktionen: - Verwendung bestehender Lasttraces: Automatische Erkennung der Felder mit den Übergabezeitpunkten und den Längen der abstrakten Aufträge

50 Kapitel 3 - Graphische Visualisierung der ursprünglichen Auftragssequenz, die in dem ausgewählten Lasttrace enthalten ist. - Auswahl verschiedener Typen der Lasttransformation: Durch die Auswahl des entsprechenden Transformationsbausteins (z.b. FG für Fragmentierung) und die Eingabe der Werte der Transformationsparameter (z.b. der Paketbearbeitungszeiten t i in verschiedenen Schichten des Protokollstapels und der maximalen Paketlänge lmax) können unterschiedliche Transformationen der ursprünglichen Auftragssequenz durchgeführt werden, z.b.: a) Header-Generierung: HG( t, l), dabei ist t die benötigte Verarbeitungszeit und l die Länge des zu erzeugenden Headers. b) Fragmentierung (ohne Auffüllung des letzten Pakets): FG 1 ( t, lmax), dabei ist t die benötigte Verarbeitungszeit und lmax ist die maximale Paketlänge. Bei der Generierung des letzten Fragments wird nicht auf die volle (maximale) Länge lmax aufgefüllt. c) Zellen-Fragmentierung (mit Auffüllung des letzten Pakets): FG 2 ( t, lmax), dabei ist t die benötigte Verarbeitungszeit und lmax ist die maximale Paketlänge. Bei der Generierung des letzten Fragments wird auf die volle (maximale) Länge lmax aufgefüllt. d) Auffüllen auf eine Mindestpaketgröße (engl. padding): PAD( t, lmin), dabei ist t die benötigte Verarbeitungszeit und lmin ist die zu garantierende Mindestpaketgröße. - Ausführung der Lasttransformation: LoadTrafo erstellt eine neue Auftragssequenz gemäß der gewählten Transformationsart und den Parameterspezifikationen (z.b. FG 1 (0.0005, 1500)). - Superposition mehrerer Transformationen: mehrere Transformationen verschiedener Transformationstypen können auf die ursprüngliche Auftragssequenz hintereinander angewendet werden, z.b. eine Fragmentierung und eine Header-Generierung, wie im Fall der Transformation von Aufträgen an die Transportschicht durch die Netzwerkschicht (IP-Schicht) in IP-basierten Rechnernetzen. Auf diese Weise können Modelle für das Verhalten komplexerer Systeme gewonnen werden. - Graphische Visualisierung der resultierenden (transformierten) Auftragsequenz. Die Funktion unterstützt den Benutzer von LoadTrafo bei der Analyse des Einflusses der Paketbearbeitung in den Schichten des Protokollstapels auf die übergebene Auftragssequenz. - Speichern der transformierten Auftragsequenz in einem neuen Last-Trace. Ein Beispiel für die Verwendung von LoadTrafo zur Modellierung von Transformationen einer MPEG-codierten Videosequenz (die z.b. mithilfe von LoadSpec, - wie in Abschnitt 3.2 bereits skizziert, - als Sequenz von abstrakten Aufträgen generiert wurde) durch die verschiedenen Schichten in einem IP-basierten Rechnernetz ist in der Abbildung 3.3 dargestellt

51 Ausgangssituation und Randbedingungen dieser Studie Abbildung 3.3: Modellierung der Transformation einer MPEG-codierten Videosequenz durch die Schichten eines IP-basierten Rechnernetzes in LoadTrafo. Die ursprüngliche MPEG-codierte Videosequenz wird nach der Übergabe an einer Transportdienstschnittstelle (z.b. UDP) in einem Knoten eines IP-basierten Rechnernetzes durch die diensterbringenden Schichten (UDP-, IP- und Ethernet-Schicht) mehrfach transformiert. Dieser komplexe Vorgang wird in LoadTrafo als Superposition der folgenden elementaren Lasttransformatoren LT 1 - LT 5 modelliert (vgl. [CWZ03]): Nr. Transformationstyp, Parameter LT 1 Erzeugung des UDP-Headers, LT 1 = HG(5[µs], 8[Byte]) LT 2 Fragmentierung in der IP-Schicht bei einer MTU Größe von 1500 [Byte], LT 2 = FG 1 (10[µs], 1500[Byte]) LT 3 Erzeugung des IP-Headers, LT 3 = HG(4[µs], 20[Byte]) LT 4 Auffüllen auf die Mindestpaketgröße des Ethernets (64[Byte] bei 10 Mbit/s Ethernet und 100 MBit/s Fast Ethernet), LT 4 = PAD(1[µs], 64[Byte]) LT 5 Erzeugung von Ethernet-Header und -Trailer, LT 5 = HG(2[µs], 14[Byte]) Tabelle 3.2: Eine exemplarische Parametrisierung der elementaren Lasttransformatoren bei der Modellierung der Transformation einer MPEG-Videosequenz durch die Schichten eines IP-basierten Rechnernetzes. Die elementaren Typen der Lasttransformation wurden in LoadTrafo als kombinierbare Bausteine exemplarisch implementiert. Die Funktion Graphische Visualisierung in LoadTrafo unterstützt den Benutzer bei der Analyse des Einflusses der Paketbearbeitung in den Schichten des TCP/IP-Protokollstapels auf die übergebene MPEG-codierte Videosequenz

52 Kapitel Anforderungen an einen echtzeitfähigen Lastgenerator Das Hauptziel bei der Lastgenerierung in den Endknoten eines gegebenen Rechnernetzes ist das Ersetzen von einem oder mehreren auftragserzeugenden Benutzern durch einen Lastgenerator, durch den das auftragserzeugende Verhalten des entsprechenden virtuellen Benutzers VU modelliert wird (siehe Abschnitt 2.1). Entsprechend den Zielen dieser Arbeit (vgl. Abschnitt 1.3) soll generell ein software-basierter Ansatz zur Lastgenerierung ohne Rückgriff auf dedizierte Hardware-Lösungen als eine der wichtigsten Randbedingungen für die Entwicklung eines neuen echtzeitfähigen Lastgenerators verfolgt werden. Die Anforderungen an einen solchen Lastgenerator sind erwartungsgemäß recht umfangreich, bedingt einerseits durch die Vielfältigkeit zu realisierender Lastmodelle und andererseits durch die hohen Erwartungen des Experimentators an den Funktionsumfang und die Benutzerfreundlichkeit bei der Durchführung von Experimenten. Eine formale Methode zur Beschreibung des Benutzerverhaltens in Form von BVA-Modellen, die zur Lastgenerierung in dem zu entwickelnden Lastgenerator eingesetzt werden sollen, wurde bereits in Kapitel 2 präsentiert. Verschiedene Anforderungen an den Funktionsumfang (z.b. an die Komponenten zur Konstruktion, Parametrisierung und Ausführung von BVA-Modellen sowie zur Analyse der Experimentergebnisse) und an die Bedienungsschnittstelle (GUI) eines verallgemeinerten Lastgenerators sind bereits in [Kol04] und [CoK05] erarbeitet und umfassend motiviert worden. Gemäß diesen Anforderungen wurde eine entsprechende Architektur zur Lastgenerierung in den IP-basierten Rechnernetzen entworfen und in einem ersten Prototyp eines verallgemeinerten Lastgenerators UniLoG realisiert. Der erste Prototyp ist allerdings durch folgende nicht zu vernachlässigende Einschränkungen gekennzeichnet (vgl. [Con06]): Die Komponente zur Generierung von Sequenzen abstrakter Aufträge (die GAR- Komponente) und die Adapter-Komponente (ADAPT) sind als getrennte Prozesse ohne eine Synchronisationsfunktion realisiert worden. Die Generierung von realen Aufträgen an einer gewählten Schnittstelle IF kann somit in ADAPT erst dann gestartet werden, wenn die Generierung einer vollständigen Sequenz von abstrakten Aufträgen in der GAR-Komponente für das gegebene Zeitintervall T abgeschlossen wurde (sog. Offline-Betrieb des Lastgenerators, vgl. [Kol04]). Keine Möglichkeit zur Berücksichtigung der systembedingten Blockierungszustände des Benutzers bei der Lastgenerierung. Die in der formalen Lastbeschreibungstechnik vorgesehene S-Zustände und Ď-Zustände eines BVA-Modells wurden bei der Generierung einer entsprechenden Auftragssequenz in der GAR-Komponente nicht berücksichtigt. So konnten in dem ersten Prototypen des Lastgenerators UniLoG nur BVA-Modelle ohne die S- und die Ď-Zustände (d.h. mit ϕ b = ) zur Lastgenerierung eingesetzt werden. 1:1-Beziehung zwischen der GAR- und der ADAPT-Komponente. Es kann nur eine einzige Sequenz von abstrakten Aufträgen von einer GAR-Komponente an den Adapter übergeben werden. So kann die Superposition (die Überlagerung) mehrerer Auftragsströme nur entweder a) durch die Aggregation mehrerer Benutzermodelle in einem BVA-Modell für eine komplexere Lastquelle bzw. b) durch die Ausführung von mehreren Instanzen des Lastgenerators mit den entsprechenden BVA-Modellen für verschiedene zu überlagernde Lastquellen, realisiert werden. Eine Überlagerung

53 Ausgangssituation und Randbedingungen dieser Studie von mehreren Auftragssequenzen direkt in der Adapter-Komponente wurde hingegen nicht vorgesehen. Um einen hohen Grad an Universalität und Realitätsnähe bei der Lastgenerierung zu erreichen und damit ein möglichst breites Anwendungsspektrum für den neuen Lastgenerator zu ermöglichen, sollen die bereits in [Kol04] und [CoK05] erarbeiteten umfassenden Anforderungen an einen verallgemeinerten Lastgenerator UniLoG berücksichtigt und die bestehenden Einschränkungen des ersten realisierten Prototypen weitestgehend beseitigt werden. Darüber hinaus werden neue Anforderungen für die Lastgenerierung in Echtzeit gestellt bzw. die bereits bestehenden Anforderungen werden verschärft. Der neue software-basierte, echtzeitfähige Lastgenerator UniLoG in dieser Arbeit soll insbesondere über folgende Funktionen verfügen: (1) Die generierte Last soll den Spezifikationen des Experimentators in dem Lastmodell exakt entsprechen. Insbesondere sollen die Übergabezeitpunkte der Aufträge in der generierten Auftragssequenz gemäß dem vorgegebenen Auftragsankunftsprozess und die Werte der Auftragsparameter gemäß den vorgegebenen Werten der Auftragsattribute in den R-Zuständen des BVA generiert werden. Es darf also nicht zu Verfälschungen dieser Werte aufgrund von internen Prozessen im Lastgenerator oder anderen externen Einflüssen kommen. (2) Die Lastgenerierung soll an einer konkreten gewählten Schnittstelle IF in einem Knoten eines IP-basierten Rechnernetzes ausgeführt werden können. (3) Während der Lastgenerierung soll die Abhängigkeit des Benutzerverhaltens von den Systemreaktionen berücksichtigt werden, falls der blockierte Makrozustand ϕ b des gewählten BVA-Modells nicht leer ist (d.h. wenn S-Zustände in dem BVA existieren). Aus diesen Anforderungen resultieren folgende Probleme und Aufgaben, die bei der Entwicklung eines neuen, echtzeitfähigen Lastgenerators in der vorliegenden Arbeit zu lösen sind: (P 1 ) Anpassung der gemäß dem BVA-Modell generierten Sequenz abstrakter Aufträge an eine konkrete reale Schnittstelle IF. Dafür muss jeder abstrakte Auftrag in einen entsprechenden realen Auftrag (in dem alle schnittstellen-spezifischen Attribute und Parameter berücksichtigt und ergänzt worden sind) in Echtzeit konvertiert werden. Konkrete Systemreaktionen sind zu verarbeiten und dem BVA als abstrakte Reaktionsnachrichten zur Verfügung zu stellen. (P 2 ) Die relativen Zeiten in der generierten Sequenz sind durch die absoluten Zeiten zu ersetzen, wofür eine entsprechende Abbildung der relativen Zeiten auf die absoluten Zeiten erforderlich ist. (P 3 ) Bei der Übergabe der realen Aufträge an der Schnittstelle IF sollen die in dem BVA-Modell spezifizierten Übergabezeitpunkte der Aufträge streng eingehalten werden. Eine besondere Herausforderung an den neuen, erweiterten Lastgenerator stellt u.a. die Realisierung der netzbedingten Blockierungszustände der Benutzer dar. Die dafür erforderliche Verarbeitung der konkreten Systemreaktionen in der ADAPT-Komponente und die Übergabe an die GAR-Komponente in Form von abstrakten Reaktionsnachrichten (z.b. für die Wahl des Folgezustands für den aktuellen S-Zustand im blockierten Ma

54 Kapitel 3 krozustand ϕ b des gegebenen BVA) lassen die bei der Entwicklung des ersten Prototypen von UniLoG gemachte Annahme über die Möglichkeit der zeitlich getrennten Generierung der abstrakten Aufträge (in der GAR-Komponente) und der realen Aufträge (in der ADAPT-Komponente) aufheben. Die bei der Entwicklung des ersten Prototypen von UniLoG realisierten Komponenten zur Modellkonstruktion und -parametrisierung (PLM, ELM) sollten generell (nach ggf. notwendigen Erweiterungen bzw. Modifikationen) weiter genutzt werden können. Insbesondere sollten die Formate der BVA- und PBVA-Dateien beibehalten werden

55 Kapitel 4 Entwurf für einen echtzeitfähigen Lastgenerator Ein Entwurf für einen neuen software-basierten, echtzeitfähigen Lastgenerator in dieser Arbeit hat sowohl den Anforderungen an die Architektur eines verallgemeinerten Lastgenerators UniLoG (wie in [CoK05] bzw. [Con06] spezifiziert) als auch den neuen zusätzlichen Anforderungen für die Lastgenerierung in Echtzeit (wie in Abschnitt 3.4 aufgezeigt) zu genügen. Ausgehend von der funktionalen Aufteilung der Module in der Architektur eines verallgemeinerten Lastgenerators UniLoG werden in Abschnitt 4.1 zunächst die Probleme skizziert, die für die Lastgenerierung in Echtzeit unter Berücksichtigung von möglichen Systemreaktionen in dem neuen Entwurf gelöst werden sollten. In den Abschnitten 4.2 und 4.3 werden die Hauptkomponenten "Generator für Sequenzen abstrakter Aufträge" (die GAR-Komponente) und der "Adapter" (die ADAPT-Komponente) mit den entsprechenden Algorithmen beschrieben. Um möglichst hohe Präzision bei der Übergabe der generierten Aufträge an das Netz zu erreichen, wird eine Synchronisationsfunktion für die Steuerung der Kontrollübergabe zwischen dem Generator und dem Adapter entworfen und in Abschnitt 4.4 beschrieben. In Abschnitt 4.5 werden die Möglichkeiten für die statistischen Auswertungen der Experimentergebnisse aufgezeigt. 4.1 Überblick über die Gesamtarchitektur Gemäß den Anforderungen an den neuen software-basierten, echtzeitfähigen Lastgenerator UniLoG in dieser Arbeit (siehe Kapitel 3) ist die Generierung von abstrakten Aufträgen gemäß einem gewählten BVA-Modell in der GAR-Komponente und die Generierung von entsprechenden realen Aufträgen an einer gewählten Schnittstelle IF in der ADAPT-Komponente nebenläufig auszuführen. Darüber hinaus kann es in verschiedenen Experimenten zur Lastgenerierung in IPbasierten Rechnernetzen erforderlich sein, die Auftragsströme mehrerer modellierter Benutzer (BVA) in Echtzeit zu überlagern, um ein spezielles Traffic-Mix zu erzeugen (z.b. die Übertragung eines MPEG-codierten Videostroms und einer PCM-codierten Audiosequenz sowie eine Dateiübertragung zur Modellierung einer Bildtelephonie-Anwendung). Die Überlagerung bzw. die Superposition der entsprechenden Auftragssequenzen kann hierbei als ein Spezialfall der Lasttransformation betrachtet werden (vgl. [Bai99], [CWZ03]). Die bereits bestehenden Komponenten zur Modellspezifikation (PLM), Parametrisierung (ELM) und statistischen Auswertung der Experimentergebnisse (EEM) sollen weiter genutzt werden. Sie sind in ihrer Funktionsweise von den geplanten Änderungen nicht betroffen und können nach geringfügigen Anpassungen in den neuen Entwurf übernommen werden. Auf der Basis dieser Überlegungen wurde im Kern des neuen Lastgenerators die Aufteilung in den Generator abstrakter Aufträge (die GAR-Komponente), den optionalen Lasttransformator (LT) und den schnittstellenspezifischen Adapter (die ADAPT-Komponente) vorgenommen (siehe Abbildung 4.1)

56 Kapitel 4 abstrakte Aufträge transformierte Aufträge reale Aufträge GAR N Lasttransformator (optional) LT RQ ADAPT Request Generator IF GAR 1 verarbeitete Reaktionen EQ Event Manager Reaktionen Abbildung 4.1: Architektur eines echtzeitfähigen Lastgenerators Zwischen dem Generator abstrakter Aufträge und dem Adapter besteht eine bidirektionale Produzenten-Konsumenten Beziehung. Einerseits produziert der Generator abstrakte Aufträge in den R-Zuständen des BVA und stellt sie (ggf. nach einer Transformation in LT) in die Auftragswarteschlange RQ des Adapters ein. Diese Aufträge werden vom Adapter konsumiert, indem sie um die schnittstellenspezifischen Attribute bzw. um die fehlenden Attributwerte ergänzt und als reale Aufträge zum spezifizierten Übergabezeitpunkt an IF ausgeliefert werden. Andererseits verarbeitet der Adapter die Systemreaktionen an IF und produziert entsprechende abstrakte Reaktionsnachrichten in der Reaktionswarteschlange EQ. Diese Reaktionsnachrichten werden von dem Generator konsumiert, indem z.b. der Nachfolger des aktuellen Blockierungszustandes im BVA ermittelt wird. Besondere Randbedingungen für den Entwurf der entsprechenden Teilkomponenten für den Generator und den Adapter bilden folgende Umstände: (1) die Warteschlangen RQ und EQ haben eine beschränkte Kapazität, (2) Prozesse sollen nur dann aktiv sein, wenn die zu bedienende Warteschlange nicht leer ist, (3) alle Aufträge sind zeitkritisch (die spezifizierten Übergabezeitpunkte sind einzuhalten). Da die Warteschlangen in diesem Entwurf im gemeinsam genutzten Speicher liegen (alternativ könnte das sog. "Message-Passing" als Methode zur Interprozesskommunikation zwischen dem Generator und dem Adapter eingesetzt werden), soll zur Lösung der Probleme (1) und (2) zunächst der wechselseitige Ausschluss für den Generator und den Adapter beim Zugriff auf RQ und EQ realisiert werden. Darüber hinaus ist eine explizite Synchronisation zwischen dem Generator und dem Adapter erforderlich, um z.b. das Einfügen eines Auftrags in die volle RQ bzw. das Entnehmen eines Auftrags aus der leeren RQ zu verhindern (das Gleiche gilt für die Reaktionen in der EQ). Die Einhaltung der Echtzeitanforderungen (3) in Bezug auf die Auslieferung der realen Aufträge zu präzise spezifizierten Übergabezeitpunkten wird insbesondere durch die folgenden Faktoren erschwert:

57 Entwurf für einen echtzeitfähigen Lastgenerator nicht vernachlässigbare Verarbeitungszeiten der Teilkomponenten: alle an der Lastgenerierung beteiligten Komponenten und Prozesse benötigen zur Bearbeitung des nächsten generierten Auftrages eine bestimmte Verarbeitungszeit, betriebssystembedingte Faktoren: Einfluss anderer Prozesse im Multitasking- Betrieb, modellbedingte Faktoren: Besonderheiten zu generierender Auftragssequenzen, z.b. stoßweises Auftragsaufkommen ( Bursts ). Die Verarbeitungszeiten der an der Auftragsgenerierung beteiligten Komponenten lassen sich generell nicht beseitigen. Die einzigen Möglichkeiten, die Verarbeitungszeiten zu verringern, sind die Optimierung der Modellausführung (in dem Generator bzw. in dem Transformator), der Einsatz einer leistungsfähigeren Hardware bzw. Parallelisierung der Modellausführung auf mehrere Maschinen. Alternativ wäre die Vorbereitung einer bestimmten Anzahl von Aufträgen im Voraus sinnvoll, soweit die Abhängigkeit des Benutzerverhaltens von den Systemreaktionen dies ermöglicht. Die betriebssystembedingten Faktoren resultieren i.d.r. aus dem Multitasking-Betrieb. Der Ablaufplaner des Betriebssystems kann z.b. einen anderen Prozess aktivieren, wenn in dem Adapter gerade kritische Aufträge zur Versendung vorliegen. Die sicherste Methode hier wäre die Verwendung eines Echtzeit-Betriebssystems wie z.b. WindowsCE [MSCE] bzw. RTLinux [RTL]. Weitere Möglichkeiten sind die Verwendung einer dedizierten Station zur Lastgenerierung und gezieltes Abschalten störender (Hintergrund-)Prozesse. In dieser Arbeit wurde der Lastgenerator zunächst auf der Basis eines nicht echtzeitfähigen Betriebssystems entwickelt, wobei ein Übergang zu einem Echtzeitbetriebssystem später ohne grundlegende Änderungen der Architektur vorgenommen werden kann. Hierbei wurde besonders auf gezielte Abschaltung störender Prozesse sowie auf die Vergabe von entsprechenden Prioritäten für die einzelnen Komponenten der Architektur geachtet. Leistungsanalysen des ersten realisierten Prototypen brachten bereits sehr ermutigende Ergebnisse in Bezug auf die Einhaltung der spezifizierten Übergabezeitpunkte der Aufträge auch bei Einsatz eines nicht-echtzeitfähigen Betriebssystems. Besonderheiten in der zu generierenden Auftragssequenz, insbesondere die sog. Auftragsbursts, können letztlich mithilfe der Beobachtung von Dringlichkeit der abstrakten Aufträge und gezielter vorzeitiger Aktivierung des Adapters bewältigt werden, soweit die Auftragszwischenankunftszeiten die maximal benötigte Verarbeitungszeit T ADAPT in dem Adapter nicht unterschreiten 2. Die realisierte Synchronisationsmethode zur sicheren Kontrollübergabe zwischen dem Generator und dem Adapter wird im Abschnitt 4.4 behandelt. 4.2 Generator abstrakter Aufträge Die Rolle des GAR-Generators im Lastgenerierungsprozess ist die Erzeugung einer Sequenz von abstrakten Aufträgen (t i, r i ) durch die Traversierung des entsprechenden 2 Bei Einsatz eines Lasttransformators dürfen die Zwischenankunftszeiten der abstrakten Aufträge auch die maximale Auftragsbearbeitungszeit des Transformators T LT nicht unterschreiten. Während dies bei analytischen Transformatoren relativ unkritisch ist, kann diese Bedingung insbesondere bei simulativen Transformatoren häufig verletzt sein

58 Kapitel 4 PBVA (dabei ist t i der physikalische Übergabezeitpunkt des Auftrags r i ). Generell unterscheiden wir zwischen den logischen (lokalen, relativen) Übergabezeitpunkten in dem BVA-Modell und den physikalischen (globalen, absoluten) Übergabezeitpunkten in der resultierenden Auftragssequenz, die Konvertierung dieser Zeitpunkte nimmt der Generator bei der Erzeugung des nächsten Auftrages vor. Im Initialisierungszustand ϕ i des PBVA ist die logische Zeit im Generator gleich Null. Der Lastgenerierungsprozess beginnt mit dem Verlassen des Initialisierungszustandes ϕ i zum physikalischen Zeitpunkt ι 0. Der physikalische Übergabezeitpunkt t i des nächsten Auftrags ergibt sich aus dem spezifizierten logischen Übergabezeitpunkt im PBVA plus die physikalische Zeit τ 0, zu der der Lastgenerator gestartet wurde (s. Abb. 4.2). t 1= r 1 t 2= r 2 φ a t 3= r 3 t 4=10+1,0 r 4 φ b t 5= r 5 φ a t 6= r 6 (a) Generator: Realzeit τ [ms] τ 0=10 τ 1 τ 2 τ 3 τ 4 τ 5 τ 6 r* 1 r* 2 r* 3 r* 4 τ e1= e 1 r* 5 r* 6 (b) Adapter: Realzeit t [ms] t 0=10 t 1= t 2 = t 3= t 4= t e*1= e* 1 t 5= t 6= Abbildung 4.2: LG gestartet um τ 0 = 10 Uhr physikalischer Zeit; (a) Abstrakte Aufträge (t i, r i ) mit physikalischen Übergabezeitpunkten t i generiert von dem Generator zu den realen Zeitpunkten τ i ; (b) Reale Aufträge (t i, r* i ) generiert von dem Adapter zu den realen Zeitpunkten t i. Während der Traversierung des PBVA werden in den R-Zuständen abstrakte Aufträge als Objekte mit ihren Attributen erzeugt, mit dem entsprechenden physikalischen Übergabezeitpunkt versehen und am Ende der Auftragswarteschlange RQ eingestellt, so dass der nächste zu versendende Auftrag stets im Kopf der RQ steht. In der echtzeitfähigen Version bereitet der Generator abstrakte Aufträge im Voraus vor, solange er nicht in den blockierten Makrozustand φ b des PBVA geht, nicht terminiert ist und die Warteschlange RQ nicht voll wird. Eine bedingungslose Übergabe der Kontrolle an den Adapter nach der Generierung jedes abstrakten Auftrags wäre hier sicher ineffizient, da der physikalische Übergabezeitpunkt (also die Dringlichkeit des abstrakten Auftrags) nicht berücksichtigt bliebe. Andererseits ist es unser Ziel, die abstrakten Aufträge möglichst frühzeitig an den Adapter zu übergeben. Aus diesem Grund erlauben wir zunächst, dass die logische Uhr in dem Generator der physikalischen Uhr in dem Adapter (die der realen Systemzeit entspricht) vorgehen darf. Der Generator kann z.b. in 500µs Realzeit abstrakte Aufträge für 1 sek. logischer Zeit erzeugen und danach in den blockierten Zustand gehen, in dem die logische Uhr von der physikalischen Uhr bei Eintritt des erwarteten Ereignisses wieder eingeholt wird (siehe e* 1 in Abb. 4.2). In dem blockierten Makrozustand φ b des PBVA ist der Generator konzeptionell passiv (d.h. der Lastgenerierungsprozess befindet sich in einem blockierten Zustand in Erwartung bestimmter oder unerwarteter Systemreaktionen), programmtechnisch kann

59 Entwurf für einen echtzeitfähigen Lastgenerator er jedoch sowohl aktiv als auch passiv realisiert werden 3. Die programmtechnisch passive Realisierung wäre vorteilhaft, da in diesem Fall das aktive Warten des Generators auf die Reaktionsnachrichten in der EQ vermieden wird. Wenn die Systemreaktion vorliegt, kann der Adapter den Generator gezielt aktivieren und über die Systemreaktion mit einer entsprechenden Nachricht in der EQ informieren. Der Generator nimmt anschließend folgende Aktionen vor: (1) die Auswahl des nächsten Zustandes in dem PBVA abhängig vom Typ der Reaktion (2) Fortschalten der logischen Uhr auf den Zeitpunkt der Entblockierung, der vom Adapter in der Reaktionsnachricht übermittelt wurde und (3) Verlassen des blockierten Makrozustands φ b des PBVA. Nach diesen Aktionen befindet sich der Generator wieder in dem aktiven Makrozustand φ a und der Lastgenerierungsprozess kann fortgesetzt werden. 4.3 Der Adapter Die Rolle des schnittstellenspezifischen Adapters im Lastgenerierungsprozess ist (a) die Konvertierung der abstrakten Aufträge in der RQ in reale Aufträge an IF sowie (b) Modellierung von Systemreaktionen an IF und Generierung von entsprechenden abstrakten Reaktionsnachrichten in der EQ. Reale Aufträge (t i, r* i ) erzeugt der Adapter durch den Aufruf entsprechender Dienstprimitiven (i.d.r. als API-Funktionen vorhanden) an der Schnittstelle IF zu den physikalischen Übergabezeitpunkten t i, die vom Generator in den abstrakten Aufträgen (t i, r i ) eingetragen wurden (siehe Abb. 4.2). Da die durch einen PBVA spezifizierten abstrakten Aufträge eine Abstraktion der realen Aufträge darstellen, kann ihre Beschreibung nicht immer alle für die Generierung von entsprechenden realen Aufträgen an IF erforderlichen Attribute enthalten. In diesen Fällen werden in dem Adapter zusätzliche Informationen zur Verarbeitung von abstrakten Aufträgen in Form von Konvertierungsvorschriften benötigt, die von dem Experimentator während der Spezifikation des PBVA für die abstrakten Auftragstypen und Auftragsattribute zu erfassen sind. Bei den Konvertierungsvorschriften können insbesondere folgende Fälle auftreten: Direkte 1:1 Zuordnung. In diesem einfachsten Fall kann die Abbildung der Attribute des abstrakten Auftragstyps auf die Parameter der entsprechenden API-Funktion an der Schnittstelle IF eins zu eins vorgenommen werden. Bei der Verarbeitung eines abstrakten Auftrags in einen realen UDP-Auftrag ist das z.b. dann der Fall, wenn die IP-Adresse und die Portnummer des Senders und des Empfängers sowie die zu übermittelnden Nutzdaten (inklusive des Bitmusters) bekannt sind. Fehlende Attribute in der Beschreibung der abstrakten Aufträge. In diesen Fällen werden die in der PBVA-Spezifikation fehlenden Attribute, die Pflichtpa- 3 Zur weiteren Diskussion verschiedener Prozessphasen (konzeptionell aktiv/passiv) und ihrer Realisierung (programmtechnisch aktiv/passiv) im prozessorientierten Modellierungsstil verweisen wir den Leser an dieser Stelle z.b. auf [Pag91] oder [PLC00]

60 Kapitel 4 rameter der Dienstprimitiven an IF sind, mit Standardwerten aus dem PBVA belegt. Kombinierte Zuordnung. Hierbei handelt es sich um die Attribute, die in der abstrakten Auftragsbeschreibung zwar vorhanden sind, deren Konvertierung in die Attribute der realen Aufträge aber nur durch zusätzliche Spezifikationen des Experimentators möglich ist. Bei der Konvertierung eines abstrakten Attributs "Datenlänge" in das Attribut "Nutzdaten" eines UDP-Auftrags muss z.b. das entsprechende Bitmuster gewählt bzw. vom Experimentator spezifiziert werden. Für die Realisierung der zweiten Funktion des Adapters - die Modellierung von Systemreaktionen - gibt es grundsätzlich auch verschiedene Möglichkeiten: (1) Lokales Modell: Generierung von abstrakten Reaktionsnachrichten (und ggf. Emulation von netzbedingten Verzögerungen) gemäß den Spezifikationen in dem blockierten Makrozustand ϕ b des PBVA. (2) Globales (externes) Modell: Generierung von abstrakten Reaktionsnachrichten gemäß einem analytischen oder simulativen Modell des Netzverhaltens, welches in einem Netzemulator ausgeführt wird [Sch06]. Zur Parametrisierung des Netzmodells (bei simulativer Auswertung) können z.b. lastabhängige Traces verwendet werden, die aus den Messungen an einem realen Kommunikationssystem gewonnen wurden [Kam04]. (3) Hybride Methode: Verarbeitung von realen Reaktionen an Schnittstelle IF (z.b. ICMP-Nachrichten "Source Quench", "Destination Unreachable", "Time Exceeded" etc.). Dabei wird insbesondere die Verfügbarkeit der entsprechenden Dienstprimitiven bzw. Funktionscodes oder Rückgabewerte zum Abruf von Statusinformationen des Systems vorausgesetzt. Alle Methoden setzen eine formale Spezifikation der möglichen Reaktionstypen an IF voraus, die von dem Experimentator während der Erstellung des PBVA vorzunehmen ist. Im Fall (3) sind die Attribute der realen Reaktion auf die Attribute der abstrakten Reaktionsnachricht abzubilden. In diesem Entwurf werden die Reaktionsnachrichten zunächst gemäß einem lokalen Modell (gemäß den Spezifikationen in dem blockierten Makrozustand ϕ b des PBVA) generiert. Die Auslagerung der Modellierung von netzabhängigen Aktivitäten des Benutzers in eine separate Adapter-Komponente ermöglicht später die Einbindung von externen Modellen des Netzverhaltens. Wie bereits erwähnt, gibt der Generator die abstrakten Aufträge (t i, r i ) möglichst frühzeitig (also vor ihrem physikalischen Übergabezeitpunkt t i ) an den Adapter weiter, um die Verarbeitungszeit T max, ADAPT in dem Adapter auszugleichen. Der Adapter bereitet zunächst den realen Auftrag (t i, r* i ) vor und wartet dann auf seinen physikalischen Übergabezeitpunkt t i. Um diese aktiven Wartephasen des Adapters möglichst kurz, d.h. im Bereich weniger µs, zu halten bzw. gar zu vermeiden, wurde eine Funktion zur sicheren Kontrollübergabe zwischen dem Generator und dem Adapter entwickelt, auf die im nächsten Abschnitt 4.4 eingegangen wird

61 Entwurf für einen echtzeitfähigen Lastgenerator 4.4 Sichere Kontrollübergabe zwischen dem Generator und dem Adapter Wie bereits erläutert, besteht zwischen dem Generator und dem Adapter eine beidseitige Produzenten-Konsumenten -Beziehung mit der Interprozesskommunikation über den gemeinsam genutzten Speicher (Warteschlangen RQ und EQ). In der Lösung des klassischen Produzenten-Konsumenten -Problems mit Semaphoren (siehe z.b. [Tan03], [Ste99]) ist der Konsument anfänglich blockiert (RQ leer). Der Produzent fängt an, Aufträge zu erzeugen, und blockiert, wenn RQ voll wird. Dabei kann (muss aber nicht!) der Scheduler des Betriebssystems die Kontrolle übergeben: - vom Produzenten (Generator) an den Konsumenten (Adapter) nach dem Einstellen des nächsten Auftrags in die RQ bzw. - vom Konsumenten (Adapter) an den Produzenten (Generator) nach dem Herausnehmen und Bearbeiten des Auftrags aus der RQ. Unter Zugrundelegung einer fairen Bedienstrategie (z.b. Round Robin) würde also eine Abwechslung des Produzenten und des Konsumenten beim Zugriff auf die Warteschlange stattfinden. Eine solche Abwechselung (Alternation) des Generators und des Adapters beim Zugriff auf die RQ wäre in unserem Fall zeitkritischer Aufträge insbesondere bei Unregelmäßigkeiten in der zu generierenden Auftragssequenz und steigenden Verarbeitungszeiten in dem Generator und ggf. dem Transformator (hervorgerufen z.b. durch den Einsatz komplexerer Simulationsmodelle) nicht effizient, da der Übergabezeitpunkt (die Dringlichkeit) der Aufträge nicht berücksichtigt bliebe. Der Scheduler des Betriebssystems könnte z.b. den Generator genau dann aktivieren, wenn Aufträge zur Versendung vorliegen und der Adapter aktiviert werden sollte. Allein durch die Vergabe entsprechender Prioritäten für den Generator und den Adapter lässt sich das Problem nicht lösen. An dieser Stelle wird eine Synchronisationsmethode benötigt, bei der die Entscheidung über die Aktivierung des Generators oder des Adapters anhand der Dringlichkeit der abstrakten Aufträge getroffen wird. Wir nennen einen Auftrag A dringend (urgent) zum Zeitpunkt t NOW, wenn bis zu seinem physikalischen Übergabezeitpunkt t NEXT weniger als eine festgelegte Zeit t übrig bleibt: (t NEXT - t NOW ) < t Die Hauptidee besteht darin, den Generator nach der Erzeugung jedes nächsten abstrakten Auftrags überprüfen zu lassen, ob der Auftrag im Kopf der Warteschlange RQ (also der nächste vom Adapter zu bearbeitende Auftrag) dringend geworden ist und, wenn ja, den Adapter gezielt zu aktivieren. Wird t in der Definition des dringenden Auftrags genau auf die Bearbeitungszeit T ADAPT des Auftrags in dem Adapter gesetzt, steht der Auftrag im Adapter um T ADAPT sek. früher zur Verfügung und kann gerade rechtzeitig an der IF übergeben werden (siehe Abb. 4.3). Das t bzw. die Bearbeitungszeit T ADAPT kann z.b. durch die durchschnittliche Auftragsbearbeitungszeit T MEAN, ADAPT in dem Adapter angenähert werden (ermittelt entweder als Durchschnitt über alle Werte oder ggf. mithilfe geeigneter Fenstertechniken, siehe z.b. [WHW05])

62 Kapitel 4 Nach der Übergabe des Auftrags an IF sollte der Adapter die Kontrolle an den Generator zurückgeben, es sei denn, der nächste zu bearbeitende Auftrag ist inzwischen dringend geworden oder der Generator befindet sich im blockierten Makrozustand ϕ b des BVA. Der Generator wäre nur dann aktiv, wenn: 1) keine dringenden Aufträge in der RQ sind und 2) die RQ nicht voll ist und 3) der aktuelle Zustand nicht in dem blockierten Makrozustand ϕ b des BVA liegt. Der Adapter ist aktiv, wenn: 1) dringende Aufträge in der RQ vorliegen oder 2) die RQ voll ist oder 3) der Generator sich im blockierten Makrozustand ϕ b des BVA befindet. Ein möglicher Wechsel der Aktivphasen des Generators und des Adapters im Lastgenerierungsprozess ist in der Abbildung 4.3 schematisch dargestellt. Die horizontalen Linien stellen jeweils die Zeitachsen für die physikalische Zeit in dem Generator und dem Adapter dar, die aktiven Phasen des Generators sind blau (grau) und die des Adapters sind grün (dunkel schraffiert) markiert. Die Phasen, in denen der Generator konzeptionell aktiv (der aktive Makrozustand ϕ a des BVA), programmtechnisch aber passiv ist, sind hellblau (hell schraffiert) dargestellt. Eine alternative Darstellung eines möglichen zeitlichen Ablaufs zwischen dem Generator und dem Adapter wurde in der Abbildung 4.4 in der Form eines Sequenzdiagramms in UML-Notation präsentiert. Folgende Ausführungen können sowohl im Zeitdiagramm in der Abbildung 4.3. als auch (alternativ) anhand des Sequenzdiagramms in der Abbildung 4.4 nachvollzogen werden. t1= r φ a t5 = t4 = t3 = t2 = t6= r2,r3,r4,r5 r6 t7=10+1,0 r7 φ b t8= r8 φ a t9= r9 τ0=10 t τ1 τ2,τ3,τ4, τ5 τ6 r*1 r*2,r*3,r*4,r*5 τ7 r* 6 r* 7 τ8 τe1= e1 τ9 t r*8 r*9 (a) Generator: Realzeit τ [ms] t0=10 t1= t2 = t3 = t4 = t5 = t6= t7= te*1= e*1 t8= t9= (b) Adapter: Realzeit t [ms] Abbildung 4.3: Sichere Kontrollübergabe zwischen dem Generator und dem Adapter Der Adapter wird vor dem Generator erzeugt und in einen passiven Zustand versetzt, in dem er auf die Aufträge in der RQ wartet. Danach wird der Generator erzeugt. Nach dem Start befindet er sich zunächst in dem Initialisierungszustand ϕ i des BVA. Der Generator und der Adapter verwenden gemeinsam eine Systemuhr um den physikalischen Startzeitpunkt τ 0 (bzw. t 0 = τ 0 im Adapter) des Lastgenerierungsprozesses und die aktuelle physikalische Systemzeit t NOW zu bestimmen

63 Entwurf für einen echtzeitfähigen Lastgenerator Zum Zeitpunkt τ 0 beginnt der Generator seine erste Aktivphase, er verlässt den Initialisierungszustand ϕ i und geht in den aktiven Makrozustand ϕ a des BVA. In den D- Zuständen des BVA wird die logische Uhr des Generators gemäß der spezifizierten Verzögerungs- bzw. Zwischenankunftszeit fortgeschaltet. In den R-Zuständen generiert er abstrakte Aufträge und verwendet den Wert seiner logischen Uhr plus τ 0 als Übergabezeitpunkt des nächsten Auftrags. Wenn der nächste zu bearbeitende Auftrag (t 1, r 1 ) im Kopf der RQ dringend geworden ist ([t 1 - t NOW t] ist erfüllt), beendet der Generator seine erste Aktivphase und aktiviert den Adapter. In seiner ersten Aktivphase bereitet der Adapter den realen Auftrag (t 1, r* 1 ) vor, und übergibt ihn sofort an IF. Danach stellt er fest, dass keine weiteren dringenden Aufträge in der RQ vorliegen und übergibt die Kontrolle zurück an den Generator. In der Aktivphase 2 befindet sich der Generator weiterhin in dem aktiven Makrozustand ϕ a des BVA. Nun generiert er einen Burst von N Aufträgen (t i, r i ), i = 1,, N, wobei N die Kapazität der Warteschlange RQ ist. Der Generator stellt fest, dass die RQ voll ist, und übergibt die Kontrolle an den Adapter. Der Adapter bleibt solange aktiv, bis mindestens ein Auftrag aus der RQ bearbeitet ist. Danach bearbeitet er entweder weitere Aufträge aus der RQ, falls sie dringend geworden sind, oder er gibt die Kontrolle an den Generator zurück. Generator Adapter ϕ i generateabstractrequest() [tnext - tnow t] [tnow tnext] generaterealrequest() ϕ a [tnext - tnow > t] generateabstractrequest() [RQ full] activateadapter() [tnow tnext] generaterealrequest() [tnext - tnow > t] generateabstractrequest() [BLOCKED = TRUE] activateadapter() [tnow tnext] generaterealrequest() ϕ b ϕ a [TERM = TRUE] activateadapter() [tnow > tblocked,max] activategenerator() [BLOCKED = TRUE] recvreaction() [TERM = TRUE] terminateadapter() ϕ t Abbildung 4.4: Eine mögliche Kontrollübergabe zwischen dem Generator und dem Adapter als Sequenzdiagramm in UML-Notation

64 Kapitel 4 In der Aktivphase 3 generiert der Generator die Aufträge (t 6, r 6 ) und (t 7, r 7 ) und geht anschließend in den blockierten Makrozustand ϕ b des BVA. Die Kontrolle geht an den Adapter über. Soweit dringende Aufträge vorliegen, werden sie vom Adapter bearbeitet. Ansonsten ist der Adapter solange aktiv, bis die erwartete Systemreaktion (t e*1, e* 1 ) vorliegt (bzw. bis die maximale Blockierungszeit verstrichen ist). Der Adapter bereitet die entsprechende abstrakte Reaktionsnachricht (τ e1, e 1 ) vor, stellt sie in die Warteschlange EQ ein und aktiviert den Generator. In der Aktivphase 4 verarbeitet der Generator die Nachricht aus der EQ (indem er den Nachfolgerzustand in dem BVA entsprechend auswählt). Danach ist er wieder in dem aktiven Makrozustand ϕ a des BVA. Er produziert die letzten Aufträge (t 8, r 8 ) und (t 9, r 9 ) und geht in den Terminierungszustand ϕ t des BVA. Der Generator ist damit beendet und die Kontrolle wird an den Adapter übergeben, der noch weiter ausstehende Aufträge aus der RQ bearbeiten soll. Nach der Bearbeitung des letzten Auftrags (t 9, r 9 ) terminiert der Adapter. Es ist zu beachten, dass die Prüfung der dringenden Aufträge in der RQ nicht nur von dem Generator, sondern auch von dem Adapter in seinen aktiven Phasen durchgeführt wird. Der Adapter überprüft nach der Bearbeitung jedes Auftrags ebenfalls, ob weitere Aufträge in der RQ inzwischen dringend geworden sind und behält die Kontrolle bei, solange solche dringenden Aufträge in der RQ noch vorliegen. 4.5 Experimental Evaluation Module In der Komponente zur statistischen Auswertung der Experimentergebnisse (engl. Experimental Evaluation Module, EEM) sollen die Daten erfasst werden, die der Experimentator für die statistische Analyse der generierten Auftragssequenzen benötigt. Zusätzlich sollen hier benutzerdefinierte Statistiken generiert werden können, die bei der Analyse der Leistungsfähigkeit und der Präzision des realisierten Lastgenerators in Kapitel 6 dieser Arbeit verwendet werden. In der EEM-Komponente können u.a. folgende Messdaten erfasst werden: die generierten abstrakten Aufträge (als Datenmaterial für weitere Auswertungen bzw. für die graphische Visualisierung), einfache statistische Werte (wie z.b. die Gesamtanzahl der generierten Aufträge, die mittlere Datenrate, die Größe der Nutzdaten, etc.), die Systemfehler sowie Statusmeldungen und Reaktionen, die bei der Übergabe der realen Aufträge an das Netz aufgetreten sind, weitere benutzerdefinierte statistische Messwerte, die während der Übergabe der realen Aufträge an das Netz erfasst bzw. ermittelt werden (z.b. die Differenzen T der spezifizierten und der faktischen Auftragsübergabezeitpunkte, deren Mittelwert Τ, Varianz Var( T) sowie die entsprechende Häufigkeitsverteilung). Die Ermittlung der Mittelwerte und der Varianzen für die während der Lastgenerierung auflaufenden Messwerte (z.b. für die Differenzen T zwischen den spezifizierten und den faktischen Übergabezeitpunkten der Aufträge) kann entweder am Ende der Lastgenerierung anhand der zwischengespeicherten Messwerte oder bereits während der Last

65 Entwurf für einen echtzeitfähigen Lastgenerator generierung rekursiv (d.h. ohne Zwischenspeicherung aller Messwerte) mithilfe der folgenden Berechnungsvorschriften erfolgen: 1) Mittelwert: Sei T(r i ) die Differenz zwischen dem faktischen t IST (r i ) und dem spezifizierten Übergabezeitpunkt t SOLL (r i ) des i-ten Auftrags r i : T(r i ) = t IST (r i ) - t SOLL (r i ). Werden die Werte T(r i ) für alle Aufträge r i (i = 1,2,... N) aus der generierten Auftragssequenz (mit N Aufträgen) in der EEM-Komponente zwischengespeichert, so kann der Mittelwert ΤN der Differenzen zwischen den faktischen und den spezifizierten Übergabezeitpunkten der Aufträge in der generierten Sequenz von N Aufträgen mithilfe der N Τ( ri) Definition des Mittelwerts mit der Formel Τ = N ermittelt werden. Anderenfalls - wenn z.b. die Zwischenspeicherung der Messwerte bei kontinuierlicher Erfas- i= 1 N sung großer Datenmengen im Lastgenerator nicht möglich sein sollte - kann der Mittelwert Τi nach i generierten Aufträgen mitgeführt und fortlaufend aktualisiert werden: i ri Τ = ( + Τ i i Τ ( 1) ( )), i = 1,2,..., Ν, und 0 i 1 Τ =. 0 2) Varianz: Bei der fortlaufenden Berechnung der Varianz muss eine modifizierte Berechnungsvorschrift verwendet werden, die den kritischen Term N i= 1 2 ( Τ( ri) ΤN) umgeht. Dieser Term kann nicht für jeden Messwert sofort berechnet werden, da der Mittelwert ΤN nicht konstant ist und von der Anzahl der Messwerte N abhängt. Durch die Anwendung des Verschiebungssatzes und der Definition des Mittelwertes Τ = N Τ( ri) N gelangt man zur Darstellung N Var( Τ) = N N i = 1 i= 1 2 ( Τ( ri)) N ( N 1) 2 N ( = 1 Τ( ri i )), die sich für jeden eintreffenden Messwert sofort aktualisieren lässt, wenn die Summe der Messwerte Τ( ri) sowie die N 2 Summe ihrer Quadrate ( Τ( ri)) mitgeführt und fortlaufend aktualisiert werden (vgl. [Wei07]). i= 1 Auf der Basis der auflaufenden Messwerte kann z.b. eine entsprechende Häufigkeitsverteilung von T(r i ) für verschiedene Auftragslängen und Zwischenankunftszeiten in der EEM-Komponente ermittelt werden. N i=

66

67 Kapitel 5 Aspekte der Realisierung des Lastgenerators In diesem Kapitel werden die wichtigsten Aspekte der Realisierung des Lastgenerators präsentiert. Zunächst wird in Abschnitt 5.1 die Entscheidung für die Realisierung des Lastgenerators mithilfe von Threads unter Microsoft Windows begründet und die für die Implementierung benötigten und von Windows bereitgestellten Betriebssystemprimitiven kurz vorgestellt. In den Abschnitten 5.2 und 5.3 wird der Ablauf im Generator- Thread und in dem Adapter-Thread betrachtet und die Operationen zur Auswertung eines BVA erläutert. Die entwickelte Synchronisationsfunktion zur sicheren Kontrollübergabe zwischen dem Generator- und dem Adapter-Thread zur Einhaltung der spezifizierten Übergabezeitpunkte der Aufträge bei ihrer Auslieferung an das Netz wird in Abschnitt 5.4 beschrieben. Das verwendete Objektmodell für die Darstellung der Komponenten eines parametrisierten BVA-Models wird anschließend in Abschnitt 5.5 präsentiert. 5.1 Realisierung mit Threads unter Windows Der in Kapitel 4 dieser Arbeit skizzierte Entwurf wurde in einer ersten echtzeitfähigen Version des Lastgenerators UniLoG in Verbindung mit jeweils einem Adapter für die Schnittstellen UDP und TCP mithilfe von Threads unter Microsoft Windows XP (SP2) realisiert. Für die Generierung von UDP- und TCP-Aufträgen im Adapter wurden Windows Sockets (die dem Paradigma der BSD-Sockets im Wesentlichen entsprechen) in der Version 2.2 verwendet. Generell bieten Threads Vorteile bei der Realisierung von Anwendungen, in denen mehrere Aktivitäten auf einmal zu erledigen sind und einige von diesen Aktivitäten von Zeit zu Zeit blockieren können. Beim Zerlegen einer solchen Anwendung - wie dem Lastgenerator in dieser Arbeit - in mehrere Threads wird das Programmiermodell einfacher. Im Vergleich zu den Prozessen bieten Threads zusätzlich folgende Vorteile (vgl. z.b. [Tan03] Kap. 2 bzw. [SGG05] Kap. 4): (1) Alle Threads innerhalb eines Prozesses benutzen gemeinsam denselben Adressraum und haben somit die gleichen globalen Variablen. Jeder Thread darf auf jede Speicheradresse innerhalb des Adressraums des Prozesses zugreifen, so darf er den Keller eines anderen Threads des Prozesses lesen, darauf schreiben oder ihn komplett löschen. (2) Threads lassen sich schneller erzeugen und zerstören, da keine Ressourcen an sie gebunden sind. (3) Wenn alle Aktivitäten rechenzeitintensiv sind, bringen Threads keinen Performance-Gewinn. Gibt es neben umfangreichen Berechnungen jedoch auch umfangreiche Ein-/Ausgabeaktivitäten, dann ermöglicht die Verwendung von Threads, dass sich diese Aktivitäten überlappen und dadurch die Anwendung beschleunigt wird

68 Kapitel 5 (4) Threads sind auf Systemen mit mehreren CPUs nützlich, auf denen echte Parallelität möglich ist. Die Übertragung einer in mehrere Threads strukturierten Anwendung auf ein Multiprozessor-System ist ohne gravierende Eingriffe in die Architektur möglich. Aus diesen Gründen wurde die bestehende konzeptionelle Aufgabenteilung zwischen dem Generator und dem Adapter auf den Generator-Thread (zuständig für die Auswertung des PBVA in Echtzeit) und den Adapter-Thread (zuständig für die Generierung von UDP- und TCP-Aufträgen und Modellierung von Systemreaktionen) übertragen, die auf einem Prozessor quasi-parallel ausgeführt werden. Die netzabhängigen Ein-/Ausgabeaktivitäten werden somit in einen separaten Adapter- Thread ausgelagert. Auf diese Weise kann der Generator-Thread bereits weitere abstrakte Aufträge vorbereiten, während der Adapter-Thread noch mit der Übergabe des letzten dringenden realen Auftrags beschäftigt ist (der Adapter-Thread wartet auf das Ende der Übergabe und ist blockiert). Des Weiteren ermöglicht diese Aufteilung später die Berücksichtigung von Reaktionen, die in einem externen Netzmodell (z.b. in einem Netzemulator wie NetEmu [Sch06]) generiert werden. Der Adapter-Thread ist dann solange blockiert, bis die entsprechende Systemreaktion in dem externen Netzmodell generiert wird und den Adapter erreicht. Threads sind ein Scheduling-Konzept und bieten gegenüber Prozessen den Vorteil einer weniger aufwendigen Kontrollübergabe. Diesen Umstand nutzen wir aus, um die Kontrolle schnell an den Adapter-Thread zu übergeben, falls der nächste zu bearbeitende Auftrag dringend geworden ist (siehe dazu Abschnitt 5.4). Da jeder Thread auf alle Objekte zugreifen darf, die zu seinem Prozess gehören, wurden die Warteschlangen RQ und EQ als globale Objekte in dem für den Generator- und den Adapter-Thread gemeinsamen Adressraum realisiert. Allerdings ist bei der Verwendung von Threads wegen der inhärenten Einführung des Nichtdeterminismus in die Ausführungsfolge einzelner Aktivitäten stets Vorsicht beim Zugriff auf die gemeinsam genutzten Objekte geboten [Lee06]. An dieser Stelle werden geeignete Mittel zur Synchronisation von Threads benötigt, wie z.b. Mutexe oder Monitore. Zur Synchronisation von Threads bietet Windows XP eine ganze Reihe von Primitiven an (wie z.b. kritische Bereiche, Events, Semaphoren, Mutexe, etc.). Wir verwendeten Mutexe für den wechselseitigen Ausschluss beim Zugriff auf die Warteschlangen und Semaphoren für die explizite Synchronisation (Kontrollübergabe mit Berücksichtigung der Dringlichkeit der Aufträge) zwischen dem Generator- und dem Adapter-Thread. Die Benutzung der Synchronisationsprimitiven Mutex und Semaphor folgt unter Windows einem bestimmten Muster. Um z.b. den Mutex mxrq für die RQ anzufordern, ruft der Generator-Thread die Win32 API Wartefunktion WaitForSingleObject() mit mxrq als Parameter auf. Wenn der Adapter-Thread gerade in Besitz von Mutex ist (mxrq ist damit 0 = "nicht signalisiert"), blockiert der Generator-Thread in der Wartefunktion, bis der Adapter-Thread den Mutex mit ReleaseMutex() freigibt (auf 1 = "signalisiert" setzt). Ist der Mutex "signalisiert", wird er atomar auf 0 = "nicht signalisiert" zurückgesetzt und der Generator-Thread verlässt die Wartefunktion und tritt in seinen kritischen Bereich ein. Ein auf einen Mutex bzw. einen Semaphor wartender Thread verbraucht dabei keine Prozessorzeit [MSDN]. Für die möglichst exakte Bestimmung der Übergabezeitpunkte der UDP- und TCP-Aufträge werden Uhrprimitiven mit der Genauigkeit im Bereich weniger µs benötigt

69 Aspekte der Realisierung des Lastgenerators Windows stellt in Win32 API mit QueryPerformanceFrequency() und Query- PerformanceCounter() eine solche Uhr zur Verfügung. Bei der Entwicklung des Werkzeugs UniLoG hat sich der Einsatz von kurzen aktiven Warteschleifen mit Aufruf von QueryPerformanceCounter() als sehr effektive Methode zur Bestimmung der Auftragsübergabezeitpunkte erwiesen [Kol04]. In der echtzeitfähigen Version des Lastgenerators werden wir zusätzlich die Priorität des Adapter-Threads erhöhen (um den Einfluss der betriebssystembedingten Faktoren zu minimieren) und auf die Dauer der aktiven Warteschleifen durch eine explizite Synchronisationsmethode gezielt Einfluss nehmen. Für die Generierung von Aufträgen erforderliche Modellkomponenten und Parameter werden möglichst in der Initialisierungsphase geladen, um ihr Nachladen während der Auftragsgenerierung auszuschließen. Die Klassen zur Beschreibung der Komponenten des PBVA werden am Ende dieses Kapitels im Abschnitt 5.5 zusammenfassend dargestellt. 5.2 Der Generator-Thread Der Generator-Thread ist zuständig für die Ausführung des PBVA in Echtzeit. Die Hauptschleife des Generator-Threads enthält die Operationen zur Ausführung von Aktionen in den Zuständen des PBVA und wird zusätzlich mit der Funktion zur sicheren Kontrollübergabe an den Adapter für die Echtzeitfähigkeit ergänzt (s. Abb. 5.4). Generator-Thread: starte (verlasse INIT-Zustand) um τ 0 Zustand = Nachfolger(INIT) logische Zeit = 0.0 physikalische Zeit = τ 0 (logische Zeit Lastgenerierungsdauer) und (TERM-Zustand nicht erreicht)? nein ENDE TERM-Zustand erreicht! ja nein Zustand = REQUEST? nein Zustand = DELAY? nein Zustand = BLOCKED? ja ja ja Mutex für RQ anfordern Mutex für EQ anfordern abstrakten Auftrag (t NEXT,r NEXT) in RQ erzeugen 1) logische Zeit fortschalten 2) t NEXT = physikalische Zeit = τ 0 + logische Zeit Reaktionsnachricht e i aus der EQ verarbeiten Mutex für RQ freigeben Mutex für EQ freigeben Zustand = Nachfolger(Zustand) Abbildung 5.1: Hauptschleife des Generator-Threads

70 Kapitel 5 Nach dem Start des Generator-Threads wird zunächst der spezifizierte PBVA komplett (d.h. mit allen seinen Zuständen, Zustandsübergängen, Auftragstypen und Parametern) geladen. Danach wird in dem PBVA der Initialisierungszustand φ i (genauer der entsprechende S α -Zustand) gesucht und zum aktuellen Zustand gewählt. Der Generator-Thread verlässt den Initialisierungszustand φ i des PBVA zum physikalischen Zeitpunkt τ 0 und wird fortgesetzt, solange der Terminierungszustand φ t nicht erreicht und die maximale Lastgenerierungsdauer nicht überschritten wurde (siehe Abbildung 5.1). Die logische Zeit wird in den D-Zuständen gemäß den spezifizierten Modellparametern für die Verzögerungs- bzw. Zwischenankunftszeit der Aufträge fortgeschaltet. Der Übergabezeitpunkt t NEXT des nächsten abstrakten Auftrags in den R-Zuständen wird auf die aktuelle physikalische Zeit gesetzt, die sich als (t NEXT = τ 0 + aktuelle logische Zeit) ergibt. Die Zugriffe auf die Warteschlangen RQ und EQ erfolgen im wechselseitigen Ausschluss mit dem Adapter und sind jeweils mit einem Mutex für RQ und einem Mutex für EQ geschützt. Wenn der Generator in Besitz des entsprechenden Mutex ist, überprüft er zunächst, ob RQ voll bzw. EQ leer ist, um einen möglichen illegalen Zustand zu vermeiden. Wie aus der Abbildung 5.1 ersichtlich, erfolgt die Generierung des nächsten abstrakten Auftrags konzeptionell zeitlos. Nach der PBVA-Konvention sind die einzigen Zustände, in denen die logische (Lastgenerierungs-)Zeit fortgeschaltet werden darf, die D-Zustände des PBVA. Die Auswahl des Nachfolgerzustandes im PBVA erfolgt ebenfalls konzeptionell zeitlos gemäß den Spezifikationen an den Zustandsübergängen des PBVA (z.b. mit Traces, Übergangswahrscheinlichkeiten oder mit speziellen Prozeduren, vgl. Kap. 2). Im Folgenden soll kurz auf die Ermittlung des Nachfolgerzustandes mithilfe von a) Übergangswahrscheinlichkeiten und b) speziellen Prozeduren eingegangen werden. a) Ermittlung des Nachfolgerzustandes mithilfe von Übergangswahrscheinlichkeiten Für die Ermittlung des nächsten Zustands Z NEXT des aktuellen Zustands Z j wurde im PBVA-Objekt die Hilfsfunktion ChooseNextState(Z j ) vorgesehen, die eine spezielle Prozedur Nachfolger() für den aktuellen Zustand aufruft. Mögliche Nachfolgerzustände Z i und die entsprechenden Übergangswahrscheinlichkeiten p ji für den Übergang aus dem aktuellen Zustand Z j in den Zustand Z i liegen in Tupeln der Form (Z i, p ji ) im Vektor der Nachfolgerzustände von Z j (Attribut m_vnext des Zustandsobjekts von Z j ). Der nächste Zustand Z NEXT wird wie folgt bestimmt: (1) Der Index i von Z NEXT wird initial auf den Index des aktuellen Zustands im Zustandsvektor gesetzt. (2) Die n Elemente (Z i, p ji ), i = 1,..., n des Nachfolgervektors werden sukzessive eingelesen. Das gesamte Intervall Ω = (0, 1) wird in (n + 1) disjunkte Intervalle (0, p j1 ), [p j1, p j1 + p j2 ), [p j1 + p j2, p j1 + p j2 + p j3 ),..., [p j1 + p j p jn, 1) aufgeteilt. (3) Eine gleichverteilte Zufallszahl ddist aus dem Intervall (0, 1) wird gezogen. (4) Ein Zustand Z i aus dem Vektor der Nachfolgerzustände, für dessen Index i die Bedingung p j(i-1) ddist < p j(i+1) erfüllt ist, wobei p j0 := 0 und p j(n+1) :=1, wird zum Nachfolgerzustand gewählt. Der Index i wird als Resultat von

71 Aspekte der Realisierung des Lastgenerators Nachfolger() an die aufrufende Methode ChooseNextState() zurückgegeben. Deterministische Zustandsübergänge werden als Transitionen mit Übergangswahrscheinlichkeit 1.0 realisiert. b) Ermittlung des Nachfolgerzustandes mithilfe von speziellen Prozeduren Wie in Kapitel 2 bereits beschrieben, stellen Prozeduren eine generische Methode zur Ermittlung des Nachfolgerzustandes im PBVA und sind besonders für die Realisierung der Zustandsübergänge von ϕ b zu ϕ a wichtig, da diese von der Systemreaktion (von dem Reaktionstyp und der Reaktionszeit) abhängig sein können. Für die Realisierung der Zustandsübergänge von einem Zustand S j in ϕ b zu den Zuständen R i in ϕ a werden die Tupel (Z i, p ji ) der Nachfolgerzustände um folgende Bedingungsvariablen und Vergleichsoperatoren ergänzt (die Übergangswahrscheinlichkeit p ji ist in diesen Fällen gleich 0.0): - den Reaktionstyp gvet(s j,z i ) und den entsprechenden Vergleichsoperator OP(S j,z i,gvet(s j,z i )), für den in diesem Fall nur der Operator = möglich ist. Die Bedingung am Zustandsübergang zu Z i evaluiert zu 1 (TRUE), wenn der Typ ET(S j ) der letzten im aktuellen Zustand S j aufgetretenen Reaktion gleich dem spezifizierten Reaktionstyp gvet(s j,z i ) ist. - die Dauer gvd(s j,z i ) der systembedingten Verzögerung im aktuellen Zustand S j und einem Vergleichsoperator OP(S j,z i,gvd(s j,z i )), der bei der Spezifikation der Zustandsübergänge aus dem S j im PBVA auszuwählen ist (zunächst stehen hier die Operatoren <, >,, zur Verfügung). Ein Zustand R i wird zum Nachfolgerzustand gewählt, wenn alle Bedingungen an dem Zustandsübergang {Z i, 0.0, gvet(s j,z i ), OP(S j,z i,gvet(s j,z i )), gvd(s j,z i ), OP(S j,z i,gvd(s j,z i ))} zu 1 (TRUE) evaluieren (eine UND-Verknüpfung 4 ). Die Prozedur Nachfolger() schaltet die logische Zeit in dem Verzögerungszustand D ji (der zwischen S j und R i liegt und laut der PBVA-Konvention nur einen Nachfolger R i hat) gemäß der Reaktionsdauer D(S j ) fort und liefert den Index i an die aufrufende Methode ChooseNextState() zurück. Für die Realisierung der Zustandsübergänge aus dem Zustand R j innerhalb des aktiven Makrozustandes ϕ a können z.b. die Bedingungsvariablen gvnumberofrequests(r j,z i ) (die Anzahl der direkt hintereinander generierten Aufträge desselben Auftragstyps im Zustand R j ) und gvtotalrequests(r j,z i ) (die Gesamtanzahl der im Zustand R j generierten Aufträge) sowie die entsprechenden Vergleichsoperatoren definiert werden. Die Auswertung dieser Bedingungen erfolgt analog in der Prozedur Nachfolger(). 5.3 Der Adapter-Thread Der Adapter-Thread kann wahlweise entweder den UDP-Adapter oder den TCP-Adapter ausführen. Der Experimentator legt durch die Wahl der Schnittstelle für Lastgenerie- 4 Die Realisierung von weiteren Verknüpfungsoperatoren ist ohne weiteres möglich

72 Kapitel 5 rung IF fest, welcher Adapter auszuführen ist. Die Hauptschleife des Adapter-Threads ist in der Abbildung 5.2 skizziert. Adapter-Thread physikalische Zeit = t 0 = τ 0 physikalische Zeit Generierungshorizont? ja Generator in ϕ b? nein Mutex für RQ anfordern abstrakten Auftrag (t NEXT, r NEXT) aus RQ extrahieren nein ja ENDE abstrakte Reaktionsnachricht (t e, e) vorbereiten Mutex für EQ anfordern Mutex für RQ freigeben realen Auftrag (t NEXT, r* NEXT) vorbereiten abstrakte Reaktionsnachricht (t e, e) in EQ erzeugen Mutex für EQ freigeben t NOW t NEXT erreicht? nein physikalische Zeit = t e+t 0 ja realen Auftrag (t NEXT, r* NEXT) an IF übergeben physikalische Zeit = t NEXT Abbildung 5.2: Hauptschleife des Adapter-Threads Sei t 0 = τ 0 der Startzeitpunkt des Lastgenerierungsprozesses im Generator-Thread. Der Adapter-Thread wird zum Zeitpunkt t < t 0 (d.h. vor dem Generator-Thread) gestartet und fortgesetzt, solange der Lastgenerierungshorizont (t 0 + Lastgenerierungsdauer) nicht erreicht ist (vgl. Abbildung 5.2). Soweit keine Nachricht vom Generator-Thread über die Blockierung in dem Makrozustand ϕ b vorliegt, bearbeitet der Adapter-Thread die abstrakten Aufträge aus der RQ, anderenfalls führt er die Operationen zur Modellierung der Systemreaktion aus. Der wesentliche Unterschied zwischen den Protokollen UDP und TCP besteht darin, dass beim TCP eine virtuelle Verbindung zu der Kommunikationspartnerinstanz aufgebaut und aufrechterhalten wird. So erforderte die Realisierung eines TCP-Adapters auch zwingend die Realisierung einer TCP-Lastsenke für die Modellierung der Kommunikationspartnerinstanz. Eine solche Lastsenke wurde als verbindungsorientierter Server mit konfigurierbarer IP-Adresse und Portnummer implementiert (s. die Spezifikation von TCPServer im Anhang A). Bei der Verarbeitung der abstrakten Aufträge in dem TCP- Adapter muss darüber hinaus sichergestellt werden, dass die virtuelle Verbindung mit

73 Aspekte der Realisierung des Lastgenerators connect() aufgebaut wurde, bevor das erste Datenpaket mit send() übergeben werden kann 5. Für den UDP-Adapter wurde ebenfalls eine UDP-Lastsenke (mit einstellbarer IP- Adresse und Portnummer) implementiert (s. die Spezifikation von UDPServer im Anhang A). Obwohl die Lastsenke nicht zwingend erforderlich ist, können durch ihren Einsatz die störenden ICMP-Messages "Destination Unreachable" in den Experimenten vermieden werden. Im Folgenden gehen wir kurz auf den Adapter für UDP ein. Ein UDP-Auftrag wird durch den Aufruf der Funktion sendto() aus der Windows-Sockets API erzeugt. Die Pflichtattribute eines UDP-Auftrags sind die IP- und die Portnummer des Senders, die IP- und die Portnummer des Empfängers, die zu übermittelnden Nutzdaten und die Nutzdatenlänge. Falls in den abstrakten Aufträgen (t NEXT, r NEXT ) in der RQ fehlend, werden diese Attribute in den realen UDP-Aufträgen (t NEXT, r* NEXT ) vor dem Aufruf von sendto() mit spezifizierten Standardwerten aus dem PBVA vorbelegt (z.b. wird ein Bitmuster gewählt, falls nur die Datenlänge als Auftragsattribut spezifiziert wurde). Die Zuordnung der abstrakten Auftragstypen und Auftragsattribute zu den entsprechenden Socket-Funktionen und Funktionsparametern wird in Fünfertupeln der Form (Auftragstypname, Attributname, Funktionsname, Parametername, Standardwert) in einer Liste gespeichert. Diese Zuordnung ist von dem Experimentator für jeden Auftragstyp und jedes Auftragsattribut im PBVA vorzunehmen. Wenn die Nachricht über die Blockierung des Generator-Threads in einem Zustand S i von ϕ b vorliegt, werden in dem Adapter folgende Operationen je nach Art der Modellierung von Systemreaktionen ausgeführt (vgl. Abschnitt 4.3): (1) Werden reale Reaktionen des unterliegenden Transportsystems in dem PBVA- Modell berücksichtigt ( hybride Methode, vgl. Abschnitt 4.3), ist der Systemzustand nach dem Erzeugen des letzten UDP-Auftrags zu untersuchen, bevor eine entsprechende abstrakte Reaktionsnachricht generiert werden kann. Dafür steht der Rückgabewert des Aufrufs von sendto() zu einer bestimmten Rückgabezeit zur Verfügung (mögliche Rückgabewerte und Fehlercodes sind im Anhang B zusammengefasst). Die im Zustand S i zu berücksichtigenden Fehlercodes sind in Form von Vierertupeln (S-Zustand, Funktionsname, Fehlercode, abstrakter Reaktionstyp) von dem Experimentator zu erfassen. (2) Eine entsprechende abstrakte Reaktionsnachricht wird als Objekt der Klasse LGReaktion erzeugt (siehe Abschnitt 5.5), dabei werden der Reaktionstyp und die Reaktionszeit gemäß den Spezifikationen im Zustand S i gesetzt ( lokales Modell, vgl. Abschnitt 4.3), es sei denn, sie wurden bereits unter (1) anhand einer realen Reaktion des Transportsystems ermittelt. Die neue Reaktionsnachricht wird in EQ gemäß der Reaktionszeit eingestellt. 5 Wir nehmen an dieser Stelle allerdings an, dass bei der Spezifikation des PBVA die richtige Reihenfolge der Dienstprimitiven vom Experimentator eingehalten wird. Wenn zum Zeitpunkt der Übergabe des ersten Datenpaketes doch noch keine TCP-Verbindung aufgebaut sein sollte, gibt der TCP-Adapter einen entsprechenden Fehlercode zurück

74 Kapitel 5 Zur Bestimmung des Übergabezeitpunktes der UDP-Aufträge werden kurze aktive Warteschleifen (mit dem Aufruf der Win32 API-Funktion GetPerformanceCounter()) eingesetzt. Die Thread-Priorität des Adapter-Threads wird hier mit SetThreadPriority() um 2 Punkte über der normalen Priorität angehoben, um die Einflüsse anderer Threads im System zu minimieren. Andere ressourcen-sparende Uhrprimitiven (z.b. unterbrechbare Timer) sind an dieser Stelle leider nicht geeignet, da ihre Auflösung an die Interrupt-Periode des Schedulers gebunden und damit für unseren Fall viel zu grob ist (z.b. werden die Interrupts bei Windows XP SP2 ca. alle 10ms ausgelöst, s. [MSDN]). Bei der Modellierung von Systemreaktionen ist es dagegen zu erwarten, dass die systeminduzierten Blockierungszeiten des Benutzers im Bereich von ms liegen. Wenn die Blockierungszeit vorher bestimmt und größer als die Interrupt-Periode des Schedulers (ca. 10ms) ist, kann in dem Adapter-Thread ein Timer für das größte Vielfache von 10ms, das kleiner der Blockierungsdauer ist, gesetzt werden. Damit würde der Adapter-Thread auch in den Blockierungsphasen des Generators keine Prozessorzeit unnötig verbrauchen. Die im nächsten Abschnitt beschriebene Synchronisationsfunktion erlaubt eine mögliche Verkürzung der aktiven Wartephasen in dem Adapter. 5.4 Synchronisation zwischen dem Generator-Thread und dem Adapter-Thread Zur Realisierung der Synchronisation zwischen dem Generator-Thread und dem Adapter-Thread werden zwei binäre Semaphoren generatoraktiv (initialisiert mit 1, "signalisiert") und adapteraktiv (initialisiert mit 0, "nicht signalisiert") verwendet. Der Adapter-Thread wird zuerst gestartet und bleibt in dem Aufruf von WaitForSingle- Object() blockiert, bis der Generator-Thread den Wert des Semaphors adapter- Aktiv mit ReleaseSemaphore() auf 1 ("signalisiert") erhöht (siehe Abb ). Da der Semaphor generatoraktiv mit 1 ("signalisiert") initialisiert wurde, kann der Generator-Thread seinen ersten Aufruf von WaitForSingleObject() passieren, wobei der Wert von generatoraktiv im Aufruf von WaitForSingleObject() atomar auf 0 ("nicht signalisiert") gesetzt wird. Der Generator kann nun die Operationen in dem aktuellen Zustand des PBVA ausführen (z.b. er generiert den nächsten Auftrag (t NEXT, r NEXT )) und bestimmt den Nachfolgerzustand im PBVA (z.b. einen Zustand aus dem blockierten Makrozustand ϕ b ). Der Generator-Thread überprüft anschließend, ob (1) RQ voll geworden ist oder (2) der neue Zustand im blockierten Makrozustand ϕ b des PBVA liegt oder (3) der nächste vom Adapter zu bearbeitende Auftrag (t NEXT, r NEXT ) dringend geworden ist (t NOW -t NEXT < t). Falls keine dieser Bedingungen erfüllt ist, wird der Wert des Semaphors generator- Aktiv wieder auf 1 ("signalisiert") erhöht, so dass der Generator-Thread den nächsten Aufruf von WaitForSingleObject() passieren kann und in die nächste Iteration seiner Hauptschleife gelangt. Anderenfalls wird der Semaphor adapteraktiv signali

75 Aspekte der Realisierung des Lastgenerators siert und der Generator-Thread blockiert in seinem nächsten Aufruf von WaitFor- SingleObject(), da generatoraktiv gleich 0 ("nicht signalisiert") ist. An dieser Stelle wird der Scheduler des Betriebssystems aufgerufen, der den Adapter-Thread aus der Blockierung in dem Aufruf von WaitForSingleObject() löst. Generator-Thread: starte (verlasse INIT-Zustand) um τ0 Adapter-Thread Zustand = Nachfolger(INIT) logische Zeit = 0.0 SEM: generatoraktiv = 1 physikalische Zeit = τ0 SEM: adapteraktiv = 0 (logische Zeit Lastgenerierungsdauer) und (TERM-Zustand nicht erreicht)? ja generatoraktiv = 1? nein nein ENDE physikalische Zeit Generierungshorizont? ja adapteraktiv = 1? nein nein ENDE ja WaitForSingleObject(generatorAktiv) ja WaitForSingleObject(adapterAktiv) Signal vom Adapter-Thread Signal vom anderen Generator-Thread Signal vom Generator-Thread Operationen in den Zuständen des PBVA Generator in ϕb? nein ja RQ voll or Zustand = BLOCKED or tnext- tnow t? ja nein generatoraktiv = 1 adapteraktiv = 1 Generierung von realen Aufträgen RQ leer? ja Modellierung von Reaktionen generatoraktiv = 1 nein tnext- tnow t? ja adapteraktiv = 1 nein generatoraktiv = 1 Abbildung 5.3: Kontrollübergabe in dem Generator-Thread Abbildung 5.4: Kontrollübergabe in dem Adapter-Thread Der Adapter-Thread gelangt in seine Hauptschleife und kann den nächsten Auftrag aus der RQ bearbeiten oder die Systemreaktion modellieren, wenn die Nachricht über die Blockierung des Generators in ϕ b bereits vorliegt (siehe Abb. 5.4). Nach der Generierung des nächsten UDP- bzw. TCP-Auftrags überprüft der Adapter-Thread, ob die RQ leer geworden ist, und, wenn ja, aktiviert er den Generator-Thread, indem er den Semaphor generatoraktiv signalisiert (auf 1 erhöht). Wenn die RQ nicht leer ist, überprüft der Adapter, ob der nächste zu bearbeitende abstrakte Auftrag (t NEXT, r NEXT ) ebenfalls dringend geworden ist und behält bzw. gibt die Kontrolle an den Generator-Thread ab, indem er den Semaphor adapteraktiv bzw. generatoraktiv signalisiert. Nach der Erzeugung der abstrakten Reaktionsnachricht und der Modellierung der Blockierungsdauer signalisiert der Adapter-Thread zwingend den Semaphor generatoraktiv. Bei allen möglichen Varianten der PBVA sollte die Termination der beiden Threads sichergestellt werden. Der Adapter könnte z.b. eine Reaktionsnachricht für den Zeitpunkt generieren, der bereits hinter dem Lastgenerierungshorizont liegt, und würde versuchen, den bereits terminierten Generator-Thread zu aktivieren. In solchen Fällen wird

76 Kapitel 5 eine Sonderbehandlung vorgenommen, die in den Abbildungen zur Vereinfachung nicht eingezeichnet wurde. Mit dem Parameter t kann somit gesteuert werden, um wie viele µs früher der Generator-Thread die Kontrolle an den Adapter-Thread übergibt. Damit lässt sich die auftragslängenabhängige Bearbeitungszeit in dem Adapter-Thread T ADAPT berücksichtigen. Bei konstanter Auftragslänge ist die Bearbeitungszeit in dem Adapter ebenfalls konstant, so sollte t = T ADAPT gewählt werden. Bei variabler Auftragslänge könnte t durch die mittlere Bearbeitungszeit T MEAN, ADAPT angenähert werden (vgl. Abschn. 4.3). 5.5 Klassen zur Beschreibung des parametrisierten BVA Die zur Beschreibung eines PBVA definierten Klassen sind mit den entsprechenden Assoziationen und Kardinalitäten in einem Klassendiagramm in der Abbildung 5.5 dargestellt. Nach dem Start des Generator-Threads wird zunächst der vollständige PBVA komplett mit allen seinen Zuständen, Zustandsübergängen, Auftrags- und Reaktionstypen sowie ihren Parametern geladen. Die Hauptklasse PBVA enthält die Zustände des PBVA als Objekte der Klasse LGZustand in dem Vektor m_vzustaende. Die Nummer des aktuellen Zustands im PBVA wird in dem Attribut m_ncurrentstate festgehalten. Alle in dem Benutzermodell definierten Auftragstypen werden in dem Vektor m_vauftragstypen erfasst. Die zur Parametrisierung der Modellkomponenten benötigten Traces werden beim Laden des PBVA in den Vektor m_vtraces übertragen. Die Methode ExecutePBVA() dient der Ausführung des parametrisierten Benutzermodells und führt in Abhängigkeit vom Typ des aktuellen Zustands entsprechende spezielle Operationen aus (z.b. die Generierung des nächsten abstrakten Auftrags in den R-Zuständen oder Fortschalten der logischen Uhr in den D-Zuständen). Die Methoden FindInitState() und ChooseNextState() werden jeweils zur Ermittlung des Initialisierungszustands bzw. des Nachfolgerzustands während der Lastgenerierung verwendet. Die allen Zustandstypen gemeinsamen Merkmale wie die Zustandsnummer, der Name, der Zustandstyp, der entsprechende Makrozustand sowie die Menge der Zustandsübergänge werden in der Basisklasse LGZustand zusammengefasst (siehe Abb. 5.5). Die Zustandsübergänge werden als Objekte der Klasse LGTransition erzeugt und in den Elementen des Vektors m_vnext des Zustandsobjekts erfasst. Die Methode Choose- NextState() im PBVA ruft die Prozedur Nachfolger() in dem aktuellen Zustandsobjekt auf, um den nächsten Zustand im PBVA zu bestimmen. Die Prozedur Nachfolger() übernimmt die Auswertung der Zustandsübergänge im Vektor m_vnext, die im Abschnitt 5.2 bereits beschrieben wurde. Die vom Zustandstyp abhängigen Merkmale (wie z.b. der zugeordnete Auftragstyp oder die Verzögerungsdauer bzw. die Zwischenankunftszeit der Aufträge) werden in den abgeleiteten Klassen LG_R für die R-Zustände, LG_D für die D-Zustände sowie LG_S für die S-Zustände modelliert. R-Zustände: Die Nummer des zugeordneten Auftragstyps wird in dem Attribut m_nat in der entsprechenden Klasse LG_R erfasst und von der Methode setauftragstyp() verändert. Ein Auftragstyp ist durch die Merkmale Nummer, Name, und Beschreibung sowie die Menge der zugeordneten Auftragsattribute (Vektor m_vattribute) in der

77 Aspekte der Realisierung des Lastgenerators Klasse LGAuftragstyp beschrieben. Die Methode generierenextauftrag() (aufgerufen aus der Methode ExecutePBVA() des PBVA-Objekts) generiert den nächsten Auftrag des zugeordneten Auftragstyps als Objekt der Klasse LGAuftrag und stellt ihn in die Auftragswarteschlange RQ gemäß dem Übergabezeitpunkt m_dsendezeit ein. PBVA # m_vzustaende: vector<lgzustand*> # m_ncurrentstate: int # m_vauftragstypen: vector<lgauftragstyp*> # m_vtraces: vector<lgtrace*> + ExecutePBVA(): bool + FindInitState(): int + ChooseNextState(current: int): int + LoadTraces(): bool + LoadPBVA(ar: Archive): bool + SavePBVA(ar: Archive): bool 1 1..* LGZustand # m_nr: int # m_name: string # m_emacrostate: EMacroState # m_estatetype: EStateType + m_vnext: vector <LGTransition*> + Nachfolger(): int 1 0..* LGTransition + m_to: int + m_prob: double + m_nrtyp: int + m_drtime: double LG_R LG_D LG_S # m_nat: LGAuftragstyp - setauftragstyp(at: LGAuftragstyp) - generierenextauftrag(): LGAuftrag # m_ddelaytime: ValueObj - setdelaytime(v: ValueObj) - procsimtime(v: ValueObj) # m_nrt: LGReaktionstyp - setreaktionstyp(rt: LGReaktionstyp) - generierenextreaktion():lgreaktion LGAuftragstyp # m_nr: int # m_name: string # m_desc: string # m_vattribute: vector<lgattribut*> * LGAuftrag # m_dsendezeit: double # m_at: LGAuftragstyp 1..* LGAttribut # m_nr: int # m_name: string # m_desc: string + m_eattrtype: EAttrType + m_edomain: EValueDomain + m_value : ValueObj + setvalue(v: ValueObj) + getvalue(): ValueObj EValueDomain = {CONST, DISTRIBUTION, TRACE} 1..* LGReaktionstyp # m_nr: int # m_name: string # m_desc: string # m_vattribute: vector<lgattribut*> 1 LGReaktion # m_drtime: double # m_rt: LGReaktionstyp 1 1..* Abbildung 5.5: Klassen zur Beschreibung des parametrisierten PBVA D-Zustände: die Zwischenankunftszeiten der Aufträge bzw. die Dauer der netzbedingten Verzögerungen der Benutzer werden in dem Attribut m_ddelaytime der Klasse LG_D erfasst und können durch die Methode setdelaytime() verändert werden. Die Methode ProcSimTime() übernimmt während der Lastgenerierung die Fortschaltung der logischen Uhr entsprechend der in dem aktuellen D-Zustand spezifizierten Verzögerungszeit

78 Kapitel 5 S-Zustände: Die Nummer des Typs der erwarteten Reaktion in einem S-Zustand wird in dem Attribut m_nrt der Klasse LG_S erfasst und von der Methode setreaktionstyp() verändert. Ein Reaktionstyp ist durch die Merkmale Nummer, Name und Beschreibung sowie die Menge der entsprechenden Reaktionsattribute (Vektor m_vattribute) in der Klasse LGReaktionstyp charakterisiert. Die Methode generierenextreaktion() (aufgerufen aus der Methode ExecutePBVA() des PBVA-Objekts) generiert die nächste Reaktionsnachricht als Objekt der Klasse LGReaktion und stellt sie in die Reaktionswarteschlange EQ gemäß der Reaktionszeit m_drtime ein. Ein Auftrags- bzw. Reaktionsattribut wird durch die Merkmale Nummer, Name, Beschreibung, den Attributdatentyp (z.b. Integer, String, IP_Address) sowie die Wertedomäne (z.b. konstante Werte, Trace oder Verteilung) und den Attributwert in der Klasse LGAttribut beschrieben. Weitere Attribute zur Spezifikation von Verteilungen und Traces sind in der Abbildung 5.5 zur Vereinfachung der Darstellung ausgelassen. An mehreren Stellen in der Klassenhierarchie (z.b. bei der Realisierung der Liste der Zustände des PBVA, der Liste der Zustandsübergänge, der Auftragsattribute etc.) ist die Container-Klasse vector aus der C++ Standard Template Library (STL) zum Einsatz gekommen. Für die Realisierung der Prioritätswarteschlangen RQ und EQ wurde die Container-Klasse queue als Basis verwendet. Für die Beschreibung der entsprechenden Attribute und Operationen dieser STL-Klassen verweisen wir den Leser an dieser Stelle auf [Str97] bzw. [Lip96]

79 Kapitel 6 Validierung des realisierten Lastgenerators Bei der Validierung des realisierten verallgemeinerten Lastgenerators in der vorliegenden Arbeit wird davon ausgegangen, dass die zur Lastgenerierung eingesetzten Lastmodelle ihre Validierungsphase bereits erfolgreich passiert haben. In den Begriffen der Architektur eines verallgemeinerten Lastgenerators (vgl. Kapitel 3) ausgedrückt, bedeutet das, dass eine entsprechende Validierung bis zur Ebene der Spezifikationen in dem PBVA-Modell bereits vollzogen wurde. Somit bedürfen noch folgende Lastgenerierungsschritte einer weiteren Validierung (vgl. Abb. 6.1): (1) die Generierung von abstrakten Aufträgen in der GAR-Komponente (Übergang von den formalen PBVA-Spezifikationen zu den abstrakten Aufträgen, die als Objekte generiert werden), (2) die Generierung von realen Aufträgen an einer gewählten Schnittstelle IF in der ADAPT-Komponente (Übergang von den abstrakten Aufträgen zu den realen Aufträgen an der UDP- und der TCP-Schnittstelle). Executable Load Models (ELM) (PBVA-Modellbank) Parameterspezifikationen auf PBVA-Ebene Validierung, Schritt 1 abstrakte Aufträge mit SOLL-Übergabezeitpunkten Generator for sequences of Abstract Requests (GAR) Adapter (ADAPT) PBVA-Spezifikationen, logische Zeiten abstrakte Aufträge, physikalische Zeiten Validierung, Schritt 2 reale Aufträge mit IST-Übergabezeitpunkten reale Aufträge, physikalische Zeiten Schnittstelle IF (UDP, TCP) Abbildung 6.1: Schritte bei der Validierung des realisierten verallgemeinerten Lastgenerators UniLoG. Für die Validierung der Lastgenerierung im Schritt 1 (siehe Abb. 6.1) - beim Übergang von den formalen PBVA-Spezifikationen zu den abstrakten Aufträgen - ist sicherzustellen, dass: (a) die einzelnen abstrakten Aufträge korrekt sind, d.h. dass die Werte der Auftragsattribute sowie die Übergabezeitpunkte der abstrakten Aufträge gemäß den entsprechenden Parameterspezifikationen in dem PBVA-Modell von der GAR-Komponente generiert werden. Während dies bei den Parametern, die als Konstante oder gemäß

80 Kapitel 6 Traces zu wählen sind, generell kein Problem darstellen sollte, muss bei den Werten der Auftragsattribute bzw. bei den ZAZ der Aufträge, die gemäß einer Verteilung zu wählen sind, die Güte der Zufallszahlen stets überprüft werden. Die internen Zufallszahlengeneratoren moderner Betriebssysteme liefern i.d.r. gleichverteilte (Pseudo-)Zufallszahlen. Mithilfe der inversen Transformation der Verteilungsfunktion, die in Kapitel 2 dieser Arbeit beschrieben wurde, können - bei hinreichend groß gewählter Stichprobe (z.b. durch die Vorgabe einer entsprechenden Lastgenerierungsdauer im Lastgenerator) - auch Zufallszahlen anderer Verteilungen (Exponential-, Erlang- sowie Normal-Verteilung) mit hinreichender Güte erzeugt werden. (b) die generierte Sequenz von abstrakten Aufträgen korrekt ist, d.h. die Reihenfolge der generierten abstrakten Aufträge entspricht der vorgegebenen Reihenfolge der Aufträge im Fall eines PBVA-Modells mit deterministischen Zustandsübergängen oder ist eine mögliche Trajektorie eines durch ein nicht-deterministisches PBVA- Modell spezifizierten stochastischen Prozesses. Für die Validierung der Lastgenerierung im Schritt 2 - beim Übergang von den abstrakten Aufträgen in der GAR-Komponente zu den realen UDP- oder TCP-Aufträgen in der ADAPT-Komponente - ist u.a. zu überprüfen, inwieweit die Längen und die Übergabezeitpunkte der realen Aufträge, die von dem Adapter generiert werden, den Längen und den Übergabezeitpunkten der spezifizierten abstrakten Aufträge im PBVA entsprechen. Zur Analyse der möglichen Abweichungen zwischen den spezifizierten (t SOLL ) und den tatsächlich erzielten (faktischen) Übergabezeitpunkten (t IST ) der Aufträge sind Messungen an der Schnittstelle erforderlich, die zur Lastgenerierung gewählt wurde. Solche Messungen können zum einen mithilfe von internen Instrumenten aus der EEM-Komponente des Lastgenerators (vgl. Kapitel 4) und zum anderen mithilfe von externen Tools, wie z.b. dem Netzanalysator Ethereal ([Ethereal]), durchgeführt werden. Der Einfluss von betriebssystembedingten Faktoren (resultierend aus dem Multitasking- Betrieb, vgl. Abschnitt 4.4) und die in dem gewählten Transportsystem geltenden Einschränkungen (wie z.b. die zur Übergabe eines UDP- oder TCP-Auftrags einer bestimmten Länge mindestens benötigte Zeit, die maximale Segmentgröße oder der Einfluss der Flusskontrolle bei TCP, etc.) können insbesondere bei den Übergabezeitpunkten der UDP- oder TCP-Aufträge zu Abweichungen führen. Eine umfassende und vollständige Validierung des realisierten Lastgenerators ist somit recht aufwändig. Aus diesem Grund wurde in der vorliegenden Arbeit zunächst eine partielle Validierung der Generierung von abstrakten Aufträgen in der GAR-Komponente in Verbindung mit dem UDP- und dem TCP-Adapter durchgeführt. Ziel der entsprechenden Experimente war es u.a., die Grenzen der Leistungsfähigkeit und der Präzision des realisierten Lastgenerators zu ermitteln. Wie in Kapitel 2 bereits erläutert wurde, erfolgt die Übergabe von Aufträgen im PBVA konzeptionell zeitlos. Bei der Generierung von realen UDP- und TCP-Aufträgen in dem Adapter gilt diese Annahme aufgrund von nicht zu vernachlässigbaren Verarbeitungszeiten in den Komponenten des zugrunde liegenden Protokollstapels nicht mehr. So wird jeder UDP- bzw. TCP-Auftrag durch einen Zeitpunkt t B für den Beginn der Übergabe und einen Zeitpunkt t E für das Ende der Übergabe dieses Auftrags an der UDPbzw. TCP-Schnittstelle gekennzeichnet (siehe Abbildung 6.2). Dabei entspricht t B dem Zeitpunkt eines entsprechenden Aufrufs von sendto() bzw. send() im UDP- bzw

81 Validierung des realisierten Lastgenerators TCP-Adapter und t E dem Zeitpunkt, zu dem die Kontrolle aus sendto() bzw. send() wieder an den UDP- bzw. TCP-Adapter zurückgegeben wird. Die zwischen t B und t E verstrichene Zeit τ(l) = (t E - t B ) wird für die Übergabe eines UDP- bzw. TCP-Auftrags der Länge L an den Socket-Puffer in der UDP- bzw. TCP-Senderinstanz benötigt und ist von der Länge L dieses Auftrags abhängig (vgl. Abb. 6.2). (Auftrags-) Beginn SENDTO() t B = t SOLL t IST τ(l) ~τ(l) Angestrebter Messzeitpunkt (t IST ) (Auftrags-) Ende t E t * Tatsächlicher Messzeitpunkt (t*) t t Abbildung 6.2: Übergabe eines Auftrags an einer UDP- oder TCP-Schnittstelle und Messungen der faktisch erzielten Übergabezeitpunkte der Aufträge. Bei der Generierung von UDP- und TCP-Aufträgen in dem UDP- und TCP-Adapter muss also festgelegt werden, ob die spezifizierten Übergabezeitpunkte t SOLL den Beginn t B oder das Ende t E der vollständigen Auftragsübergabe darstellen sollen. In der Realisierung des Lastgenerators in der vorliegenden Arbeit werden die in dem PBVA spezifizierten Übergabezeitpunkte t SOLL als Beginn der Auftragsübergabe t B interpretiert. Die entsprechenden sendto() bzw. send()-aufrufe in dem UDP- bzw. TCP-Adapter sollen also genau zu diesen Zeitpunkten t SOLL begonnen werden. Die tatsächlich erzielten (faktischen) Übergabezeitpunkte t IST werden als t IST = t* - τ(l) ermittelt, wobei t* die unmittelbar nach dem Aufruf von sendto() bzw. send() gemessenen Zeitpunkte und τ(l) die Zeit für die Übergabe eines Auftrags der Länge L an den Socket-Puffer der Senderinstanz darstellen (vgl. Abb. 6.2). Bei der experimentellen Ermittlung der Abweichungen zwischen den faktisch erzielten und den spezifizierten Übergabezeitpunkten der UDP- und der TCP-Aufträge in Form von Differenzen Τ = t IST - t SOLL stellt τ(l) somit eine sog. auftragslängenabhängige Messungenauigkeit des realisierten Lastgenerators dar. Als Hauptkriterien zur Bewertung der Leistungsfähigkeit bzw. der Präzision des realisierten Lastgenerators können die maximale erreichbare Datenrate der generierten Verkehrsströme bzw. der Mittelwert und die Varianz der Verteilung von Differenzen zwischen den faktischen und den spezifizierten Übergabezeitpunkten der realen Aufträge herangezogen werden. Diese Kriterien haben einen strengen Bezug zu der Schnittstelle IF, die von dem Experimentator zur Lastgenerierung gewählt wurde. Im Folgenden werden einige Experimentserien vorgestellt, die zur Ermittlung dieser Größen für den UDP- und den TCP-Adapter durchgeführt wurden. 6.1 Experimente mit dem UDP-Adapter Um die ersten Aussagen zur Leistungsfähigkeit und zur Präzision des neuen Lastgenerators zunächst in Verbindung mit dem realisierten UDP-Adapter zu treffen, wurden Ex

82 Kapitel 6 perimente zur Generierung von UDP-Verkehrsströmen mit konstanter (engl. constant bit rate, CBR) und variabler (engl. variable bit rate, VBR) Datenrate durchgeführt. Das verwendete elementare BVA-Model eines Benutzers des Transportdienstes an der UDP-Schnittstelle ist in der Abbildung 6.3 dargestellt. Die Zustände S i und S t sind jeweils der Initialisierungs- und der Terminierungszustand des entsprechenden BVAs. Im R-Zustand R sd werden Aufträge vom Auftragstyp SEND_DATA mit den drei dazugehörigen Auftragsattributen dest_addr (der Name bzw. die Adresse des Empfängers), dest_port (die Portnummer des Empfängers) und data_len (die Länge L der zu übermittelnden Dateneinheit) generiert. Im Zustand D t wird das Zeitintervall zwischen zwei aufeinanderfolgenden Aufträgen (die Zwischenankunftszeit ZAZ der Aufträge) modelliert. Die Zustandsübergänge in dem BVA-Modell erfolgen gemäß den Übergangswahrscheinlichkeiten an den Kanten des BVAs. Abbildung 6.3: BVA-Modell für einen Benutzer des Transportdienstes an der UDP-Schnittstelle. Die Werte der Auftragsattribute dest_addr und dest_port werden für die Experimente als Konstante, z.b und 7777 spezifiziert. Werden die Auftragslänge data_len in R sd und die ZAZ der Aufträge in D t ebenfalls als Konstante, z.b. 1472[Byte] bzw. 200[µs] spezifiziert, sowie die Lastgenerierungsdauer z.b. auf 30[sec] gesetzt, wird von UniLoG die entsprechende Last als CBR UDP-Verkehr mit einer konstanten Datenrate von 60.56[Mbit/s] für 30[sec] generiert und an das Netz übergeben. Zur Modellierung von VBR UDP-Verkehr können in dem skizzierten BVA- Modell entweder die Auftragslänge data_len (in den Experimenten später kurz als L bezeichnet) oder die ZAZ der Aufträge in D t oder beide Parameter variiert werden (die Auftragslänge in R sd kann z.b. gemäß Trace und die ZAZ der Aufträge in D t negativexponentiell verteilt mit einer entsprechenden (Auftragsankunfts-)Rate λ, z.b. λ=5000[aufträge/s] und E[ZAZ]=(1/λ)=200[µs], gewählt werden)

83 Validierung des realisierten Lastgenerators Die Experimente wurden in einem 100 MBit/s Fast Ethernet LAN mit einem Hub TP800 der Firma 3Com bei einer MTU-Größe von 1500 Byte durchgeführt. Der Lastgenerator wurde auf einem handelsüblichen PC mit Intel Pentium 4 CPU 2.39 GHz, 1,00 GB RAM, Intel PRO/100 VM Network Connection Adapter, Microsoft Windows XP Professional, Version 2002, Service Pack 2 ausgeführt. Als Lastsenke für den generierten UDP-Strom kam ein PC mit einer identischen Systemkonfiguration zum Einsatz. Ein dritter Windows-PC wurde für die Aufzeichnung und die Analyse des Verkehrs im LAN mit dem Netzwerk-Analysator Ethereal (Vers. 0.99) verwendet Experimente mit CBR-Verkehr Die Datenrate eines UDP-Stroms kann zum einen durch die Veränderung der Auftragslänge L und zum anderen durch die Veränderung der Zwischenankunftszeit (ZAZ) der Aufträge beeinflusst werden. Für die Untersuchungen mit CBR-Verkehr wurden in diesem Abschnitt drei Experimentserien durchgeführt, wobei in jeder Serie die Auftragslänge L konstant gehalten wurde. In den einzelnen Experimenten innerhalb der Experimentserie wurde eine andere konstante Zwischenankunftszeit ZAZ der Aufträge gewählt. In der ersten Experimentserie wurde die Auftragslänge absichtlich groß L 1 = 10000[Byte] gewählt und die ZAZ von 1[ms] bis zum rechnerischen Übergabezeitlimit der UDP-Aufträge (bei der Auftragslänge von 10000[Byte]) von Experiment zu Experiment systematisch verkleinert 6 (siehe Tabelle 6.1). ZAZ [µs] (860) (850) (845) (842) (840) (839) (835) # Aufträge Datenrate [MBit/s] TMEAN (µs) Var( T) T >= 1ms T [800, 1000) µs T [600, 800) µs T [400, 600) µs T [200, 400) µs T [100, 200) µs T [90, 100) µs T [80, 90) µs T [70, 80) µs T [60, 70) µs T [50, 60) µs T [40, 50) µs T [30, 40) µs T [20, 30) µs T [10, 20) µs T [5, 10) µs T < 5µs % ( T < 10 µs) Tabelle 6.1: Experimentserie 1, L 1 = 10000[Byte], ZAZ = [µs], τ(l 1 )~706[µs], Lastgenerierungsdauer 30[sek.]. Die Lastgenerierungsdauer wurde konstant bei 30[sek.] gehalten. In jedem Experiment wurde für jeden Auftrag die Abweichung T = t IST - t SOLL zwischen dem gemessenen faktischen Übergabezeitpunkt t IST und dem spezifizierten Übergabezeitpunkt t SOLL berechnet (vgl. Einführung zu Kapitel 6). Die Anzahl der generierten UDP-Aufträge (#Aufträge), die entsprechende Datenrate des übergebenen UDP-Auftragsstroms, die 6 Für die Übergabe von L 1 = 10000[Byte] Nutzdaten an der UDP-Schnittstelle im gegebenen 100 Mbit/s Fast Ethernet LAN werden gerade mindestens ca. 800[µs] benötigt: ((10000[Byte]{Nutzdaten} +8[Byte]{UDP-Header} + 20[Byte]{IP-Header}+14[Byte]{MAC-Header}) * 8[Bit/Byte] / 100[MBit/s] = [µs])

84 Kapitel 6 mittlere Differenz der faktischen und der spezifizierten Übergabezeitpunkte der Aufträge ( T MEAN ), ihre Varianz Var( T) sowie die empirische Häufigkeitsverteilung von T (die sog. "Ausreißer") sind in der Tabelle 6.1 für verschiedene Werte der ZAZ zusammengefasst. Es ist zu bemerken, dass bei ZAZ von 1[ms] bis ca. 870[µs] etwas mehr als 95% der Differenzen T kleiner als 10[µs] sind (vgl. die letzte Zeile in der Tab. 6.1). Unter der Annahme von normalverteilten Differenzwerten T können mithilfe des Stichprobenmittelwertes T MEAN, der Stichprobenvarianz Var( T) sowie der Stichprobengröße (#Aufträge) die entsprechenden 95%-Konfidenzintervalle (kurz 95%-KI) berechnet werden. Für die ZAZ von 870[µs] ergibt sich ein 95%-KI ZAZ=870[µs] = [7,9995; 8,0005]. Bei ZAZ von 860, 850 und 845[ms] liegen jeweils 94,12%, 92,31% und 88,47% der Werte von T unter 10[µs] (95%-KI ZAZ=860[µs] =[10,9994; 11,0006], 95%-KI ZAZ=850[µs] = [12,9993; 13,0007] und 95%-KI ZAZ=845[µs] =[23,999; 24,001]). Solche ZAZ, bei denen mehr als 95% der Differenzen T oberhalb von 10[µs] liegen, werden in der aktuellen Realisierung des UDP-Adapters als nicht mehr hinreichend valide unterstützte ZAZ angesehen. Die relativ hohe Anzahl und eine breite Streuung von Ausreißern dürfte in dem Fall L 1 = 10000[Byte] auf den Einfluss der Fragmentierung und der damit verbundenen Verarbeitungsprozesse in der IP-Schicht zurückzuführen sein. Aus diesen Gründen wurde die zweite Experimentserie mit der größten möglichen Auftragslänge durchgeführt, bei der noch keine Fragmentierung der Pakete in der IP- Schicht stattfindet. Bei der gegebenen MTU-Größe von 1500 Byte ergibt sich die entsprechende maximale Auftragslänge L 2 von 1472[Byte]: 1500[Byte]{MTU} - 20[Byte]{IP-Header} - 8[Byte]{UDP-Header}. Die ZAZ der Aufträge wurde von 500[µs] bis 120[µs] variiert 7. Die entsprechenden Experimentergebnisse sind in der Tabelle 6.2 zusammengefasst. ZAZ [µs] (125) (124) (123) #Aufträge Datenrate [MBit/s] TMEAN (µs) Var( T) T >= 1ms T [800, 1000) µs T [600, 800) µs T [400, 600) µs T [200, 400) µs T [100, 200) µs T [90, 100) µs T [80, 90) µs T [70, 80) µs T [60, 70) µs T [50, 60) µs T [40, 50) µs T [30, 40) µs T [20, 30) µs T [10, 20) µs T [5, 10) µs T < 5 µs % ( T < 10 µs) Tabelle 6.2: Experimentserie 2, L 2 = 1472[Byte], ZAZ = [µs], τ(l 2 )~54[µs], Lastgenerierungsdauer 30[sek.]. 7 Für die Übergabe von L 2 = 1472[Byte] Nutzdaten an der UDP-Schnittstelle im gegebenen 100 Mbit/s Fast Ethernet LAN werden mindestens 120[µs] benötigt: ((1472[Byte]{Nutzdaten} + 8[Byte]{UDP- Header} + 20[Byte]{IP-Header} + 14[Byte]{MAC-Header}) * 8[Bit/Byte] / 100[MBit/s] = [µs])

85 Validierung des realisierten Lastgenerators Obwohl im Vergleich zu der Experimentserie 1 mehr Aufträge erzeugt werden, liegen bei ZAZ im Bereich von 500 bis 140[µs] mehr als 98% der Werte von T unter 10[µs] (siehe Tabelle 6.2). Das 95%-KI bei ZAZ von 140[µs] ergibt sich zu 95%-KI ZAZ=140[µs] = [6,9999; 7,0001]. Bei ZAZ von 140[µs] bis 126[µs] liegen mehr als 95% der Werte von T unter 10[µs] (95%-KI ZAZ=126[µs] =[18,9997; 19,0003]). Bei ZAZ ab 125[µs] bricht das Verhalten von T stark ein: es liegen deutlich weniger als 95% der Differenzwerte unter 10[µs] (95%-KI ZAZ=125[µs] =[29,9996; 30,0004], 95%-KI ZAZ=124[µs] =[125,9992; 126,0008]). Die im Vergleich zur Experimentserie 1 relativ kleine Anzahl von Ausreißern lässt sich vermutlich durch die bei L 2 =1472[Byte] nicht mehr stattfindende Fragmentierung erklären. Zusätzlich ist noch zu bemerken, dass in der Experimentserie 2 die variierte ZAZ der UDP-Aufträge sehr nahe an dem rechnerischen Übergabezeitlimit der UDP-Aufträge (ca. 121[µs] bei L 2 =1472[Byte]) spezifiziert wurde und durch den UDP-Adapter auch realisiert werden konnte (ca. 140[µs] wenn 98% bzw. 126[µs] wenn 95% der Differenzwerte unter 10[µs] liegen sollen). In der dritten Experimentserie wurde die Auftragslänge noch weiter auf L 3 = 50[Byte] reduziert, um den Lastgenerator in Verbindung mit dem UDP-Adapter bei extrem kleinen konstanten Zwischenankunftszeiten der UDP-Aufträge zu testen (der rechnerische Übergabezeitlimit der UDP-Aufträge liegt bei einer Paketgröße von 50[Byte] bei ca. 7,36[µs] 8 ). Die Ergebnisse der dritten Experimentserie sind in der Tabelle 6.3 zusammengefasst. ZAZ [µs] (38) (37) (36) #Aufträge Datenrate[MBit/s] TMEAN (µs) Var( T) T >= 1ms T [800, 1000) µs T [600, 800) µs T [400, 600) µs T [200, 400) µs T [100, 200) µs T [90, 100) µs T [80, 90) µs T [70, 80) µs T [60, 70) µs T [50, 60) µs T [40, 50) µs T [30, 40) µs T [20, 30) µs T [10, 20) µs T [5, 10) µs T < 5 µs % ( T < 10 µs) Tabelle 6.3: Experimentserie 3, L 3 = 50[Byte], ZAZ = [µs], τ(l 3 )~14[µs], Lastgenerierungsdauer 30[sek.]. Bei ZAZ im Bereich von 400 bis 42[µs] liegen mehr als 98% der Werte von T unterhalb von 10[µs] (95%-KI ZAZ=42[µs] =[15,9996; 16,0004]), bei ZAZ im Bereich von 42 bis 39[µs] sind es nur 95% der Differenzwerte (95%-KI ZAZ=40[µs] =[20,9995; 21,0005]). Auffallend ist eine sehr starke Erhöhung der Differenzen T bei ZAZ kleiner als 39[µs] (z.b. 95%-KI ZAZ=36[µs] = [2479,99; 2480,01]). Dieser Umstand ist durch die extrem kleine Länge der ZAZ zu erklären. Wird der Übergabezeitpunkt eines Auftrags 8 Für die Übergabe von L 3 = 50[Byte] Nutzdaten an der UDP-Schnittstelle im 100 Mbit/s Fast Ethernet LAN werden mindestens 7.36[µs] benötigt: ((1472[Byte]{Nutzdaten} + 8[Byte]{UDP-Header} + 20[Byte]{IP-Header} + 14[Byte]{MAC-Header}) * 8[Bit/Byte] / 100[MBit/s] = 7.36[µs])

86 Kapitel 6 aufgrund der internen Prozesse im Betriebssystem oder im Lastgenerator verfehlt, so werden auch die Übergabezeitpunkte der nachfolgenden Aufträge mit einer hohen Wahrscheinlichkeit verfehlt. Da ab einer ZAZ von 38[µs] deutlich weniger als 95% der Differenzwerte unter 10[µs] liegen (vgl. Tabelle 6.3) und das rechnerische Übergabezeitlimit der UDP-Aufträge (ca. 7.36[µs]) nicht unterschritten ist, kann geschlossen werden, dass die restliche Zeit von ca. 30[µs] für die internen Vorgänge im Lastgenerator (z.b. für die Vorbereitung der Aufträge in der GAR- und in der ADAPT-Komponente bzw. für die Kontrollübergabe zwischen dem Generator und dem Adapter) verbraucht wird und somit den zusätzlichen Zeitaufwand für die Erstellung eines jeden UDP-Auftrags darstellt. Die Abhängigkeit der Größe T MEAN von der spezifizierten Zwischenankunftszeit ZAZ und der Länge L der Aufträge wurde in der Abb. 6.4 für die Experimentserien 1, 2 und 3 zusammenfassend dargestellt. Bei festem L beobachtet man einen rapiden Anstieg von T MEAN, je näher die ZAZ am rechnerischen Übergabezeitlimit der Aufträge an der UDP-Schnittstelle spezifiziert wird (803[µs] bei L 1 = [Byte], 121[µs] bei L 2 = 1472[Byte] bzw. 7,36[µs] bei L 3 =50[Byte]) T_mean (ZAZ, L) T_mean [µs] ZAZ [µs] L = [Byte] L = 1472 [Byte] L = 50 [Byte] Abbildung 6.4: Mittlere Differenz T MEAN der spezifizierten und der faktischen Übergabezeitpunkte der UDP-Aufträge bei L 1 = 10000, L 2 = 1472, L 3 = 50 [Byte]. Unter der Voraussetzung, dass mindestens 98% der Werte der Abweichungen zwischen den spezifizierten und den faktischen Übergabezeitpunkten der UDP-Aufträge unter 10[µs] liegen sollen, lassen sich mit der aktuellen Realisierung von UniLoG UDP-Verkehrsströme mit einer konstanten Datenrate bis zu 86[Mbit/s] auf der UDP-Schicht erzeugen (z.b. bei L 2 =1472[Byte] und ZAZ = 140[µs], vgl. Tabelle 6.2). Es lassen sich ggf. noch höhere Datenraten erzielen, soweit größere Abweichungen von den spezifizierten Übergabezeitpunkten der UDP-Aufträge toleriert werden (z.b [MBit/s] bei

87 Validierung des realisierten Lastgenerators L 1 =10000[Byte] und ZAZ=870[µs], 95% der Differenzwerte liegen in diesem Falle noch unter 10[µs], vgl. Tabelle 6.1). Die Systemauslastung auf der Ethernet-Ebene ist wegen der hinzugefügten UDP-, IPund MAC-Header noch etwas höher. Die in den Experimentserien induzierte Netzauslastung wurde durch die Analysen des protokollierten LAN-Verkehrs in Ethereal sowie durch die Leuchtanzeigen verschiedener Auslastungsniveaus auf dem eingesetzten Hub bestätigt. Bei der Auftragslänge L 2 = 1472[Byte] und der ZAZ von 140[µs] befand sich das Netz bereits im Überlastbereich (86% Systemauslastung) Experimente mit VBR-Verkehr Wie im vorangehenden Abschnitt bereits erläutert wurde, kann die Datenrate eines UDP-Stroms zum einen durch die Veränderung der Auftragslänge L und zum anderen durch die Veränderung der Zwischenankunftszeit (ZAZ) der Aufträge beeinflusst werden. Für die Untersuchungen mit VBR-Verkehr in diesem Abschnitt wurden zwei weitere Experimentserien 4 und 5 durchgeführt, wobei die Auftragslänge L in jeder Experimentserie konstant gehalten wurde. In den einzelnen Experimenten innerhalb einer Experimentserie wurden die Zwischenankunftszeiten der Aufträge gemäß einer Exponentialverteilung gewählt, wobei der Erwartungswert E[ZAZ] der ZAZ durch die Vorgabe einer entsprechenden (Auftragsankunfts-)Rate λ der Exponentialverteilung (siehe Kap. 2) gesteuert wurde. Im Unterschied zu den Experimenten mit CBR-Verkehr im Abschnitt sind die ZAZ der Aufträge nunmehr nicht konstant. So kann es vorkommen, dass der Übergabezeitpunkt des nächsten Auftrags kleiner gewählt wird als das Übergabezeitlimit eines UDP-Auftrags bei gegebener Auftragslänge, mit der Folge, dass dieser Übergabezeitpunkt in dem Adapter garantiert verfehlt wird. Bei größeren Auftragslängen L (und damit einem höheren Übergabezeitlimit) und kleineren (durch die Vorgabe einer entsprechenden Rate λ) spezifizierten ZAZ ist dieser Effekt verstärkt zu erwarten. Im Vergleich zu den Experimenten mit CBR-Verkehr ist also eine schnellere Erhöhung der Differenzwerte Τ während der systematischen Reduzierung der ZAZ bei konstanter Auftragslänge L zu erwarten. In der Experimentserie 4 wurde eine maximal mögliche Auftragslänge L 4 =1472[Byte] gewählt, bei der noch keine Fragmentierung der Pakete in der IP-Schicht stattfindet. In jedem Experiment wurde eine negativ-exponentiell verteilte ZAZ der Aufträge spezifiziert, dabei wurde der Erwartungswert der ZAZ durch die Vorgabe einer entsprechenden Rate λ der Exponentialverteilung systematisch von 1[ms] bis 120[µs] variiert. Die Experimentergebnisse (die Anzahl der generierten UDP-Aufträge, die entsprechende Datenrate der generierten UDP-Ströme, der Mittelwert Τ MEAN und die Varianz Var( Τ) der Differenzen zwischen den faktischen und den spezifizierten Übergabezeitpunkten der UDP-Aufträge sowie die entsprechende Häufigkeitsverteilung von Τ) sind in der Tabelle 6.4 zusammengefasst. Im Vergleich zu den Experimenten mit CBR-Verkehr ist der Mittelwert der Differenzen Τ bereits für relativ weit vom rechnerischen Übergabezeitlimit der UDP-Aufträge liegende ZAZ recht hoch (vgl. Tabellen 6.4 und 6.2). So liegen z.b. bei einer vorgegebener ZAZ mit E[ZAZ]=400[µs] bereits weniger als 95% der Differenzwerte Τ unterhalb von 10% der spezifizierten ZAZ, d.h. unter 40[µs] (vgl. letzte Zeile in der Tabelle 6.4,

88 Kapitel 6 95%-KI E[ZAZ]=400[µs] =[11,9992; 12,0008]). Dieser Umstand ist im Wesentlichen auf die Eigenschaften der gewählten negativ-exponentiell verteilten Zwischenankunftszeiten der Aufträge zurückzuführen. E[ZAZ] [µs] # Aufträge Datenrate [MBit/s] TMEAN [µs] Var( T) T >= 1ms T [800, 1000) µs T [600, 800) µs T [400, 600) µs T [200, 400) µs T [100, 200) µs T [90, 100) µs T [80, 90) µs T [70, 80) µs T [60, 70) µs T [50, 60) µs T [40, 50) µs T [30, 40) µs T [20, 30) µs T [10, 20) µs T [5, 10) µs T < 5µs % ( T < 10 µs) % ( T < 0.1*E[ZAZ]) Tabelle 6.4: Experimentserie 4, L 4 = 1472[Byte], E[ZAZ] = [µs], τ(l 4 )~54[µs], Lastgenerierungsdauer 30[sek.]. Die (Häufigkeits-)Verteilung der absoluten Werte der Abweichungen zwischen den erzielten und den spezifizierten Übergabezeitpunkten der Aufträge ist also im Vergleich zu den Experimenten mit CBR-Verkehr weniger aussagekräftig. Aus diesem Grund sind die in dem PBVA-Modell spezifizierten (Exponential-)Verteilungen der ZAZ den bei der Übergabe der UDP-Aufträge in dem Adapter tatsächlich erzielten empirischen (Häufigkeits-)Verteilungen der ZAZ in den Abbildungen gegenübergestellt. F(zaz) F(zaz) P[ZAZ<=zaz] 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=600[µs]) faktische ZAZ (nach der Übergabe im Adapter) P[ZAZ<=zaz] 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=400[µs]) faktische ZAZ (nach der Übergabe im Adapter) Abbildung 6.5: λ=1666,67[pakete/s], E[ZAZ]=600[µs] Abbildung 6.6: λ=2500[pakete/s], E[ZAZ]=400[µs]

89 Validierung des realisierten Lastgenerators F(zaz) F(zaz) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=300[µs]) faktische ZAZ (nach der Übergabe im Adapter) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=200[µs]) faktische ZAZ (nach der Übergabe im Adapter) Abbildung 6.7: λ=3333,33[pakete/s], E[ZAZ]=300[µs] Abbildung 6.8: λ=5000[pakete/s], E[ZAZ]=200[µs] F(zaz) F(zaz) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=180[µs]) faktische ZAZ (nach der Übergabe im Adapter) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=150[µs]) faktische ZAZ (nach der Übergabe im Adapter) Abbildung 6.9: λ=5555,56[pakete/s], E[ZAZ]=180[µs] Abbildung 6.10: λ=6666,67[pakete/s], E[ZAZ]=150[µs] An den Diagrammen in den Abbildungen kann beobachtet werden, dass die tatsächlich erzielte (empirische) Häufigkeitsverteilung der ZAZ umso mehr von der im PBVA-Modell spezifizierten Exponential-Verteilung der ZAZ abweicht, je kleiner der Erwartungswert der spezifizierten exponentiell-verteilten ZAZ gewählt wird. Dies entspricht der Erhöhung des Mittelwerts Τ MEAN der Differenzen zwischen den faktischen und den spezifizierten Übergabezeitpunkten der UDP-Aufträge bei Reduzierung der spezifizierten ZAZ in der Tabelle 6.4. Bei negativ-exponentiell verteilten ZAZ können generell auch solche Werte für die ZAZ der SEND_DATA-Aufträge im PBVA-Modell gewählt werden, die kleiner sind, als die für die Übergabe eines entsprechenden UDP-Auftrags an den Socket-Puffer in der UDP-Senderinstanz benötigt wird. Solche ZAZ können von der ADAPT-Komponente allerdings nicht realisiert werden; so weist die Kurve der tatsächlich erzielten empirischen Verteilung der ZAZ anfänglich einen horizontalen Verlauf auf (in diesen Fällen ist die Wahrscheinlichkeit P{ZAZ Übergabezeitlimit} gleich 0.0). In der nächsten Experimentserie 5 wurde die Auftragslänge mit L 5 =50[Byte] kleiner als in der Experimentserie 4 gewählt, das rechnerische Übergabezeitlimit der UDP-Aufträ

90 Kapitel 6 ge verringert sich entsprechend auf ca. 7,36[µs] (vgl. die Berechnungen zur Experimentserie 3). E[ZAZ] [µs] # Aufträge Datenrate [MBit/s] TMEAN [µs] Var( T) T >= 1ms T [800, 1000) µs T [600, 800) µs T [400, 600) µs T [200, 400) µs T [100, 200) µs T [90, 100) µs T [80, 90) µs T [70, 80) µs T [60, 70) µs T [50, 60) µs T [40, 50) µs T [30, 40) µs T [20, 30) µs T [10, 20) µs T [5, 10) µs T < 5µs % ( T < 10 µs) %( T < 0.1*E[ZAZ]) Tabelle 6.5: Experimentserie 5, L 5 = 50[Byte], E[ZAZ] = [µs], τ(l 5 )~14[µs], Lastgenerierungsdauer 30[sek.]. Im Vergleich zu der Experimentserie 4 mit L 4 =1472[Byte] liegen in der Experimentserie 5 mit L 5 =50[Byte] bei viel kleineren ZAZ von ca. 250[µs] mehr als 95% der Differenzen Τ zwischen den faktischen und den spezifizierten Übergabezeitpunkten der UDP-Aufträge unter 10% des Erwartungswertes E[ZAZ]. Bei einem vorgegebenen E[ZAZ] von 250[µs] liegen z.b. mehr als 95% der Differenzwerte Τ unter 25[µs] und 95%-KI E[ZAZ]=250[µs] =[10,9993; 11,0007]. Das 95%-KI bei E[ZAZ] von 40[µs] ergibt sich zu [99,9992; 100,0008] und ist damit etwas breiter als im Fall konstanter ZAZ. Die in dem PBVA-Modell spezifizierte Exponentialverteilung der ZAZ und die tatsächlich erzielte empirische Verteilung der ZAZ bei der Übergabe der UDP-Aufträge in dem UDP-Adapter sind für ausgewählte Erwartungswerte der ZAZ in den Abbildungen gegenübergestellt. F(zaz) F(zaz) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=200[µs]) faktische ZAZ (nach der Übergabe im Adapter) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=150[µs]) faktische ZAZ (nach der Übergabe im Adapter) Abbildung 6.11: λ=5000[pakete/s], E[ZAZ]=200[µs] Abbildung 6.12: λ=6666,67[pakete/s], E[ZAZ]=150[µs]

91 Validierung des realisierten Lastgenerators F(zaz) F(zaz) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=100[µs]) faktische ZAZ (nach der Übergabe im Adapter) P[ZAZ<=zaz] 1,2 1 0,8 0,6 0,4 0, ,0002 0,0004 0,0006 0,0008 0,001 zaz spezifizierte ZAZ (Exp-verteilt mit E[ZAZ]=50[µs]) faktische ZAZ (nach der Übergabe im Adapter) Abbildung 6.13: λ=10000[pakete/s], E[ZAZ]=100[µs] Abbildung 6.14: λ=20000[pakete/s], E[ZAZ]=50[µs] Im Vergleich zu den Experimenten der Experimentserie 4 mit gleichen ZAZ bei der Auftragslänge L 4 =1472[Byte] wird beobachtet, dass die vorgegebene Exponential-Verteilung der ZAZ durch die tatsächlich erzielte empirische (Häufigkeits-)Verteilung besser angenähert wird (vgl. z.b. die Abbildungen 6.8 und 6.11 bzw und 6.12). Dieser Umstand ist in erster Linie auf die kleinere Auftragslänge L 5 = 50[Byte] in der Experimentserie 5 zurückzuführen, die in einem entsprechend geringeren Übergabezeitlimit der UDP-Aufträge resultiert. So ist die Wahrscheinlichkeit, gemäß der vorgegebenen Exponentialverteilung eine ZAZ zu ziehen, die kleiner als das Übergabezeitlimit ist, in der Experimentserie 5 bei L 5 =50[Byte] kleiner, als in der Experimentserie 4 bei L 4 =1472[Byte] T_mean (ZAZ, L) T_mean [µs] ZAZ [µs] L = 1472 [Byte] L = 50 [Byte] Abbildung 6.15: Mittlere Differenz T MEAN der spezifizierten und der faktischen Übergabezeitpunkte der UDP-Aufträge bei L 4 = 1472 und L 5 = 50 [Byte], VBR-Verkehr

92 Kapitel 6 Der Verlauf der Mittelwerte Τ MEAN der Differenzen zwischen den faktischen und den spezifizierten Übergabezeitpunkten der UDP-Aufträge bei negativ-exponentiell verteilten ZAZ für die Auftragslängen L 4 und L 5 ist abschließend in der Abbildung 6.15 dargestellt. Analog zu den Experimenten mit CBR-Verkehr können die ZAZ der Aufträge bei kleineren Auftragslängen (L 5 =50[Byte]) näher an dem rechnerischen Übergabezeitlimit der UDP-Aufträge spezifiziert und in dem Adapter auch realisiert werden, als bei größeren Auftragslängen (L 4 =1472[Byte]). Bei der Datenlänge L 5 =50[Byte] fällt wieder der starke Einbruch von Τ MEAN ab einer spezifizierten (mittleren) ZAZ von 39[µs] auf. Dies stimmt mit den Beobachtungen bei identischer Auftragslänge L 3 =50[Byte] in den Experimenten der Experimentserie 3 mit CBR-Verkehr überein. 6.2 Experimente mit dem TCP-Adapter Im Vergleich zu UDP erlauben die Eigenschaften des TCP-Protokolls, wie z.b. die Verbindungs- und die Byte-Strom-Orientierung, die Zuverlässigkeit, die Flusskontrolle sowie die Möglichkeit einer Vollduplex-Übertragung, wesentlich umfangreichere Dienstleistungen für die Anwendungen. Es ist wohlbekannt, dass z.b. Pufferüberläufe in der Empfänger- oder in der Senderinstanz bzw. Überlasterscheinungen im Netzwerk zu Verlusten oder Verzögerungen von Datensegmenten führen können. In dem TCP-Protokoll wird diesen Umständen mit den entsprechenden Techniken zur Fluss- bzw. zur Staukontrolle (z.b. mit dem Congestion-Avoidance- und dem Slow-Start-Algorithmus) Rechnung getragen. Die verwendeten Timer und die speziellen Algorithmen versetzen die TCP-Partnerinstanzen in die Lage, auf Fehlerzustände und auf veränderte Bedingungen bei der Übertragung von Daten zu reagieren. In den Experimenten mit dem TCP- Adapter können allerdings solche internen Mechanismen im TCP-Protokoll generell zu Abweichungen zwischen den spezifizierten und den faktisch erzielten Übergabezeitpunkten der TCP-Aufträge führen. Die Experimente zur Analyse der Leistungsfähigkeit und der Präzision des Lastgenerators in Verbindung mit dem TCP-Adapter wurden daher zunächst in einem idealen Netz durchgeführt. So wurde sichergestellt, dass in der in Abschnitt 6.1 bereits beschriebenen und für die Experimente mit dem TCP-Adapter verwendeten Netzumgebung kein zusätzlicher konkurrierender Verkehr vorhanden war. Für die Aufzeichnung und die Analyse des Verkehrs im eingesetzten LAN wurde der Netzwerk-Analysator Ethereal (Vers. 0.99) verwendet. Das verwendete BVA-Modell eines Benutzers des Transportdienstes an der TCP- Schnittstelle ist in der Abbildung 6.16 dargestellt. Die Zustände S i und S t sind jeweils der Initialisierungs- und der Terminierungszustand des entsprechenden BVAs. Im R- Zustand R conn wird der Aufbau einer TCP-Verbindung mit Erzeugung eines Auftrags vom Auftragstyp CONNECT mit zwei dazugehörigen Auftragsattributen dest_addr (der Name bzw. die Adresse des Empfängers) und dest_port (die Portnummer des Empfängers) modelliert. Im S-Zustand S ack werden die netzbedingten Blockierungszustände des Benutzers modelliert. Konnte die TCP-Verbindung erfolgreich aufgebaut werden, erfolgt der Zustandsübergang von S ack in den R-Zustand R msg, sonst in den Terminierungszustand S t. Im R-Zustand R msg erfolgt die Modellierung der Datenübertragung durch die Erzeugung der Aufträge vom Auftragstyp SEND_MSG mit dem einzigen Auftragsattribut data_len (die Länge L der zu übermittelnden Daten). Im Zustand D t wird

93 Validierung des realisierten Lastgenerators das Zeitintervall zwischen zwei aufeinanderfolgenden SEND_MSG-Aufträgen modelliert. Konnte ein SEND_MSG-Auftrag nicht erfolgreich abgewickelt werden, erfolgt ein Zustandsübergang in den Terminierungszustand S t. Im R-Zustand R disc wird der Abbau der TCP-Verbindung durch die Erzeugung des Auftrags vom Auftragstyp DISCONNECT (ohne weitere Auftragsattribute) initiiert. Die Zustandsübergänge in dem BVA-Modell erfolgen gemäß den spezifizierten Übergangswahrscheinlichkeiten an den Kanten des BVAs. Abbildung 6.16: BVA-Modell für einen Benutzer des Transportdienstes an der TCP-Schnittstelle. Die Werte der Auftragsattribute dest_addr und dest_port werden für die Experimente als Konstante, z.b und 7777 spezifiziert. Werden die Auftragslänge data_len in R msg und die ZAZ der SEND_MSG-Aufträge in D t ebenfalls als Konstante, z.b. 1460[Byte] bzw. 500[µs] spezifiziert, und die Lastgenerierungsdauer z.b. auf 30[sec] gesetzt, wird von UniLoG die entsprechende TCP-Auftragssequenz mit einer konstanten Datenrate von 24.22[Mbit/s] für 30[sec] generiert und an der TCP-Schnittstelle übergeben. Zur Modellierung von VBR TCP-Verkehr können in dem skizzierten BVA-Modell entweder die Auftragslänge data_len (kurz L) oder die ZAZ der Aufträge in D t oder beide Parameter variiert werden (die Auftragslänge in R msg kann z.b. gemäß einer Normalverteilung und die ZAZ der Aufträge in D t negativ-exponentiell verteilt mit einer entsprechenden (Auftragsankunfts-)Rate λ, z.b. λ = 2000[Aufträge/s] und E[ZAZ] = (1/λ) = 500[µs], gewählt werden)