I2P Entwicklertreffen - 4. April 2006

16:21 <jrandom> 0) hi 16:21 <jrandom> 1) Netzstatus und 0.6.1.14 16:21 <jrandom> 2) Syndie-Planung 16:21 <jrandom> 3) Lokale jbigi-Optimierungen 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) hi 16:21 * jrandom winkt 16:21 <jrandom> Wöchentliche Statusnotizen unter http://dev.i2p.net/pipermail/i2p/2006-April/001275.html veröffentlicht 16:21 * Complication liest 16:22 <jrandom> während ihr alle diesen (kurz zusammengeworfenen) Post lest, springen wir gleich zu 1) Netzstatus 16:23 <@cervantes> (Forum wieder da) 16:23 <jrandom> es gibt ein paar Probleme, die die Nutzung auf 0.6.1.13 beeinträchtigen, und die meisten davon wurden aufgespürt und gelöst 16:24 <Complication> Hier, mit dem "vierten" CVS-Build, habe ich eine Änderung in meinen Grafiken bemerkt 16:24 <jrandom> es gibt noch ein paar Macken, die getestet und überarbeitet werden, aber ein Release sollte in den nächsten Tagen raus sein 16:24 <Complication> Insgesamt ging es in Richtung mehr Stabilität und weniger Sprunghaftigkeit 16:24 <jrandom> oh Mist, ich habe vergessen, auf -4 zu erhöhen, oder? 16:24 <jrandom> (ok, -5 kommt später heute Abend raus) 16:24 <jrandom> cool, Complication 16:25 <Complication> Aber meine Wahrnehmung könnte auch von jbigi beeinflusst sein, da ich nichts unternommen habe, um das auszuschließen 16:25 <Complication> Jetzt, nach einer Weile, ist die Wiederübertragungsrate ebenfalls auf 15% gesunken 16:28 <jrandom> hmm, ich sehe auch, wie mein durchschnittliches SSU-RTO sich der 3s-Obergrenze nähert 16:28 <jrandom> (allerdings weiterhin sehr niedrige Wiederübertragungsrate, unter 5%) 16:29 * Complication wirft einen zweiten Blick darauf 16:29 <Complication> Sagen wir, der Rohdurchschnitt liegt etwas über 1500 16:29 <Complication> (hier) 16:30 <+fox> <BrianR___> jrandom: Gibt es eine De-facto-"MTU" für i2p-Pakete? 16:30 <jrandom> ah ok, vielleicht sinkt die Wiederübertragungsrate, wenn das langsam nach oben geht 16:30 <Complication> Bei mir begann es mit kleineren MTUs, jetzt wurde auf 1350 erhöht 16:30 <jrandom> BrianR___: ja, entweder 1350 oder 608 (wie auf `http://localhost:7657/peers.js` angezeigt) 16:31 <jrandom> wenn die Fehlerrate bei der größeren MTU zu hoch ist, fällt es auf die kleinere MTU zurück (und wenn sie bei der kleineren MTU zu niedrig ist, springt es auf die höhere MTU) 16:31 <+fox> <BrianR___> jrandom: Gilt das für die innere Nutzlast oder die sichtbaren IP-Pakete? 16:31 <+fox> <BrianR___> D. h., wenn ich einen Datenblock über einen I2P-Stream sende, welche Größe der Chunks wäre ideal, um den Overhead zu minimieren? 16:31 <jrandom> das gilt für die UDP-Nutzlast 16:32 <jrandom> Streams sind zwei Schichten darüber 16:32 <jrandom> (es gibt Fragmentierung für tunnels und dann nochmal Fragmentierung auf der Stream/I2CP-Ebene) 16:32 <+fox> <BrianR___> Ja... Gibt es eine ideale Größe, um Fragmentierung zu minimieren? 16:32 <jrandom> die ideale Blockgröße einer App, die die Streaming-Lib verwendet, ist "groß", damit die Streaming-Lib die passende Größe wählen kann. 16:33 <jrandom> (aka den Mann hinter dem Vorhang ignorieren) 16:33 <+fox> <BrianR___> Aah.. Vielleicht sollte ich über Pipelining oder so nachdenken.. 16:34 <+fox> <BrianR___> Ich plane eine App mit viel Request/Response-Verkehr... 16:34 <jrandom> ich würde dann Batching empfehlen, um die Geschwätzigkeit zu reduzieren 16:34 <Complication> Vielleicht hilft es teilweise, den Verkehr zu bündeln 16:37 <jrandom> ok, noch etwas zu 1) Netzstatus, oder sollen wir rüberwackeln zu 2) Syndie-Planung 16:38 * jrandom wackelt rüber 16:39 <jrandom> das ist weitgehend ein Platzhalter und eine cfp - es wird eine erhebliche Überarbeitung von Syndie geben, sowohl im Betrieb als auch in der UI, also wenn ihr Schlüssel-Features oder Use-Cases habt, die aus eurer Sicht adressiert werden müssen, meldet euch 16:40 <jrandom> (mehr Infos folgen natürlich, sobald die Dinge weiter ausgearbeitet sind) 16:42 <jrandom> das ist alles, was ich dazu im Moment zu sagen habe, also weiter zu 3) jbigi-Optimierungen 16:42 <@frosk> und ich hatte angenommen, "plotting" bezöge sich auf irgendeinen jrobin-Kram in Syndie :) 16:43 <jrandom> hehe 16:43 <jrandom> es wäre interessant, Posts/Tag, Posts/Autor, neue Autoren/Tag usw. zu plotten ;) 16:44 <Complication> Oh, noch ein Punkt zu Syndie (sorry, erst jetzt wieder eingefallen) 16:44 <Complication> =ein Bit 16:44 <@frosk> welches willst du, 0 oder 1? :) 16:44 <Complication> Hältst du es für praktisch bzw. einfach/schwierig, Lieblingsautoren und geblacklistete (Spam-)Autoren in zwei verschiedene Listen zu trennen? 16:45 <Complication> Auf addresses.jsp 16:45 <jrandom> oh, ja, ohne große Mühe 16:46 <jrandom> das ist auch eine gute Idee für die Überarbeitung, aber vielleicht bekommen wir das in den 0.6.1.14-Build 16:47 <Complication> Nee, es beißt mich nicht, ich habe mich nur an etwas erinnert, das mir damals aufgefallen ist 16:47 <Complication> Jedenfalls wird jbigi unter Linux/AMD64 schneller, wenn man lokal kompiliert und GMP 4.2 verwendet 16:48 <jrandom> cool 16:48 <jrandom> hast du das mit -O3 -m64 auf GMP 4.1.2 verglichen? 16:48 <Complication> Und ich bin ein verdammter Idiot, weil ich völlig falschen Compile-Flags nachgejagt bin :O 16:48 <@cervantes> der relevante Link war `http://forum.i2p/viewtopic.php?t=1523&start=30` btw 16:48 <jrandom> ah danke, cervantes 16:48 <Complication> jrandom: Ich habe noch nicht verglichen, werde es aber tun 16:49 <Complication> Beim nächsten geplanten Reboot 16:50 <jrandom> der jbigi-Build-Prozess ist im Wesentlichen "build GMP, then build jbigi.o, and link the two together", daher können alle Optimierungen, die man an GMP vornehmen möchte, als erster Schritt gemacht werden 16:50 <@cervantes> Ich habe in früheren Tests, die ich gemacht habe, keinen großen Unterschied zwischen -O3 und -O2 gesehen; ob das unter x86_64 anders ist ... *shrug* 16:50 <jrandom> aye, könnte auch vom Compiler-Release abhängen 16:50 <jrandom> (insbesondere mit all den 3.3/3.4/4.0/4.1-Problemen) 16:51 <@cervantes> nur um zu wiederholen, was ich in dem Thread erwähnt habe... wir werden wahrscheinlich so bald kein windows64-optimiertes jbigi sehen 16:51 <+fox> <BrianR___> Komprimiert die i2p Stream-Lib die Nutzlast? 16:52 <Complication> BrianR: ja 16:52 <@cervantes> es sei denn, jemand hat M$ VC 2005 mit 64-Bit-SDK und hat Lust auf schwere Plackerei, um gmp damit zu kompilieren 16:52 <Complication> Zumindest soweit ich weiß 16:53 <@cervantes> (es gab irgendwo allerdings ein Projekt, gmp in ein VC-Projekt zu portieren) 16:53 <jrandom> cervantes: nun, wir haben eines, das /works/ für amd64/win, aber es holt nicht das Maximum aus der Hardware ;) 16:53 <jrandom> (wenn meine neue Kiste ankommt, kann ich das vielleicht tunen, da es ein amd64 ist) 16:53 <+fox> <BrianR___> versuche herauszufinden, ob ich ein Binärprotokoll verwenden sollte, um Bits zu sparen, oder ob zlib oder so ein ASCII-Protokoll schön klein quetscht.. 16:54 <@cervantes> coolio - leider scheinen Mingw64 oder cygwin64 nicht in naher Zukunft zu kommen... 16:54 <jrandom> BrianR___: vorzeitige Optimierung ist die Wurzel allen Übels und so weiter... 16:55 <Complication> zumindest teilweise menschenlesbare Protokolle sind im Allgemeinen leichter zu debuggen, aber ich denke, das hängt davon ab, was man tut 16:56 <Complication> (denn einige Dinge wie Verschlüsselung mögen es nicht, menschenlesbar zu sein, ganz egal :) ) 16:57 <Complication> Aber wenn I2P die Verschlüsselung übernimmt und auch komprimiert, stehen die Chancen gut, dass vieles, was darauf aufsetzt, mit menschenlesbaren Protokollen umgesetzt werden kann 16:58 <jrandom> aye 16:58 <jrandom> ok, noch etwas zu 3) jbigi-Kram? 16:58 <jrandom> wenn nicht, gehen wir weiter zu 4) ??? 16:59 <jrandom> hat noch jemand etwas für das Meeting? 17:01 <+tethra> ich erinnere mich, kürzlich etwas über anonyme Kollaborationstools gehört zu haben 17:01 <+tethra> magst du ausführen, welcher Art, und ob sie Syndie-esk sein werden oder nicht? 17:02 <@cervantes> IRC und Syndie sind anonyme Kollaborationstools :) 17:02 <jrandom> hmm, nicht sicher, worauf du dich beziehst - oder meinst du vielleicht die tatsächlich geplanten Syndie-Überarbeitungen? :) 17:02 <+tethra> stimmt. 17:02 * tethra ist sich auch nicht sicher, deshalb hat er gefragt 17:02 <+tethra> darüber wurde in den Foren gesprochen - Gründe für Anonymität und so 17:03 <+tethra> ich suche den Thread, damit ich das Zitat holen kann 17:03 <jrandom> ah, richtig 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> der Use-Case-Thread 17:03 <+tethra> - anonym gehostete & öffentlich erreichbare Foren/Boards/Wikis 17:03 <+tethra> ja 17:04 <+tethra> wird es ein i2wiki-ähnliches Projekt geben, das auf etwas wie Syndie basiert, oder liegt das bei den Nutzern? 17:04 <jrandom> da gab es ein paar gute Ideen und gutes Feedback 17:05 <jrandom> Die Möglichkeit, Syndie-Posts zu bearbeiten, ist ein oft gewünschtes Feature, und damit ließe sich ein Wiki mit einem Rich-Editor umsetzen 17:05 <jrandom> aber natürlich existiert nichts in einem Vakuum - wenn jemand glaubt, dass das notwendig ist, sollte jemand sagen "hey, ein Wiki ist essenziell, und hier ist warum" 17:06 <jrandom> es gibt unendlich viele Apps, die man /bauen kann/, aber da wir auf starke Anonymität und starke Sicherheit abzielen, muss sorgfältig gewählt werden, was gebaut wird 17:07 <+tethra> richtig 17:07 <+tethra> das heißt, einige der schwierigeren Dinge anonym und sicher zu halten, sind vielleicht besser bei jemandem aufgehoben, der gut darin ist, Dinge anonym und sicher zu halten, oder? 17:08 <jrandom> wahrscheinlich, allerdings gibt es keine Kabale - jeder kann lernen 17:08 <+tethra> (Schlüsseldinge, im Grunde. Nicht dass ich etwas beim Namen nenne, aber na ja.) 17:08 <+tethra> stimmt 17:09 <+tethra> aber das Lernen auf Kosten der eigenen und der Anonymität anderer ist nicht der beste Weg 17:10 <jrandom> irgendwo muss jeder anfangen, natürlich 17:10 <+tethra> (vielleicht wäre es gut, wenn jemand eine Art Sandbox bauen würde, die es erlaubt, $software laufen zu lassen und Leute sie angreifen zu lassen und so, das wäre gut für jemanden, der neu/unerfahren ist?) 17:10 <+tethra> ja 17:14 <jrandom> ok, hat noch jemand etwas für das Meeting? 17:15 <jrandom> wenn nicht 17:15 * jrandom leitet den Abschluss ein 17:15 <@cervantes> *räusper* 17:15 * jrandom hält inne 17:16 <jrandom> was geht, cerv? 17:16 <Complication> Cool, ich habe ein baf gefunden ;P 17:17 <jrandom> baf-blockiert ;) 17:17 <@cervantes> ups srry, mach mit dem baffing weiter 17:17 * jrandom setzt das Aufwickeln fort 17:18 * jrandom *baf*t das Meeting zu