I2P vývojářské setkání - 25. dubna 2005

16:12 <jrandom> 0) ahoj 16:12 <jrandom> 1) Stav sítě a 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) ahoj 16:13 * jrandom mává 16:13 <@cervantes> čau 16:13 <jrandom> týdenní statusové poznámky zveřejněny @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> zatímco si to všichni prolítnete, pojďme na 1) Stav sítě 16:14 <jrandom> takže, jak většina z vás viděla, máme venku nové vydání a zatím jsou výsledky docela pozitivní 16:15 <@cervantes> (jupí!) 16:15 <jrandom> pořád nejsme tam, kde potřebujeme být, ale v zásadě to řeší hlavní problémy, které jsme viděli 16:15 <jrandom> jo, je fajn mít zase obstojné míry sestavování tunnel (tunel) u 2+ hop tunnels :) 16:16 * jrandom má 50%+ úspěšnost na jiném routeru (směrovač) s 1hop tunnels 16:17 <jrandom> myslím, že posledních pár změn v 0.6.1.17 by mělo do budoucna pomoci vyhnout se tomuhle typu kolapsu z přetížení 16:17 <jrandom> pro uživatele to ale znamená, že občas uvidíme vypršení lease, ale místo aby se to nabalovalo, dojde k backoff 16:17 * cervantes spouští Azureus 16:18 <+Complication> Dnes ráno jsem zaznamenal úspěšnost klientských tunnel (délka 2 +/- 1) kolem 35 % 16:18 <+Complication> Teď je to nižší, protože jsem zkusil pár úprav a ta poslední nebyla nic moc :D 16:18 <@cervantes> jrandom: dobrá práce s dohledáním – chvílemi jsme začínali vypadat jako freenet :) 16:19 <jrandom> *ehm* ;) 16:20 <+fox> <inkeystring> jrandom: nevadilo by ti stručně popsat backoff mechanismus? Momentálně pracuju na něčem takovém pro freenet 0.7 16:21 <jrandom> inkeystring: měli jsme backoff na transportní vrstvě, který snižuje přenosy k peerovi, když je transportní vrstva přetížená, ale to nestačilo 16:21 <@cervantes> *ehm* říkal jsem freenet, myslel jsem tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: nová změna byla propagovat to výš, aby se přestalo pokoušet stavět tunnels, když je naše komunikační vrstva saturovaná 16:22 <jrandom> (místo posílání dalších pokusů o sestavení tunnel) 16:22 <+fox> <inkeystring> díky – dělá transportní vrstva backoff jen při ztrátě paketů, nebo má příjemce nějakou možnost řídit tok? 16:23 * jrandom si vybavuje, že s toadem párkrát probíral dopad přetížení vs. směrování (na irc a na mém starém flogu), ale na žádné čistě pozitivní řešení si nevzpomínám :/ 16:23 <jrandom> příjemce může poslat NACK a máme podporu pro ECN, ale nebylo to potřeba 16:23 <+fox> <inkeystring> jo, debata se znovu objevila na freenet-dev :-) pořád žádná stříbrná kulka 16:24 <+fox> <inkeystring> super, díky za informace 16:24 <+Complication> Taky teď používají UDP, že? 16:24 <jrandom> aktuálně mají silně přetížené peery problém ne s omezením per-peer, ale s rozsahem komunikace mezi peery 16:24 <+Complication> (jako transportní protokol) 16:24 <+fox> <inkeystring> šířka = počet peerů? 16:24 <jrandom> ano 16:25 <jrandom> s vyšší úspěšností tunnel už peer nemusí mluvit se stovkami peerů jen proto, aby se postavil tunnel 16:25 <jrandom> takže si vystačí jen s 20–30 peery 16:25 <jrandom> (tedy přímo připojené peery) 16:26 <+fox> <inkeystring> hádám, že to jsou dobré zprávy pro NAT hole punching, keepalive atd.? 16:26 <jrandom> na druhou stranu, při 2–300 aktivních SSU spojení bude mít linka 6 KB/s problémy 16:26 <jrandom> jo 16:26 <+fox> <inkeystring> Complication: ano 16:27 <+fox> <inkeystring> (v 0.7 alfa) 16:27 <+Complication> Aha, tak pak nejspíš čelí podobným věcem 16:27 <+Complication> Doufám, že někdo najde kouzelnou kulku :D 16:27 <jrandom> ale jiným způsobem. Transportní vrstva je relativně snadný problém 16:27 <+fox> <inkeystring> myslím, že možná zrecyklovali část kódu SSU... nebo o tom aspoň mluvili 16:27 <jrandom> (alias dobře prozkoumáno přes 30 let) 16:28 <jrandom> ale vyvažování zátěže v i2p (a freenet) funguje na vyšší úrovni než point-to-point linky a má jiné požadavky 16:28 <+fox> <inkeystring> jo, ošemetná je interakce se směrováním 16:29 <jrandom> jo, i když I2P to má snazší (nemusíme najít konkrétní peery s danými daty, stačí kdokoli s kapacitou účastnit se našich tunnel) 16:30 <+fox> <inkeystring> takže není ztráta efektivity, když se vyhneš přetíženému peeru... 16:30 <+fox> <inkeystring> zatímco ve freenet může obcházení přetíženého peeru prodloužit cestu 16:30 <+fox> <inkeystring> každopádně sorry za OT 16:31 <jrandom> v pohodě, vysvětlit, proč změny v 0.6.1.17 ovlivnily náš kolaps z přetížení, bylo relevantní :) 16:31 <jrandom> ok, má ještě někdo něco k 1) Stavu sítě? 16:32 <+Complication> Jak už bylo zmíněno, při čistém .17 jsem pozoroval výraznou periodicitu v šířce pásma a počtu aktivních peerů 16:32 <+Complication> A pár dalších lidí to zřejmě zažívá taky, i když netuším, jak časté to je 16:33 <+Complication> Přemýšlím nad hlavními příčinami, hlavně z pohledu řízení tempa u tunnel, ale zatím bez řešení 16:33 <+Complication> Dokázal jsem své grafy trochu zploštit, ale za cenu celkového zhoršení 16:33 <+Complication> Zkoušel jsem úpravy jako: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (to mělo zabránit tomu, aby úplně přestalo zkoušet stavět své vlastní tunnels) 16:35 <jrandom> aha jasně 16:35 <+Complication> (a samozřejmě je loglevel mimo, protože jsem ho kvůli testování změnil) 16:35 <jrandom> máme tam nějaký kód, který se snaží tu periodicitu trochu rozladit, ale nefunguje to úplně správně (zjevně) 16:36 * perv právě odstřelil svůj systém :( 16:36 <+Complication> Ale zkoušel jsem podobné věci a zkoušel snížit růstový faktor počtu tunnel 16:36 <perv> existuje undelete pro reiser4? 16:36 <jrandom> v zásadě, když se budeme tvářit, že tunnels vyprší (náhodně) dřív, než skutečně vyprší, mělo by to pomoci 16:36 <+Complication> Zrovna čtu velkou funkci "countHowManyToBuild" v TunnelPool.java :D 16:36 <+Complication> Ještě jsem ji nedočetl 16:37 <jrandom> (i když to samozřejmě zvýší frekvenci stavění tunnel, což před 0.6.1.17 nebylo rozumné) 16:37 <+Complication> perv: něco existuje 16:37 <jrandom> hmm, dát tam náhodnost by bylo těžké, Complication, protože tu funkci voláme poměrně často 16:38 * perv zvažuje záchranu a přechod na Gentoo 16:38 <jrandom> doporučil bych podívat se na náhodnění doby expirace úspěšně postavených tunnels 16:38 <+Complication> perv: s reiserem jsi na tom určitě líp než s ext3 16:38 <+Complication> perv: ale z hlavy to nevím 16:38 <+Complication> jrandom: pravda, někdy by to takhle mohlo přestavovat víc, než je třeba 16:38 <jrandom> (aby si stávající countHowManyToBuild myslela, že je potřebuje dřív, než doopravdy) 16:38 <+Complication> (a někdy to nevyhnutelně přestaví víc, když se tunnels rozbijí a zpanikaří to) 16:40 <+Complication> Hmm, možnost, kterou jsem nezvážil... 16:41 <+Complication> Každopádně si s tím taky hraju, ale zatím žádná užitečná pozorování 16:42 <jrandom> super, mám k tomu pár drobných úprav, se kterými si hraju – možná je dáme dohromady do dalšího buildu a uvidíme, jak to funguje na rozumně životaschopné síti ;) 16:43 <spinky> Je nějaká statistika, kde lze vidět, kolik overheadu síť I2P přidává k aplikačním datům? 16:43 <jrandom> "overhead" je tak nabitý termín... ;) 16:43 <jrandom> říkáme tomu cena anonymity ;) 16:43 <spinky> hehe 16:45 <jrandom> (alias ne tak úplně. U aplikační nálože na dokonalé síti s nulovým přetížením a 1+1hops je účinnost na koncích něco jako 70–80 %) 16:45 <jrandom> ((naposledy, když jsem měřil)) 16:45 <jrandom> ale to jsou opravdu laboratorní podmínky 16:45 <jrandom> živá síť je mnohem složitější 16:47 <spinky> Jasně, myslel jsem jen množství extra dat použitých na vytváření tunnels, klíčů, paddingu atd 16:47 <spinky> ...v porovnání s přenesenými aplikačními daty 16:47 <jrandom> záleží na rámování zpráv, přetížení, úspěšnosti sestavování tunnel atd 16:48 <jrandom> 2 hop tunnel může síť postavit s přenosem 20 KB 16:48 <+Complication> Chtěl jsem to občas testovat, hlavně s cílem odhadnout "plýtvání" u aplikací pro hromadný přenos jako BitTorrent a I2Phex 16:48 <+Complication> Ale nikdy jsem se nedostal k čistému měření mezi svými dvěma uzly 16:48 <+Complication> Jednou se k tomu ale vrátím 16:49 <jrandom> Complication: s ukecanými aplikacemi je to dost těžké, mnohem jednodušší je měřit wget :) 16:49 <+Complication> To je svatá pravda 16:50 <+Complication> V tom, co se mi podařilo zkusit, nebyla ani stopa po přesnosti 16:54 <jrandom> ok, pokud k 1) už nic není, přesuneme se k 2) I2Phex 16:55 <jrandom> Complication: co máš nového? :) 16:55 <+Complication> Včerejší commit byl oprava určitých problémů, které někteří zažívali s mým pitomým detektorem prvního spuštění 16:56 <+Complication> Detektor prvního spuštění je teď méně pitomý a bar hlásil, že se zdá, že začal fungovat normálně 16:56 <+Complication> Nicméně, vzhledem k tomu, že I2Phex se v aktuálních podmínkách sítě už zdá provozuschopný, 16:56 <+Complication> zkusím najít i bug s rehash. 16:57 <+Complication> Pokud se mi to povede 16:57 <jrandom> super, vím, že tě tenhle pronásleduje už měsíce 16:57 <+Complication> Zajímavé je, že ho možná má i mainline Phex, a zkusím najít a přečíst si i jejich pozorování 16:58 <jrandom> ale je fajn slyšet, že oprava startu je tam 16:58 <jrandom> aha jasně 16:58 <+Complication> =to je ono 16:58 <+Complication> Momentálně nemůžu potvrdit, jestli to mainline Phex má nebo ne – osobně jsem to tam neviděl 16:59 <jrandom> (občasné chyby)-- 16:59 <+Complication> Je těžké to vyvolat kontrolovaně, a tím pádem těžké najít 17:00 <+Complication> A z mé strany je to zatím asi vše 17:00 <+Complication> Později jsem přemýšlel, jestli by nestálo za to omezit počet paralelních pokusů o kontaktování peerů, které I2Phex spouští najednou 17:01 <jrandom> jo, asi ano 17:01 <+Complication> Protože by to v krátkém čase vytvořilo spoustu NetDB lookupů a z pohledu I2P routeru by to nemuselo být úplně hezké 17:02 <jrandom> a nové kontakty na destination vyžadují elG místo aes 17:02 <+Complication> Ale zatím jsem kvůli tomu nic nečetl ani nenapsal žádný kód 17:04 <jrandom> k, v pohodě. Možná to zabalí řešení to mýtické sloučení i2phex/phex :) 17:04 <+Complication> A z mé strany to je asi všechno z fronty I2Phex... 17:04 <jrandom> super, díky za aktualizaci a za snahu se v tom vrtat! 17:05 <jrandom> ok, přeskočme k 3) ??? 17:05 <jrandom> má někdo ještě něco k projednání na schůzce? 17:05 <lsmith> ahoj! chtěl bych pochválit vývojáře za skvělé zlepšení v posledním vydání, moje celková šířka pásma ukazuje 0.9/1.4 KB/s a pořád jsem připojený na IRC... je to... šíleně cool :) 17:05 <+Complication> :D 17:06 <jrandom> díky za trpělivost po cestě – podpora uživatelů s nízkou šířkou pásma je zásadní 17:06 <@cervantes> lsmith: to je fakt dobré 17:06 <@cervantes> * Spojení resetováno 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> jo a ještě jedna věc – zzz je zpátky a s ním přichází stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Dost užitečný zdroj srovnávacích dat :) 17:11 <jrandom> jasnačka 17:11 <jrandom> ok, má někdo ještě něco ke schůzi? 17:13 <jrandom> pokud ne... 17:13 <jdot> mám po baf jednu dvě otázky 17:13 <jrandom> heh ok, tak rozjedeme baffer :) 17:13 * jrandom se rozmachuje... 17:13 * jrandom *baf*s schůzi uzavírá