I2P-Entwicklertreffen - 16. Mai 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) hi <cervantes> 1) jrandom ist nicht hier <cervantes> 2) ??? <cervantes> 0) hi <cervantes> hi <cervantes> weiter zu 1) <cervantes> jrandom ist heute nicht hier, aber er wird uns morgen ein Status-Update geben <cervantes> 2) ??? <cervantes> hat sonst noch jemand etwas zum Meeting beizutragen? <bar> ich habe eine Frage <cervantes> in dem Fall... * cervantes holt aus * cervantes hört auf auszuholen <Complication> Aha, eine Frage... <bar> der PRNG (Pseudozufallszahlengenerator) Fix im cvs, wird der die allgemeine Performance verbessern oder bezieht er sich auf etwas anderes? <cervantes> es ist ungewiss, welche allgemeinen Konsequenzen das haben könnte <Complication> Ich kenne den Gesamteinfluss persönlich nicht, aber es betrifft mindestens zwei Verhaltensweisen, die mir bewusst sind: <cervantes> aber es behebt speziell ein Symptom bei i2ptunnel * cervantes lässt complication dekomplizieren <Complication> tunnel length Randomisierung und Auswahl des IRC-Servers (allgemeiner: zufällige Auswahl aus einer Liste von I2PTunnel-Zielen) <Complication> Die Randomisierung der tunnel length hat wahrscheinlich einen erheblichen Effekt auf die allgemeine Netzwerkgesundheit, da sie Clients, die bei der tunnel length Kompromisse eingehen dürfen, tatsächlich erlaubt, das auch zu tun <Complication> Sie werden also nicht den Atem anhalten und 2-hop tunnels bauen, sondern auch einige 1-hop tunnels ausprobieren <Complication> (die in harten Zeiten viel leichter zu bekommen sind) <cervantes> auch könnte die IRC-Konnektivität besser werden, sobald es ausgerollt ist. Im Grunde bekam freshcoffee nie Client-Verbindungen, weil es in der Liste an zweiter Stelle stand – mit dem nächsten Release sollte die Last also gleichmäßig auf beide Server verteilt werden <bar> also hat der Bug dazu geführt, dass die Leute, wenn verfügbar, immer die längeren tunnel lengths gewählt haben? <Complication> Wenn ich es richtig verstanden habe, war jede Randomisierung mit eher kleinen Ganzzahlen betroffen (z. B. 0 oder 1 wählen) <Complication> Ich *glaube*, Randomisierungen mit größeren Ganzzahlen (z. B. eine Ganzzahl zwischen 0 und 100 wählen) waren weniger betroffen <Complication> wenn es dich interessiert, solltest du wahrscheinlich jranom nach Details fragen, wenn er zurück ist <Complication> Ich könnte die Details falsch wiedergeben. <bar> verstehe, danke. guter Fang <Complication> nun, cervantes kam her und fing an, sich darüber zu beschweren, dass er keine Überlastung bekommt ;P <cervantes> so habe ich das auch verstanden <cervantes> siehst du... im Leben bekommt man nichts, wenn man nicht meckert :) <cervantes> hat irgendwer noch andere Fragen oder Themen für das Meeting? <fox> <duck> ja <Pi> eine Frage zur allgemeinen Netzgesundheit: Ich sehe, dass immer mehr Clients i2p-version-mäßig zurückbleiben (2 verwenden noch 0.6.1.11 und so weiter). Werden diese Clients es nicht immer schwieriger machen, die Auswirkungen von Änderungen am Core zu beobachten? (da scheinbar „immer weniger“ aktualisieren wollen) <fox> * duck wiederholt das Obige * w423412323 schlägt einen Themenwechsel in dieser Richtung vor. ;) <fox> <duck> Ich habe mich gefragt, ich habe einige abgefahrene Tuning-Commits auf der cvs-Mailingliste gesehen. Sind das eher Experimente? Basieren sie auf Beobachtungen? Sind sie verfrüht? <Complication> Pi: Solange sie nicht in großer Zahl vorhanden sind, sollte das keinen großen Unterschied machen <Pi> 70 von 300 Clients verwenden laut meiner netdb gerade eine nicht-0.6.1.18-Version <Complication> Es ist ein Spiel aus Zahlen und Kapazität – wenn entweder die meisten routers, oder zusätzlich die routers mit der höchsten Kapazität halbwegs aktualisiert sind, macht es nichts, wenn einige Leute vergessen, dass sie I2P installiert haben :) <cervantes> Pi: Wenn sich die älteren routers schlecht verhalten, sollte sich das Netzwerk _anpassen_ und den über sie gerouteten traffic reduzieren <cervantes> *wird geroutet <cervantes> Complication: hast du die Frage von duck gesehen? <Pi> und eine Frage zu einer Statistik auf der i2p-console, die vor einiger Zeit aufgetaucht ist: Was bedeutet handle backlog? <Complication> duck: Meinst du die tunnel throttle Anpassungen? Das ist Tuning in dem Sinne, dass es nichts grundsätzlich Neues bringt, aber es sollte inzwischen recht gut getestet sein (z. B. wird es wohl nicht byte) <Complication> Aber es könnte ein wenig byten, wenn du ein exotisches Setup betreibst, das komplett außerhalb der Parameter liegt, die ich mir vorstellen konnte <fox> <duck> Complication: Ich habe mich gefragt, ob ‚2‘ statt ‚3‘ Dinger wirklich so viel ausmachen <fox> <duck> aber es schien, dass das Random-Problem ein großer Übeltäter gewesen sein könnte <fox> <duck> (obwohl der relative Einfluss auf die Netzwerk-„Ungesundheit“ davon abhängt, wann es eingeführt wurde) <cervantes> Pi: handle backlog ist die Anzahl der ausstehenden eingehenden tunnel Join-Anfragen (Zitat aus dem Changelog) <Complication> Wenn du das zufällige nextInteger()-Problem meinst und die Auswirkungen auf die Randomisierung der tunnel length, denke ich, dass das einen erheblichen Effekt hätte <Complication> Der Kostenunterschied zwischen dem Bau eines 1-hop und eines 2-hop tunnel ist ziemlich erheblich <Pi> thx, cervantes :) <fox> <duck> wann wurde es eingeführt? <Complication> duck: Ich glaube, es wurde mit einigen Umstellungen auf den Fortuna-Generator eingeführt, oder mit irgendeiner Modifikation daran <fox> <duck> ok; vielen Dank für deinen Input <Complication> Lass mich das cvsweb für mehr Details prüfen... <cervantes> Pi: Ich glaube, es gibt jetzt Code, der eingehende tunnel-Anfragen verwirft, wenn die Warteschlange voll wird (um die CPU-Last zu reduzieren) <Complication> Pi: ja, das sollte der sichtbare Indikator für einen weiteren Parameter sein, der bei der Entscheidung genutzt wird: "haben wir genug Kapazität, um an einem weiteren tunnel teilzunehmen?" <cervantes> duck: Ich erlebe seit der Einführung des Fixes auf jeden Fall eine große Änderung im Verhalten des routers. – nicht alles gut, muss ich sagen :) <Complication> großer handle backlog == Stau, es hat keinen Sinn zu versuchen, anderen Leuten tunnels beizutreten <cervantes> hatte neulich eine Load Average von 14 und 12000 teilnehmende tunnels <Complication> Handle backlog scheint besonders auf routers mit hoher Kapazität wichtig zu sein (in Bezug auf das, was cervantes gesehen hat) <Complication> routers mit geringer Kapazität drosseln ihre tunnel-Annahme im Allgemeinen aus Bandbreitengründen <Complication> (oder aus Gründen der tunnel-Testzeit, um genau zu sein) <Complication> (oder versuchen es zumindest) <cervantes> wow, wir haben eine halbe Stunde geschafft.... <Complication> In der Tat :D <cervantes> möchte noch jemand etwas auf den Tisch bringen? <cervantes> in dem Fall... * cervantes holt aus * cervantes *bafft* das Meeting zu <fox> <duck> thx, dass du dich um das Meeting gekümmert hast <cervantes> heh, ich hatte erwartet, es zu baf schließen, bevor irgendwer etwas sagt.... aber bar hat diesen Plan ruiniert :)