I2P Entwicklertreffen - 22. März 2005

13:01 <@jrandom> 0) hi 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) Batching (Stapelbildung) 13:01 <@jrandom> 3) Aktualisierung 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) hi 13:01 * jrandom winkt 13:01 <@jrandom> die gerade veröffentlichten wöchentlichen Statusnotizen sind online @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> hi 13:02 <+cervantes> 'lo 13:02 <@jrandom> springen wir gleich zu 1) 0.5.0.3 13:02 <@jrandom> das Release kam vor ein paar Tagen heraus, und die Rückmeldungen sind positiv 13:02 <+cervantes> jrandom: Sag Bescheid, wenn die blauen tanzenden Zwerge auf deinen Monitor klettern, dann beenden wir das Meeting frühzeitig 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (danke Bob für editierbare Sitzungslogs ;) 13:04 <@jrandom> Ich habe zu 0.5.0.3 nicht viel mehr hinzuzufügen als das, was in dieser Nachricht steht 13:04 <@jrandom> Hat jemand Anmerkungen/Fragen/Bedenken dazu? 13:04 <bla> jrandom: Gibt es neue Messungen zum Code für die Auswahl schneller Peers? 13:05 <@jrandom> ah, ich wusste, da war noch etwas in 0.5.0.3, das ich vernachlässigt hatte ;) 13:06 <@jrandom> Ich habe noch keine harten Kennzahlen, aber anekdotisch hat die schnelle Peer-Auswahl die Peers gefunden, von denen ich ausdrücklich weiß, dass sie ‚schnell‘ sind (z. B. router auf demselben Rechner, usw) 13:07 <bla> jrandom: Manchmal erfordern eepsites noch mehrere Versuche, um einen guten tunnel zu finden, den man verwenden kann 13:07 <@jrandom> Es gab auch Berichte über recht ordentliche Durchsatzraten gelegentlich (im Bereich 10–20KBps), aber das ist noch nicht häufig (wir haben die Parameter noch gedrosselt) 13:08 <+ant> <Connelly> oops, da ist ein Meeting 13:09 <@jrandom> hmm, ja, ich habe festgestellt, dass die Zuverlässigkeit noch nicht da ist, wo sie sein muss. Mehr als einmal neu zu versuchen ist aber wirklich keine Lösung – wenn eine Site nach 1 Retry nicht lädt, gib ihr 5–10 Min., bevor du es erneut versuchst 13:09 <@jrandom> Was ich jedoch im Netz sehe, sind nicht seltene Verzögerungsspitzen auf der Transportschicht 13:10 <@jrandom> z. B. 5–20+ Sekunden, nur um eine 1–2KB‑Nachricht durch einen Socket zu spülen 13:10 <@jrandom> Bindet man das mit einem 5‑Hop‑Pfad (2‑Hop‑tunnels) zusammen, kann es Probleme geben 13:11 <@jrandom> Das ist tatsächlich ein Teil dessen, was den Batching-Code antreibt – die Anzahl der zu sendenden Nachrichten zu reduzieren 13:13 <@jrandom> ok, hat sonst noch jemand Fragen/Anmerkungen/Bedenken zu 0.5.0.3? 13:13 <bla> jrandom: Sieht gut aus. Ich frage im nächsten „Abschnitt“ mehr dazu 13:14 <@jrandom> w3rd, ok, vielleicht können wir dann weitermachen – 2) Batching (Stapelbildung) 13:15 <@jrandom> Die E‑Mail und mein Blog (jrandom.dev.i2p</spam>) sollten die Grundlagen dessen beschreiben, was geplant ist 13:15 <@jrandom> und nun, eigentlich sind das ziemlich grundlegende Dinge 13:15 <@jrandom> Der aktuelle Präprozessor, den wir haben, war der einfachst mögliche, um ihn zu implementieren (Klassenname: TrivialPreprocessor) ;) 13:16 <@jrandom> Der neue hat einige einstellbare Parameter für die Batching-Frequenz sowie eine gewisse outbound tunnel affinity innerhalb einzelner tunnel pools (wobei wir versuchen, für nachfolgende Anfragen bis zu z. B. 500ms denselben outbound tunnel zu wählen, um das Batching zu optimieren) 13:17 <@jrandom> Das ist etwa alles, was ich dazu habe – Fragen/Anmerkungen/Bedenken? 13:18 <bla> Erfordert das, dass alle teilnehmenden Knoten den neuen Präprozessor ausführen, oder kann ein Mix aus Trivial/NewOne koexistieren? 13:18 <+Ragnarok> Das fügt .5 s Latenz hinzu, richtig? 13:19 <@jrandom> bla: Nee, dieser Präprozessor wird nur auf dem tunnel gateway verwendet, und es liegt an diesem gateway zu entscheiden, wie oder ob gebatcht wird 13:20 <@jrandom> Ragnarok: Meistens nicht – Nachricht 1 kann bis zu .5s verzögert werden, aber die Nachrichten 2–15 werden viel schneller übertragen als sonst. Es ist auch ein einfacher Schwellwert – sobald Daten in der Größe einer vollständigen tunnel message verfügbar sind, wird gespült 13:20 <+Ragnarok> cool 13:20 <+Ragnarok> Wie viel Overhead spart es? 13:21 <@jrandom> erheblich ;) 13:21 <+Ragnarok> „Erheblich“ ist gut, wenn auch vage :P 13:21 <@jrandom> schau auf deinem http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> und vergleiche das mit #tunnel.fullFragments 13:22 <bla> jrandom: Betrifft das nur die Kommunikation endpoint->IB-gateway? 13:22 <@jrandom> Mit Batching steigt das Verhältnis von full zu small, und die Anzahl der pad bytes in small geht herunter 13:23 <@jrandom> bla: hmm, es betrifft alle tunnel gateways, egal ob inbound oder outbound 13:24 <mihi> full fragments: durchschnittlicher Lebenszeitwert: 1,00 über 1.621,00 Ereignisse 13:24 <bla> jrandom: ok 13:24 <mihi> Kann es eine fraktionale Anzahl von Fragmenten geben? 13:24 <@jrandom> full: 1.00 über 807,077.00 Ereignisse small: 746.80 über 692,682.00 Ereignisse 13:25 <@jrandom> heh mihi 13:25 <@jrandom> (dieses small: 746 bedeutet, dass bei diesen 692k Nachrichten 746 von 996 Bytes verschwendete pad bytes waren!) 13:26 <@jrandom> Naja, nicht ganz verschwendet – sie haben ihren Zweck erfüllt 13:26 <+detonate> trotzdem unnötiger Overhead 13:27 <@jrandom> Jap, vieles davon sollten wir mit dem Batching-Präprozessor loswerden können 13:28 <@jrandom> Leider wird das im nächsten Release nicht enthalten sein 13:28 <@jrandom> aber es wird in der 0.5.0.6‑Rev enthalten sein (oder vielleicht 0.5.1) 13:28 <@jrandom> äh, 0.5.0.5, oder 0.5.1 13:28 * jrandom verwirrt sich bei #s 13:29 <bla> jrandom: Wie kommt's, dass nicht? 13:29 <+cervantes> Hasch und Pillen... verdammt 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: Es gibt einen Bug in 0.5.0.3 (und davor), bei dem der Fragmented-Message-Handler dazu führt, dass nachfolgende Fragmente innerhalb derselben tunnel message verworfen werden 13:31 <@jrandom> Wenn wir den Batching-Präprozessor direkt ausrollen würden, hätten wir eine beträchtliche Zahl verlorener Nachrichten 13:31 <@jrandom> Kein Grund zur Sorge, wir haben noch anderes schickes Zeug im Ärmel, daher wird die kommende 0.5.0.4 nicht völlig langweilig ;) 13:31 <bla> jrandom: Ah, so ist das 13:32 <bla> jrandom: Ah, deshalb müssen wir das erst machen, nachdem 0.5.0.4 Mainstream ist.. Verstehe. Thnx. 13:33 <@jrandom> Ja, es wäre schön, wenn der Fragment-Handler damit umgehen könnte, und das tut er im Allgemeinen auch, er gibt nur den Byte-Puffer zu früh frei und nullt dadurch nachfolgende Fragmente (ups) 13:33 <@jrandom> ok, noch etwas zu 2), oder sollen wir zu 3) Aktualisierung übergehen? 13:35 <@jrandom> Ok, wie in den Statusnotizen erwähnt (und schon eine Weile an verschiedenen Stellen diskutiert), werden wir Funktionen für einfaches und sicheres Aktualisieren hinzufügen, die nicht erfordern, dass der Endnutzer die Website besucht, die Mailingliste liest oder das Topic im Channel liest :) 13:36 <+detonate> cool 13:36 <@jrandom> smeghead hat Code zusammengestellt, um den Prozess zu automatisieren und abzusichern, und arbeitet mit cervantes zusammen, um sowohl fire2pe als auch die normale routerconsole anzubinden 13:37 <@jrandom> Die E‑Mail enthält die allgemeine Beschreibung dessen, was verfügbar sein wird, und obwohl das meiste davon funktioniert, gibt es noch ein paar Teile, die noch nicht vollständig ausgearbeitet sind 13:37 <@jrandom> Im Gegensatz zum Batching wird dies in der nächsten Rev /verfügbar/ sein, auch wenn die Leute es erst mit 0.5.0.5 wirklich nutzen können (wenn es Zeit zum Aktualisieren ist) 13:39 <+Ragnarok> also ... was ist dann das coole Zeug für 5.0.4? 13:42 <@jrandom> Mit dem Update-Code kommt die Fähigkeit, Ankündigungsdaten zu holen, z. B. ein Stück News oben auf der router console anzuzeigen. Zusätzlich haben wir als Teil des Update-Codes eine neue zuverlässige Download-Komponente, die entweder direkt oder über den eepproxy funktioniert und dabei neu versucht und fortsetzt. Vielleicht werden darauf einige relatd Features aufbauen, aber keine Versprechen 13:42 <+Ragnarok> nett 13:43 <@jrandom> ok, sonst noch Fragen/Anmerkungen/Bedenken zu 3) Aktualisierung? 13:45 <@jrandom> wenn nicht, weiter zu 4) ??? 13:45 <@jrandom> Gibt es sonst noch etwas, das jemand ansprechen möchte? Ich bin sicher, ich habe einiges verpasst 13:45 <+detonate> i2p ist dafür bekannt, mit der Sun JVM in OpenBSD 3.7 zu funktionieren :) 13:45 <@jrandom> schön! 13:47 <bla> Wie ist der Status beim UDP-Transport? 13:48 <+detonate> udp wird unordentlich werden, ich denke, es wäre besser, den Pipelining-Code von bt zu klauen und anzupassen ;) 13:48 <@jrandom> *hust* 13:49 <@jrandom> Ich erwarte nicht allzu viele Probleme, aber es gibt sicher Arbeit zu tun 13:49 <@jrandom> Wie die Queueing-Policy arbeitet sowie das bw‑Throttling für die Aufnahme in die Queue wird interessant sein 13:50 <bla> Wer hat diese Vorarbeiten gemacht? 13:50 <@jrandom> bla: detonate und mule 13:50 <+detonate> ja.. ich habe allerdings im letzten Monat oder so geschludert 13:50 <bla> detonate: Ich nehme an, du scherzt, mit deiner BT-Bemerkung? 13:51 <+detonate> Ich bin halb ernst 13:51 <+detonate> Damit könntest du zumindest die Thread-Zahl für den Transport halbieren 13:51 * jrandom schleudert einen Eimer Schlamm auf detonate 13:51 <jdot> woohoo. Mein router läuft jetzt auf meinem Dedicated-Server statt auf meiner miesen Kabelverbindung. 13:51 <@jrandom> nice1 jdot 13:52 <@jrandom> wir werden mit 3–5 Threads in der Transportschicht für alle Kommunikation mit allen Peers auskommen 13:52 <bla> detonate: Aber die Hälfte wird nicht reichen, wenn das Netz groß wird (> ein paar hundert Knoten) 13:52 <jdot> mit 1000GB Bandbreite zu seiner Verfügung 13:53 <jdot> leider werden j.i2p und die chat.i2p noch ein paar Stunden down sein, während ich Dinge migriere 13:53 <duck> detonate: addressbook auch auf Halt? 13:53 <+detonate> ja, ist auch auf Halt 13:54 <+detonate> das Einzige, was nicht auf Halt ist, ist der monolithische Profile Storage, den wollte ich später heute zum Laufen bringen 13:54 <@jrandom> w3rd 13:54 <+detonate> dann wird i2p die Platte nicht massiv fragmentieren 13:54 <jdot> jrandom: Was die BW‑Limits angeht, sind das Durchschnitte? 13:54 <+frosk> moderne Dateisysteme fragmentieren nicht, Dummerchen 13:55 <+detonate> ntfs schon 13:55 <@jrandom> jdot: Die Bandbreitenlimits sind strikte Token-Buckets 13:55 <@jrandom> jdot: Wenn du die Burst-Dauer einstellst, ist das der Zeitraum, über den es mittelt 13:56 <@jrandom> (nun, 2x Burst == Periode) 13:56 <@jrandom> ((so ungefähr)) 13:56 <jdot> hmmm... nun, ich habe 1000GB und möchte, dass i2p bis zu 800GB/Monat verbrauchen kann.... 13:56 <+ant> <mihi> detonate: ntfs speichert sehr kleine Dateien in mft, was nahezu keine Fragmentierung bedeutet 13:57 <jdot> und es ist mir egal, wie hoch es im Burst geht 13:57 <+detonate> nun, wenn du den Defragmentierer laufen lässt, verbringt er 10 Minuten damit, alle 6000 Profile zu verschieben.. also müssen sie fragmentieren 13:58 <@jrandom> jdot: hmm, nun, 800GB ist vermutlich mehr, als es ohnehin schieben will, also kannst du wahrscheinlich ohne Limits auskommen ;) 13:58 <@jrandom> andererseits, wenn du eine Policy beschreiben könntest, die du implementiert haben möchtest, könnten wir das vielleicht abbilden 13:58 <jdot> jrandom: Ich mache das erst mal so und schaue, wie es läuft 13:58 <bla> detonate: NTFS ist, IIRC, ein Journalling-FS. Also wird sogar eine monolithische Datei fragmentieren, wenn du in kleinen Portionen hineinschreibst 13:58 <+detonate> alles wird auf einmal geschrieben 13:59 <+detonate> und auf einmal gelesen 13:59 <bla> detonate: Ok. Verstehe. 13:59 <jdot> jrandom: Nun, warten wir ab, ob es überhaupt ein Problem sein wird. 13:59 <bla> detonate: Gute Arbeit in dem Fall! 13:59 <+detonate> Mich würde interessieren, wie viel Nutzung es wirklich gibt, wenn du es ungedrosselt lässt 14:00 <+detonate> auf einer guten Verbindung 14:00 <jdot> Ich bin auch interessiert! 14:00 <@jrandom> Meine Colo-routers laufen ungedrosselt, allerdings CPU-begrenzt 14:00 <+Ragnarok> Kannst du einen Bitbucket verwenden, um über einen Monat zu mitteln? 14:00 <jdot> jrandom: CPU-begrenzt? Was für eine CPU? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> hmm, hatte weniger erwartet 14:01 <@jrandom> jdot: CPU-begrenzt, weil ich 3 routers darauf laufen lasse, plus ein paar andere JVMs, manchmal mit Profiling 14:01 <+detonate> müssen diese bt-Leute sein 14:01 <+detonate> Sobald das Batching-Zeug online ist, wäre es interessant zu sehen, wie sich das ändert 14:02 <@jrandom> detonate: Ein Teil dieses Transfers ist auch, dass ich 50MB‑Dateien zwischen sich selbst schiebe ;) 14:02 <+detonate> heh 14:02 <jdot> ahh. ok. Nun, wir werden sehen, wie dieses System sich schlägt. Es ist ein AMD XP 2400 mit 512MB und einer 10Mbit‑Verbindung 14:02 <@jrandom> Ragnarok: Token-Buckets funktionieren so nicht wirklich 14:02 <@jrandom> jdot: word, ja, das ist ein P4 1.6 iirc 14:03 <@jrandom> Ragnarok: In einem Token-Bucket fügst du jede (z. B.) Sekunde gemäß der Rate Tokens hinzu. Wenn der Bucket voll ist (Größe = Burst-Periode), werden die Tokens verworfen 14:04 <@jrandom> Wann immer du Daten übertragen willst, musst du eine ausreichende Anzahl von Tokens bekommen 14:04 <@jrandom> (1 Token = 1 Byte) 14:04 <+Ragnarok> Ich weiß, wie sie funktionieren... was passiert, wenn du den Bucket einfach sehr groß machst? 14:05 <+detonate> dann hörst du nie auf, Daten zu senden 14:05 <+detonate> wenn er unendlich groß ist 14:05 <+detonate> äh, und er ist mit Tokens gefüllt 14:05 <@jrandom> Wenn er wirklich groß ist, kann er nach geringer Nutzung nach außen gehen und auf unbegrenzte Raten boosten 14:06 <@jrandom> obwohl das in manchen Fällen vielleicht erwünscht ist 14:07 <@jrandom> Das Ding ist: Du kannst den Token-Bucket nicht einfach auf 800GB setzen, da das die insgesamt übertragene Menge nicht begrenzen würde 14:08 <+detonate> Du brauchst dort ein Feld, in dem du die Anzahl der Tokens pro Sekunde setzen kannst, dann kannst du einfach die Bandbreitennutzung pro Monat durch die Anzahl der Sekunden teilen 14:08 <+detonate> :) 14:10 <@jrandom> Das ist dasselbe wie einfach die Rate über den Monat gemittelt zu setzen, was unausgewogen wäre. Aber wie auch immer, es gibt viele mögliche Szenarien – wenn jemand welche hat, die seine Bedürfnisse adressieren und die mit dem Vorhandenen nicht erfüllt werden können, bitte meldet euch 14:10 <+Ragnarok> aber wenn du die Rate auf den gewünschten Durchschnitt setzt... ich denke hier 308 kB/s, und dann den bitbucket auf etwas sehr Großes setzt... warum funktioniert das nicht? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> Nun, du könntest es so einstellen, dass es in einer 60‑Sekunden‑Burst‑Periode nie mehr als 800GB/44000 sendet 14:12 <+detonate> 44000 ist ungefähr die Anzahl der Minuten in einem Monat 14:13 <@jrandom> Die Bucket‑Größe/Burst‑Dauer beschreibt, wie viel wir ohne Begrenzung senden, und die meisten Leute /wollen/ Begrenzungen, damit der router nicht 10mbps für 5 Minuten verschlingt, während der Bucket entleert wird (oder so) 14:14 <@jrandom> Eine zusätzliche Drosselung der Tokens, die aus dem Bucket kommen, ist ebenfalls möglich (und sollte diese Drossel ihre eigene Token‑Bucket haben, und dieser Bucket seine eigene Drossel, usw) 14:16 <+Ragnarok> Ich dachte, der Bucket wird nur aufgefüllt, wenn Bandbreite nicht genutzt wird 14:16 <@jrandom> Tokens werden dem Bucket mit einer konstanten Rate hinzugefügt (z. B. 64k Tokens pro Sekunde) 14:17 <@jrandom> Alles, was Bandbreite will, fragt immer den Bucket 14:18 <+Ragnarok> ah.. ok 14:19 <@jrandom> Ok, cool, hat sonst noch jemand etwas, das er für das Meeting ansprechen möchte? 14:21 <@jrandom> ok wenn nicht 14:21 * jrandom holt aus 14:21 * jrandom *baf*s das Meeting