I2P Entwicklertreffen - 07. März 2006

15:08 <jrandom> 0) hi 15:08 <jrandom> 1) Netzstatus 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) hi 15:08 * jrandom winkt 15:08 <jrandom> Wöchentliche Statusnotizen unter http://dev.i2p.net/pipermail/i2p/2006-March/001267.html veröffentlicht 15:09 * jrandom gibt euch allen Stunden, um dieses riesige Konvolut an Notizen durchzulesen 15:10 * Complication tut so, als hätte er es noch nicht bemerkt ;) 15:11 <+Complication> Hi :) 15:11 <+susi23> hi :) 15:12 <jrandom> dann können wir gleich in 1) Netzstatus einsteigen 15:12 <jrandom> Die Mail gibt meinen allgemeinen Überblick darüber, was vor sich geht. Wie deckt sich das mit dem, was ihr so seht? 15:13 <+Complication> Drosselungs-Fixes scheinen die Zuverlässigkeit erhöht zu haben, haben die Bandbreite aber deutlich gedrückt 15:13 <+Complication> Einen Moment, ich suche das Diagramm heraus 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Hohe Abschnitte bei nicht der neuesten Version, niedrige bei der neuesten 15:15 <+Complication> Gleiche Limiter-Einstellungen, möglicherweise sogar lockerer auf den strengeren (neuesten) Versionen 15:16 <+Complication> Aber es ist kein großes Problem, denn es überträgt 15:16 <jrandom> cool, geringerer Bandbreitenverbrauch ist angemessen, wenn du dich deinem tatsächlichen Bandbreitenlimit näherst 15:17 <+Complication> Meistens scheint es vor dem „sustained bandwidth“-Limit zurückzuspringen 15:17 <+Complication> Erreicht nie das Burst-Limit 15:18 <+Complication> (was an sich sinnvoll ist – mich beunruhigt das Zurückspringen vor dem sustained-Limit) 15:19 <bar> Ich sehe ziemlich genau das, was Complication sieht. Mein gesamter Bandbreitenverbrauch liegt nur bei 50% meiner Max-Einstellungen. Vor 0.6.1.11 waren es ~80% 15:19 <jrandom> Ist 200kbps deine Limiter-Rate, mit 300kbps Burst? 15:20 <jrandom> (frage mich nur, wie viel Zeit es früher im Burst verbracht hat) 15:20 <jrandom> Reduzierter Bandbreitenverbrauch ist allerdings eines der Ziele der jüngsten Änderungen 15:21 <+Complication> ~225 sustained, ~325 burst 15:21 <+Complication> Hey, ich hätte... 15:22 <+Complication> Habe ich es falsch *interpretiert*? 15:23 <+Complication> Vergesst es, ich bin ein Trottel... falsch gerechnet, es ist bei weitem nicht so schlimm :O 15:23 <jrandom> Zu wenige Daten :) Es könnte auf ein Problem hindeuten, aber das, was du bisher beschrieben hast, deutet darauf hin, dass sich alles wie gewünscht verhält 15:23 <+Complication> Es ist etwas konservativ, aber bei weitem nicht so schlimm, wie ich dachte 15:24 <+Complication> Laut der Router Console (die in derselben Einheit misst wie der Limiter) liegt der ausgehende Gesamt-Durchschnitt bei 2/3 des sustained-Limits und 1/2 des burst-Limits 15:25 <+Complication> Aber der eingehende Gesamt-Durchschnitt liegt, muss ich sagen, nur knapp über 1/3 des sustained-Limits und 1/4 des burst-Limits 15:26 <+Complication> zum Beispiel: Bei einem sustained-Limit von 30 und einem burst-Limit von 40 läge ausgehend bei 20 und eingehend knapp über 10 (hauptsächlich wegen fehlender Last) 15:26 <jrandom> cool 15:26 <+Complication> Aber das Diagramm habe ich wegen Kb/KB-Problemen falsch interpretiert :O 15:27 * Complication löscht das Diagramm aus der Historie 15:28 <jrandom> Gutes Auge trotzdem, sagt mir auf jeden Fall Bescheid, wenn etwas merkwürdig klingt 15:28 <jrandom> ok, noch etwas zu 1) Netzstatus? 15:28 <jrandom> wenn nicht, schwingen wir rüber zu 2) ??? 15:28 <jrandom> Hat sonst noch jemand etwas zu besprechen? 15:30 <+Complication> Nun, es gab einige jbigi-Tests, und offenbar hat jemand Ergebnisse erhalten, die nahelegen, dass die 64‑Bit‑Version für Linux eher langsam ist 15:31 <+Complication> Bei ihnen war sie langsamer als reines Java, nicht sicher, ob ein Messfehler oder nicht :O 15:32 <+Complication> Ich konnte das nicht reproduzieren 15:32 <jrandom> ja, ich war mir nicht sicher, welche .so sie genau für die Plattform verwendet haben 15:32 <+Complication> Hier war es etwa doppelt so schnell wie reines Java 15:32 <+dust> meine experimente mit html als einem zusätzlichen nachrichtenformat in syndie fangen an zu funktionieren. mein lokaler 'sucker' kann jetzt webseiten (mit bildern) abrufen und als syndie posts speichern 15:33 <jrandom> ah wikked dust 15:33 <+dust> kein css tho 15:33 <+Complication> Aber Leute auf 32‑Bit berichteten, dass es *wesentlich* schneller als reines Java ist (so etwa 10x oder ähnlich) 15:35 <bar> hmm.. Complication, könnte es sein, dass die aktuelle amd64-.so nur für 32‑Bit‑Systeme ist und er sie auf einem 64‑Bit‑OS getestet hat? 15:36 <+Complication> bar: könnte sein, da ich es auch auf einem 64‑Bit‑OS getestet habe :O 15:36 <jrandom> iirc the amd64 was built to work on pure64 debian 15:37 <+Complication> So oder so schlugen einige vor, dass das Einbinden einer frischeren gmp helfen könnte 15:37 <bar> nur ein schuss ins blaue, ich bin kein wiz bei diesen dingen 15:37 <jrandom> eh, wir verwenden 4.1.4 15:37 <+Complication> Besonders nachdem sie ihren bald anstehenden Versionssprung gemacht haben 15:38 <+Complication> Da ich kein gmp‑Spezialist bin, könnte ich dazu nicht viel sagen 15:38 <jrandom> (und die bevorstehenden Optimierungen in gmp werden voraussichtlich keine erheblichen Verbesserungen bringen) 15:38 <+Complication> Abgesehen von „vielleicht tatsächlich“ 15:38 <jrandom> Verbesserungen kommen durch architekturspezifische Builds 15:40 <+Complication> In meinem Test, ausgelöst durch ihren Test, scheint die 64‑Bit‑Athlon‑lib auf einem 64‑Bit‑Sempron unter einem 64‑Bit‑Mandriva allerdings nur geringfügig schneller zu sein als reines Java 15:40 <+Complication> (oh, und eine 64‑Bit‑VM) 15:41 <+Complication> (geringfügig = doppelt so schnell) 15:41 <jrandom> hmm 'k 15:42 <+Complication> Ich werde auf mehr Plattformkombinationen testen und Bescheid sagen, wenn ich etwas finde, das sich zu berichten lohnt 15:43 <jrandom> cool, danke 15:43 <jrandom> ok, hat noch jemand etwas für das Meeting? 15:46 <jrandom> wenn nicht... 15:46 * jrandom leitet das Ende ein 15:47 * jrandom *baf*s das Meeting