Setkání vývojářů I2P - 7. března 2006

15:08 <jrandom> 0) ahoj 15:08 <jrandom> 1) Stav sítě 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) ahoj 15:08 * jrandom mává 15:08 <jrandom> týdenní poznámky o stavu jsou zveřejněny na http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom dává vám všem pár hodin na pročtení té obrovské bichle poznámek 15:10 * Complication předstírá, že si toho ještě nevšiml ;) 15:11 <+Complication> Ahoj :) 15:11 <+susi23> ahoj :) 15:12 <jrandom> no, můžeme se rovnou pustit do 1) stavu sítě 15:12 <jrandom> Ten mail popisuje můj obecný pohled na to, co se děje. jak to sedí s tím, co vidíte vy? 15:13 <+Complication> Opravy škrcení jako by zvýšily spolehlivost, ale opravdu srazily propustnost 15:13 <+Complication> Moment, hledám ten graf 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Vysoké úseky jsou na starších verzích, nízké úseky na nejnovější 15:15 <+Complication> Stejné nastavení omezovače, možná volnější na přísnějších (nejnovějších) verzích 15:16 <+Complication> Ale není to moc velký problém, protože se to přenáší 15:16 <jrandom> super, snížené využití šířky pásma je vhodné, jak se blížíš svému skutečnému limitu šířky pásma 15:17 <+Complication> Většinu času se to zdá stáhnout zpět ještě před limitem "sustained bandwidth" (trvalý limit šířky pásma) 15:17 <+Complication> Nikdy se to nedotkne "burst limit" (krátkodobý limit) 15:18 <+Complication> (což samo o sobě dává smysl – to, že se to stáhne zpět ještě před trvalým limitem, mě znepokojuje) 15:19 <bar> vidím v zásadě to samé co Complication. moje celková spotřeba pásma je jen 50 % mých max. nastavení. před 0.6.1.11 to bývalo ~80 % 15:19 <jrandom> je 200kbps tvoje rychlost omezovače, s 300kbps burst? 15:20 <jrandom> (jen přemýšlím, kolik času to dřív trávilo v burstu) 15:20 <jrandom> snížení využití šířky pásma je ale jedním z cílů nedávných změn 15:21 <+Complication> ~225 trvale, ~325 burst 15:21 <+Complication> Hele, mohl jsem... 15:22 <+Complication> Nevyložil jsem si to špatně? 15:23 <+Complication> Zapomeňte na to, jsem trouba... špatně jsem to spočítal, není to zdaleka tak špatné :O 15:23 <jrandom> nedostatek dat :) mohlo by to ukazovat na problém, ale to, co jsi zatím popsal, naznačuje, že se to chová, jak má 15:23 <+Complication> Je to trochu konzervativní, ale zdaleka ne tak špatné, jak jsem si myslel 15:24 <+Complication> Podle Router Console (která měří ve stejné jednotce jako omezovač) je odchozí celkový průměr 2/3 trvalého limitu a 1/2 krátkodobého limitu 15:25 <+Complication> Ale příchozí celkový průměr je, musím říct, jen mírně nad 1/3 trvalého limitu a 1/4 krátkodobého limitu 15:26 <+Complication> například, při předpokladu trvalého limitu 30 a krátkodobého limitu 40 by odchozí bylo 20 a příchozí něco přes 10 (většinou kvůli nedostatku zátěže) 15:26 <jrandom> super 15:26 <+Complication> Ale ten graf jsem špatně interpretoval, kvůli problémům Kb/KB :O 15:27 * Complication maže ten graf z historie 15:28 <jrandom> dobrý postřeh, každopádně mi určitě dej vědět, když bude něco znít divně 15:28 <jrandom> ok, ještě něco k 1) stavu sítě? 15:28 <jrandom> jestli ne, tak se šoupneme k 2) ??? 15:28 <jrandom> má někdo ještě něco k diskusi? 15:30 <+Complication> No, proběhlo nějaké testování jbigi a zjevně někdo dostal výsledky, které naznačovaly, že 64bit verze pro Linux je spíš pomalejší 15:31 <+Complication> Měli to pomalejší než čistá Java, nevím, jestli to nebyl problém měření :O 15:32 <+Complication> Nepodařilo se mi to zopakovat 15:32 <jrandom> jo, nebyl jsem si jistý, jaké přesně .so pro tu platformu používali 15:32 <+Complication> U mě to bylo asi dvakrát rychlejší než čistá Java 15:32 <+dust> moje experimenty s html jako dalším formátem zpráv v syndie začínají fungovat. můj lokální 'sucker' teď umí stáhnout webové stránky (s obrázky) a uložit je jako příspěvky v syndie 15:33 <jrandom> ah, hustý dust 15:33 <+dust> ale bez css 15:33 <+Complication> Ale lidi na 32bit mluvili o tom, že je to o dost rychlejší než čistá Java (třeba 10x a podobně) 15:35 <bar> hm.. Complication, nemůže být, že současné amd64 .so je jen pro 32bit systémy a on to testoval na 64bit OS? 15:36 <+Complication> bar: může být, protože já jsem to testoval taky na 64bit OS :O 15:36 <jrandom> jestli si dobře pamatuju, amd64 bylo zbuilděné, aby fungovalo na pure64 debianu 15:37 <+Complication> Tak či onak, někteří lidi navrhli, že by mohlo pomoct naimportovat novější gmp 15:37 <bar> jen výstřel do tmy, nejsem v těchhle věcech žádný expert 15:37 <jrandom> eh, používáme 4.1.4 15:37 <+Complication> Zvlášť po jejich brzkém skoku na novou verzi 15:38 <+Complication> Nejsem specialista na gmp, moc k tomu neřeknu 15:38 <jrandom> (a chystané optimalizace v gmp nejspíš nepřinesou výrazné zlepšení) 15:38 <+Complication> Kromě "možná fakt" 15:38 <jrandom> zlepšení přicházejí z buildů pro jednotlivé architektury 15:40 <+Complication> V mém testu, vyprovokovaném jejich testem, se ale 64bit athlon knihovna na 64bit Sempronu, na 64bit Mandrivě, zdá jen nepatrně rychlejší než čistá Java 15:40 <+Complication> (jo a 64bit VM) 15:41 <+Complication> (nepatrně znamená dvakrát) 15:41 <jrandom> hmm 'k 15:42 <+Complication> Zkusím testovat na víc kombinacích platforem a dám vědět, pokud najdu něco, co stojí za sdílení 15:43 <jrandom> super, díky 15:43 <jrandom> ok, má někdo ještě něco na tuhle schůzku? 15:46 <jrandom> pokud ne... 15:46 * jrandom končí 15:47 * jrandom *baf*s uzavírá schůzku