University of Würzburg Informatik III (Distributed Systems) Prof. Dr. P. Tran-Gia www3.informatik.uni-wuerzburg.de Towards Efficient Simulation of Large.

Präsentation zum Thema: "University of Würzburg Informatik III (Distributed Systems) Prof. Dr. P. Tran-Gia www3.informatik.uni-wuerzburg.de Towards Efficient Simulation of Large."—  Präsentation transkript:

1 University of Würzburg Informatik III (Distributed Systems) Prof. Dr. P. Tran-Gia www3.informatik.uni-wuerzburg.de Towards Efficient Simulation of Large Scale P2P Networks Compact Data Structures Andreas Binzenhöfer ITG-Fachgruppe 5.2.1 “Cooperating and Scalable Networks” Aachen, Ericsson, J. Sachs, 04.05.2006

2 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 2 Hintergrund P2P Mechanismen „verteiltes Telefonbuch“ 10  100  1000  10000  … Extrem große Zahl an Benutzern zu simulieren Wie groß ist groß genug? Probleme bei Laufzeit und Speicher Lösungsansätze: - Geeignet abstrahieren - Effiziente Event Queue - Event Design Algorithmen

3 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 3 Inhalt  Einführung und Problemstellung  Queue Efficiency  Calendar Queue im P2P Umfeld  Event Efficiency  Kademlia Bucket Refreshes  State Efficiency  Process Handlers  Zusammenfassung

4 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 4 Verschiedene Möglichkeiten zur Optimierung Viel Speicher ↔ Viele Teilnehmer ↔ Viele Events

5 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 5 Queue Efficiency Optimieren der Zeit in der Queue

6 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 6 Problemstellung Hold Time = Enque + Deque Operation

7 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 7 Calendar Queue Day 1Day 2Day 3Day N d *  Gleiche Funktionsweise wie ein normaler Kalender  Ein Jahr besteht aus N d (=365) Tagen  Ein Tag besteht aus T d (=24) Zeiteinheiten  Einfügen in O(1) durch Berechnen des Index (modulo N d )  Herausnehmen durch Weiterhangeln von Tag zu Tag

8 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 8 Calendar Queue: Probleme Zu viele Tage: Dequeue Operation nicht mehr in O(1) Zu lange Tage:Enqueue Operation nicht mehr in O(1)

9 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 9 Calendar Queue in der Praxis  Ansätze zum dynamischen Anpassen der Parameter N d und T d  Bei P2P Simulationen in der Regel nicht nötig  Optimale Werte:  T d, so dass wenige Events pro Tag  N d, so dass Großteil der Events in einem Jahr Day 1Day 2Day 3Day N d *

10 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 10 4096 Tage mit jeweils 100ms Aktueller Tag

11 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 11 32768 Tage mit jeweils 1ms Aktueller Tag

12 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 12 Zwischenfazit  Hold Time in der Event Queue beeinflußt Skalierbarkeit  Calendar Queue  Leicht implementierbar  Muß für P2P nicht dynamisch angepaßt werden  Ähnliche Datenstrukturen existieren z.B. in C#  Praktische Erfahrungen decken sich nicht immer mit Theorie (ns2)

13 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 13 Event Efficiency Reduktion der Anzahl an Events

14 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 14 0111 Kademlia: Strukturiertes P2P Overlay 1010 0100 1010 0 0111 1 0 1 0 1 0100 0001 0011 0001 0011 1111 Eigener Hash: 0000 Ein Eintrag pro Bucket Nachbarschaft Entfernte Peers im Overlay Bucket mit Nachbarn Nicht mehr splitten

15 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 15 Kademlia Bucket Refreshes  Etwa log 2 (n) buckets pro peer  Refresh eines buckets, falls dieser mindestens eine Stunde lang nicht benutzt wurde  Beispiel: 4380 39605820 peer X bucket 1 bucket 2bucket 3 Time of next refresh

16 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 16 Kademlia Bucket Refreshes Refresh event moved every time peer uses bucket bucket i Naive Lösung ohne zusätzlichen Speicher: Obsolete refresh events are being skipped bucket i Naive Lösung mit zusätzlichem Speicher: Jeder bucket speichert den tatsächlichen Zeitpunkt des nächsten Refresh Zu zeitintensiv Zu viele unnötige Events

17 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 17 Kademlia Bucket Refreshes bucket i Optimierte Lösung (Laufzeit): Jeder bucket speichert den tatsächlichen Zeitpunkt des nächsten Refresh Optimierte Lösung (Speicher): bucket 1 bucket 2 bucket 3 current minimum log2(n)·n refresh events 1.7 Millionen für 100000 Nur noch n refresh events Bsp: Reduktion um Faktor 17

18 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 18 State Efficiency Kompakte Datenstrukturen

19 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 19 Process Handler  Vermeiden von redundanter Information paralleler Prozesse  Bsp. parallele Suche:  Jedes teilnehmende Peer speichert ähnliche Informationen  Gleiche Information liegt mehrmals im Speicher Day 1Day 2Day 3Day N d process handler R a = 3 xyz = 48

20 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 20 Process Handler  R a zählt die Anzahl der Pointer auf den Process Handler (Remaining access)  Prinzip: „Der letzte macht die Türe zu“  Vorteil: Einsparung redundanter Information Day 1Day 2Day 3Day N d R a = 3 xyz = 48 process handler

21 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 21 Beispiel Search Handler  Search Handler speichert  Initiator der Suche  Gesuchte ID  Zeitpunkt des Timeouts  Anzahl (positiver) Antworten  … process handler R a =3 sender=48 query=667 timeout=4567 answers=2

22 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 22 Welchen Einfluss hat die Overlay Größe? 010002000300040005000600070008000900010000 0 5 10 15 20 25 0.95-quantile 0.99-quantile 0.9999-quantile Chord size n search delay bound / E[T N ] E[T N ] = 50 ms c T N = 1

23 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 23 Welchen Einfluss hat die Overlay Größe? Aussage: Dokumentverlust hängt nicht von der Ringröße, sondern von der Bewegung im Overlay ab

24 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 24 Wie groß ist groß genug?  P2P Algorithmen entworfen um mit der Größe zu skalieren  Churn hat stärkeren Einfluss auf Leistungsparameter  Overlay muss allerdings groß genug sein  Vollvermaschung  Zipf Verteilung vieler Parameter  Komplettaustausch des Overlays  Für strukturierte P2P Netze ca. 40000 ausreichend

25 University of Würzburg Distributed Systems Andreas Binzenhöfer Compact Data Structures 25 Q&A

26 University of Würzburg Dept. of Distributed Systems Prof. Dr. P. Tran-Gia Towards Efficient Simulation of Large Scale P2P Networks Compact Data Structures ITG 5.2.1 Fachgruppentreffen Andreas Binzenhöfer, University of Würzburg binzenhoefer@informatik.uni-wuerzburg.de 4.-5. Mai 2006 in Aachen