I2P-Entwicklertreffen - 25. April 2005

16:12 <jrandom> 0) hi 16:12 <jrandom> 1) Netzstatus und 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) hi 16:13 * jrandom winkt 16:13 <@cervantes> 'lo 16:13 <jrandom> Wöchentliche Statusnotizen veröffentlicht @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> während ihr euch das kurz anschaut, springen wir zu 1) Netzstatus 16:14 <jrandom> also, wie die meisten von euch gesehen haben, haben wir ein neues Release herausgebracht, und bisher sind die Ergebnisse ziemlich positiv 16:15 <@cervantes> (yay!) 16:15 <jrandom> noch nicht da, wo wir hinmüssen, aber es räumt die Hauptprobleme, die wir gesehen haben, weitgehend aus 16:15 <jrandom> ja, es ist schön, wieder halbwegs brauchbare tunnel-Bauraten zu haben, bei 2+ Hop tunnels :) 16:16 * jrandom hat 50%+ Erfolgsraten auf einem anderen router mit 1-Hop tunnels 16:17 <jrandom> Ich denke, die letzten Änderungen in 0.6.1.17 sollten auch künftig helfen, diese Art von Kongestionskollaps zu vermeiden 16:17 <jrandom> für Nutzer sichtbar ist allerdings, dass wir gelegentlich lease-Abläufe sehen werden, aber statt sich hochzuschaukeln, fährt es dann zurück 16:17 * cervantes startet azureus 16:18 <+Complication> Heute Morgen habe ich client tunnel (Länge 2 +/- 1) Erfolgsraten von nahe 35% aufgezeichnet 16:18 <+Complication> Aktuell ist es niedriger, da ich einige Änderungen ausprobiert habe und die letzte davon nicht so toll war :D 16:18 <@cervantes> jrandom: gut gemacht, das herauszufinden – wir fingen schon an, ein wenig wie freenet auszusehen :) 16:19 <jrandom> *hust* ;) 16:20 <+fox> <inkeystring> jrandom: würdest du kurz den Backoff-Mechanismus beschreiben? ich arbeite gerade an etwas Ähnlichem für freenet 0.7 16:21 <jrandom> inkeystring: wir hatten auf der Transportschicht einen Backoff-Mechanismus, um Übertragungen zu einem Peer zu verringern, wenn die Transportschicht überlastet ist, aber das war nicht ausreichend 16:21 <@cervantes> *hust* sagte ich freenet, ich meinte tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: die neue Änderung war, das nach oben auf eine höhere Ebene zu propagieren, sodass wir aufhören, tunnels zu bauen, wenn unsere Kommunikationsschicht gesättigt ist 16:22 <jrandom> (statt noch mehr tunnel-Bauversuche zu senden) 16:22 <+fox> <inkeystring> danke – macht die Transportschicht nur Backoff bei Paketverlust, oder gibt es eine Möglichkeit für den Empfänger, den Fluss zu steuern? 16:23 * jrandom erinnert sich, mit toad ein paar Mal (auf irc und in meinem alten Flog) die Auswirkungen von Congestion vs. Routing diskutiert zu haben, allerdings erinnere ich keine netto-positive Lösung :/ 16:23 <jrandom> der Empfänger kann NACKen, und wir haben Hooks für ECN, aber sie waren nicht nötig 16:23 <+fox> <inkeystring> ja, die Debatte ist auf freenet-dev wieder aufgeflammt :-) noch immer keine Wunderwaffe 16:24 <+fox> <inkeystring> cool, danke für die Information 16:24 <+Complication> Verwenden die heutzutage nicht auch UDP? 16:24 <jrandom> derzeit haben stark überlastete Peers Probleme nicht mit der per-Peer-Drosselung, sondern mit der Breite der Peer-Kommunikation 16:24 <+Complication> (als Transportprotokoll) 16:24 <+fox> <inkeystring> Breite = Anzahl der Peers? 16:24 <jrandom> ja 16:25 <jrandom> mit den erhöhten tunnel-Erfolgsraten müssen Peers nicht mehr mit Hunderten Peers sprechen, nur um einen tunnel gebaut zu bekommen 16:25 <jrandom> sie kommen also mit nur 20-30 Peers aus 16:25 <jrandom> (direkt verbundene Peers, wohlgemerkt) 16:26 <+fox> <inkeystring> ich schätze, das sind gute Nachrichten für NAT Hole Punching, Keepalives usw.? 16:26 <jrandom> andererseits, mit 2-300 aktiven SSU-Verbindungen wird eine 6KBps-Leitung Probleme haben 16:26 <jrandom> ja 16:26 <+fox> <inkeystring> Complication: ja 16:27 <+fox> <inkeystring> (in der 0.7-Alpha) 16:27 <+Complication> Aha, dann stehen sie wahrscheinlich vor ähnlichen Dingen 16:27 <+Complication> Ich hoffe, jemand findet die Wunderwaffe :D 16:27 <jrandom> allerdings auf andere Weise. die Transportschicht ist ein relativ einfaches Thema 16:27 <+fox> <inkeystring> ich denke, sie haben vielleicht etwas des SSU-Codes wiederverwendet ... oder zumindest darüber gesprochen 16:27 <jrandom> (sprich seit 30+ Jahren gut erforscht) 16:28 <jrandom> aber die Lastverteilung in i2p (und freenet) arbeitet auf einer höheren Ebene als Punkt-zu-Punkt-Verbindungen und hat andere Anforderungen 16:28 <+fox> <inkeystring> ja, die Interaktion mit dem Routing ist knifflig 16:29 <jrandom> ja, wobei i2p es einfacher hat (wir müssen nicht spezifische Peers mit den betreffenden Daten finden, sondern nur irgendwelche mit Kapazität, an unseren tunnels teilzunehmen) 16:30 <+fox> <inkeystring> also gibt es keinen Effizienzverlust, wenn man einen überlasteten Peer meidet... 16:30 <+fox> <inkeystring> während in freenet das Routing um einen überlasteten Peer die Pfadlänge erhöhen kann 16:30 <+fox> <inkeystring> wie auch immer sorry fürs OT 16:31 <jrandom> kein Problem, wobei es relevant war zu erklären, warum die Änderungen in 0.6.1.17 unseren Kongestionskollaps beeinflusst haben :) 16:31 <jrandom> ok, hat noch jemand etwas zu 1) Netzstatus? 16:32 <+Complication> Nun, wie schon erwähnt, beim Betrieb mit reinem .17 habe ich eine spürbare Periodizität bei Bandbreite und aktiven Peers beobachtet 16:32 <+Complication> Und ein paar andere scheinen es auch zu erleben, obwohl ich keine Ahnung habe, wie verbreitet es ist 16:33 <+Complication> Ich habe über die Hauptursachen gerätselt, vor allem aus der Perspektive der tunnel-Drosselung, aber noch keine Lösung 16:33 <+Complication> Ich habe es geschafft, meine eigenen Graphen flacher aussehen zu lassen, aber nur zum Preis einiger allgemeiner Verschlechterungen 16:33 <+Complication> Habe Änderungen wie diese ausprobiert: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (das sollte verhindern, dass es für seine eigenen tunnels völlig auf Bauversuche verzichtet) 16:35 <jrandom> ach richtig 16:35 <+Complication> (oh, und natürlich ist das Loglevel schräg, da ich das zum Testen geändert habe) 16:35 <jrandom> wir haben dort etwas Code, der versucht, die Periodizität etwas zu verschieben, aber das funktioniert nicht ganz richtig (offensichtlich) 16:36 * perv hat gerade sein System geschossen :( 16:36 <+Complication> Aber ich habe Dinge wie diese probiert und versucht, den Wachstumsfaktor für die Anzahl der tunnel zu reduzieren 16:36 <perv> gibt es ein Undelete für reiser4? 16:36 <jrandom> grundsätzlich sollte es helfen, wenn wir so tun, als würden tunnels (zufällig) früher ablaufen, als sie es tatsächlich tun 16:36 <+Complication> Lese gerade die große Funktion "countHowManyToBuild" in TunnelPool.java :D 16:36 <+Complication> Aber ich habe sie noch nicht durchgelesen 16:37 <jrandom> (auch wenn das offensichtlich die Häufigkeit des tunnel-Aufbaus erhöhen würde, was vor 0.6.1.17 nicht sinnvoll gewesen wäre) 16:37 <+Complication> perv: da gibt es etwas 16:37 <jrandom> hmm, dort eine Randomisierung einzubauen wäre schwierig, Complication, da wir diese Funktion ziemlich häufig aufrufen 16:38 * perv erwägt, zu retten und auf gentoo zu wechseln 16:38 <jrandom> was ich empfehlen würde, wäre, die Ablaufzeit erfolgreich aufgebauter tunnels zu randomisieren 16:38 <+Complication> perv: mit reiser bist du besser bedient als mit ext3, auf jeden Fall 16:38 <+Complication> perv: aber ich weiß es nicht auswendig 16:38 <+Complication> jrandom: stimmt, manchmal könnte es so zu viel bauen 16:38 <jrandom> (so dass die bestehende countHowManyToBuild denkt, sie braucht sie, bevor sie es tatsächlich tut) 16:38 <+Complication> (und manchmal baut es zwangsläufig zu viel, wenn tunnels brechen und es hastig wird) 16:40 <+Complication> Hmm, eine Möglichkeit, die ich nicht bedacht habe... 16:41 <+Complication> Wie auch immer, ich spiele auch damit, aber noch keine hilfreichen Beobachtungen 16:42 <jrandom> cool, ich habe ein paar Tweaks, mit denen ich dazu experimentiere; vielleicht bekommen wir das bis zum nächsten Build zusammen, um zu sehen, wie es im halbwegs brauchbaren Netz funktioniert ;) 16:43 <spinky> Gibt es eine Statistik, in der man sehen kann, wie viel Overhead das i2p-Netz dem Anwendungsdatenverkehr hinzufügt? 16:43 <jrandom> „Overhead“ ist so ein aufgeladener Begriff... ;) 16:43 <jrandom> wir nennen es die Kosten der Anonymität ;) 16:43 <spinky> hehe 16:45 <jrandom> (bzw. nicht wirklich. Nutzlast auf Anwendungsebene erreicht in einem perfekten Netz mit 0 Congestion & 1+1 Hops etwa 70–80% Effizienz an den Endpunkten) 16:45 <jrandom> ((als ich das zuletzt gemessen habe)) 16:45 <jrandom> aber das sind wirklich Laborbedingungen 16:45 <jrandom> das Live-Netz ist viel komplizierter 16:47 <spinky> Genau, ich meinte nur die Menge an zusätzlichen Daten für das Einrichten von tunnels, Schlüssel, Padding usw. 16:47 <spinky> ...verglichen mit den übertragenen Anwendungsdaten 16:47 <jrandom> hängt vom Framing der Nachrichten, Congestion, den Erfolgsraten beim tunnel-Aufbau usw. ab 16:48 <jrandom> ein 2-Hop tunnel kann gebaut werden, wobei das Netz etwa 20KB tragen muss 16:48 <+Complication> Ich wollte das schon mal testen, primär mit dem Ziel, die „Verschwendungs“-Rate von Massentransferanwendungen wie BitTorrent und I2Phex abzuschätzen 16:48 <+Complication> Aber ich bin nie dazu gekommen, eine saubere Messung zwischen meinen zwei Nodes zu machen 16:48 <+Complication> Irgendwann gehe ich das aber an 16:49 <jrandom> Complication: das ist bei geschwätzigen Apps ziemlich schwierig, viel einfacher ist es, wget zu messen :) 16:49 <+Complication> Wie wahr 16:50 <+Complication> Bei dem, was ich ausprobiert habe, war keine Spur von Präzision dabei 16:54 <jrandom> ok, wenn es zu 1) nichts Weiteres gibt, gehen wir über zu 2) I2Phex 16:55 <jrandom> Complication: woran arbeitest du? :) 16:55 <+Complication> Nun, der gestrige Commit war ein Fix für bestimmte Probleme, die einige Leute mit meinem albernen First-Run-Detektor erlebt haben 16:56 <+Complication> Der First-Run-Detektor ist jetzt weniger albern, und bar berichtete, dass er sich nun normal zu verhalten scheint 16:56 <+Complication> Allerdings, da I2Phex unter den aktuellen Netzbedingungen bereits lauffähig scheint, 16:56 <+Complication> werde ich auch versuchen, den Rehash-Bug zu finden. 16:57 <+Complication> Wenn ich nur kann 16:57 <jrandom> cool, ich weiß, der verfolgt dich schon seit Monaten 16:57 <+Complication> Interessant ist, dass Mainline-Phex ihn vielleicht auch hat, und ihre Beobachtungen zu finden und zu lesen werde ich ebenfalls versuchen 16:58 <jrandom> aber schön zu hören, dass der Startup-Fix drin ist 16:58 <jrandom> ah, alles klar 16:58 <+Complication> =ist das 16:58 <+Complication> Ich kann derzeit jedoch nicht bestätigen, ob Mainline-Phex ihn hat oder nicht – habe ihn dort persönlich nie gesehen 16:59 <jrandom> (sporadische Bugs)-- 16:59 <+Complication> Es ist schwer, ihn kontrolliert hervorzurufen, und daher schwer zu finden 17:00 <+Complication> Und von meiner Seite war's das fürs Erste 17:00 <+Complication> Später habe ich mich gefragt, ob es sinnvoll wäre, die Anzahl der parallelen Peer-Kontaktversuche zu begrenzen, die I2Phex auf einmal abfeuert 17:01 <jrandom> ja, wahrscheinlich 17:01 <+Complication> Weil sie in kurzer Zeit eine ganze Menge NetDB-Lookups erzeugen würden, was aus Sicht eines I2P router potenziell nicht so schön ist 17:02 <jrandom> und neue Destination-Kontakte benötigen elG statt aes 17:02 <+Complication> Aber ich habe noch keinen Code dafür gelesen oder geschrieben 17:04 <jrandom> ok, kein Problem. vielleicht bringt der mythische i2phex/phex-Merge eine Lösung mit :) 17:04 <+Complication> Und von meiner Seite war's das an Neuigkeiten von der I2Phex-Front... 17:04 <jrandom> cool, danke für das Update und die Mühe beim Nachforschen! 17:05 <jrandom> ok, springen wir weiter zu 3) ??? 17:05 <jrandom> hat noch jemand etwas für das Meeting? 17:05 <lsmith> hallo! ich möchte die devs nur für die fantastischen Verbesserungen im neuesten Release loben, meine Gesamtbandbreite zeigt 0.9/1.4 KBps und ich bleibe mit irc verbunden... das ist... wahnsinnig cool :) 17:05 <+Complication> :D 17:06 <jrandom> danke für eure Geduld auf dem Weg – die Unterstützung von Nutzern mit niedriger Bandbreite ist entscheidend 17:06 <@cervantes> lsmith: das ist wirklich gut zu 17:06 <@cervantes> * Verbindung zurückgesetzt 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> oh, eine weitere bemerkenswerte Sache ist, dass zzz zurück ist, und mit ihm kommt stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Eine ziemlich nützliche Quelle für Vergleichsdaten :) 17:11 <jrandom> definitiv 17:11 <jrandom> ok, hat noch jemand etwas für das Meeting? 17:13 <jrandom> wenn nicht... 17:13 <jdot> ich habe ein oder zwei Post-baf-Fragen 17:13 <jrandom> heh ok, dann bringen wir den Baffer ins Rollen :) 17:13 * jrandom holt aus... 17:13 * jrandom *baf*t das Meeting zu