I2P vývojářské setkání - 16. května 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) ahoj <cervantes> 1) jrandom tu není <cervantes> 2) ??? <cervantes> 0) ahoj <cervantes> ahoj <cervantes> přejděme k 1) <cervantes> jrandom tu dnes není, ale zítra nám dá status update <cervantes> 2) ??? <cervantes> má někdo něco dalšího k dnešnímu setkání? <bar> mám otázku <cervantes> v tom případě... * cervantes se natahuje * cervantes přestává natahovat <Complication> Aha, otázka... <bar> ta oprava PRNG v cvs, zlepší to obecný výkon, nebo se to týká něčeho jiného? <cervantes> obecně není jisté, jaké to může mít důsledky <Complication> O celkovém dopadu osobně nemám přehled, ale týká se to alespoň dvou chování, o kterých vím: <cervantes> ale konkrétně to opravuje symptom v i2ptunnel * cervantes nechává Complication odkomplikovat <Complication> náhodná volba délky tunnelu a výběr IRC serveru (obecněji, náhodný výběr ze seznamu I2PTunnel destinací) <Complication> Náhodná volba délky tunnelu má pravděpodobně významný vliv na celkové zdraví sítě, protože umožní klientům, kteří si můžou dovolit kompromis v délce tunnelu, to skutečně udělat <Complication> Takže nebudou zadržovat dech a stavět 2-hop tunnels, ale zkusí i nějaké 1-hop tunnels <Complication> (které jsou v těžkých časech mnohem snazší získat) <cervantes> také se může zlepšit IRC konektivita, jakmile se to rozšíří. V zásadě freshcoffee nedostával žádná klientská připojení, protože byl druhý v seznamu – takže s příštím vydáním by se zátěž měla rovnoměrně rozdělit mezi oba servery <bar> takže ten bug způsobil, že lidé vždycky volili delší délky tunnelu, když byly k dispozici? <Complication> Pokud jsem to správně pochopil, byla tím ovlivněna každá randomizace s menšími celými čísly (např. vyber 0 nebo 1) <Complication> *myslím*, že randomizace s většími celými čísly (např. vyber celé číslo mezi 0 a 100) byly ovlivněné méně <Complication> pokud tě to zajímá, asi bys měl požádat jranom o podrobnosti, až se vrátí <Complication> Můžu se v detailech mýlit. <bar> chápu, díky. dobrý postřeh <Complication> no, cervantes sem přišel a začal si stěžovat, že nedostává žádné přetížení ;P <cervantes> tak jsem to pochopil i já <cervantes> vidíš... nic v životě nedostaneš, když si nezabrbláš :) <cervantes> má někdo další otázky nebo témata pro setkání? <fox> <duck> ano <Pi> otázka k obecnému zdraví sítě: vidím víc a víc klientů, kteří zůstávají pozadu co do i2p-verze (2 pořád používají 0.6.1.11 atd.). Nebudou tito klienti čím dál víc ztěžovat monitorování dopadů změn v jádře? (protože „méně“ lidí se zdá chtít aktualizovat) <fox> * duck opakuje výše uvedené * w423412323 navrhuje změnu tématu tím směrem. ;) <fox> <duck> Přemýšlel jsem, viděl jsem na mailinglistu CVS pár zvláštních commitů k ladění. Jsou to spíš experimenty? Jsou založené na pozorováních? Nejsou předčasné? <Complication> Pi: dokud nejsou přítomny ve velkých počtech, neměly by mít velký vliv <Pi> 70 z 300 klientů teď podle mého netdb používá jinou než 0.6.1.18 verzi <Complication> Je to hra čísel a kapacity – pokud je buď většina routerů, nebo navíc routery s nejvyšší kapacitou rozumně aktualizovaná, pár lidí, kteří zapomněli, že si nainstalovali I2P, by nemělo vadit :) <cervantes> Pi: pokud se starší routery chovají špatně, síť by se _měla_ přizpůsobit a omezit provoz směrovaný přes ně <cervantes> *being routed <cervantes> Complication: viděl jsi duckovu otázku? <Pi> a otázka ke statistice na i2p-console, která se objevila před nějakou dobou: co znamená handle backlog? <Complication> duck: myslíš úpravy škrcení tunnelů? Je to ladění v tom smyslu, že nepřináší nic zásadně nového, ale měly by být teď docela dobře otestované (tj. asi nebudou kousat) <Complication> Ale možná trochu kousnou, pokud provozuješ exotickou konfiguraci, která je úplně mimo parametry, které mě napadly <fox> <duck> Complication: zajímalo mě, jestli na tom opravdu záleželo, aby '2' místo '3' věciček <fox> <duck> ale zdálo se, že problém s náhodností mohl být velký prevít <fox> <duck> (ačkoliv relativní dopad na nezdravý stav sítě závisí na tom, kdy byl zaveden) <cervantes> Pi: handle backlog je počet čekajících žádostí o připojení do příchozích tunnelů (citováno z changelogu) <Complication> Pokud myslíš problém s random nextInteger() a dopad na náhodnou volbu délky tunnelu, mám pocit, že to má významný efekt <Complication> Rozdíl v nákladech mezi stavbou 1-hop a 2-hop tunnelu je dost významný <Pi> díky, cervantes :) <fox> <duck> kdy to bylo zavedeno? <Complication> duck: myslím, že to přišlo s nějakými přepnutími na Fortuna generator, nebo s nějakou úpravou v něm <fox> <duck> ok; díky moc za tvoje postřehy <Complication> Nech mě zkontrolovat cvsweb pro víc detailů... <cervantes> Pi: myslím, že je teď nasazený kód, který zahazuje příchozí žádosti o tunnel, když se fronta zaplní (aby se snížilo zatížení cpu) <Complication> Pi: ano, to by měl být viditelný indikátor dalšího parametru používaného při rozhodování „máme dost kapacity, abychom se účastnili dalšího tunnelu?“ <cervantes> duck: určitě pozoruji velkou změnu v chování routeru od chvíle, kdy byla oprava nasazena. – ne všechno dobré, musím říct :) <Complication> velký handle backlog == přetížení, nemá smysl zkoušet se připojit do tunnelů ostatních <cervantes> nedávno jsem měl load average 14 a 12000 participating tunnels <Complication> Handle backlog se zdá důležitý zejména u routerů s vysokou kapacitou (viz co viděl cervantes) <Complication> Routery s nízkou kapacitou obecně škrtí přijímání tunnelů kvůli důvodům šířky pásma <Complication> (přesněji kvůli času testu tunnelů) <Complication> (nebo se o to alespoň snaží) <cervantes> páni, zvládli jsme půl hodiny.... <Complication> Vskutku :D <cervantes> chce ještě někdo něco přidat na stůl? <cervantes> v tom případě... * cervantes se natahuje * cervantes *baffs* schůzi uzavírá <fox> <duck> díky, že ses postaral o schůzku <cervantes> heh čekal jsem, že to bafnu a zavřu dřív, než někdo něco řekne.... ale bar ten plán zkazil :)