Setkání vývojářů I2P - 22. března 2005

13:01 <@jrandom> 0) ahoj 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) dávkování 13:01 <@jrandom> 3) aktualizace 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) ahoj 13:01 * jrandom mává 13:01 <@jrandom> právě zveřejněné týdenní poznámky o stavu jsou k dispozici na http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> ahoj 13:02 <+cervantes> čau 13:02 <@jrandom> skočme rovnou k 1) 0.5.0.3 13:02 <@jrandom> vydání vyšlo před pár dny a ohlasy jsou pozitivní 13:02 <+cervantes> jrandom: dej vědět, až ti na monitor vylezou modří tancující trpaslíci, a meeting ukončíme dřív 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (díky Bobovi za editovatelné zápisy ze schůzky ;) 13:04 <@jrandom> k 0.5.0.3 nemám moc co dodat nad to, co je v tom mailu 13:04 <@jrandom> máte k tomu nějaké komentáře/dotazy/obavy? 13:04 <bla> jrandom: Nějaká nová měření kódu pro výběr rychlých peerů? 13:05 <@jrandom> aha, věděl jsem, že je v 0.5.0.3 ještě něco, co jsem zanedbal ;) 13:06 <@jrandom> zatím nemám tvrdá čísla, ale podle dojmů fast peer selection našel peery, o kterých vím, že jsou „rychlí“ (např. routery na stejném stroji apod.) 13:07 <bla> jrandom: Někdy eepsites stále vyžadují několik pokusů, než se najde použitelný tunnel 13:07 <@jrandom> občas přišly hlášení o docela slušné propustnosti (v rozsahu 10–20 KB/s), ale není to zatím časté (stále máme parametry přiškrcené) 13:08 <+ant> <Connelly> ups, probíhá meeting 13:09 <@jrandom> hmm, ano, zjistil jsem, že spolehlivost stále není tam, kde má být. Opakovat víc než jednou ale není řešení – když se stránka nenačte ani po jednom opakování, dejte tomu 5–10 min, než to zkusíte znovu 13:09 <@jrandom> co jsem ale na síti viděl, jsou poměrně časté špičky zpoždění v transportní vrstvě 13:10 <@jrandom> např. trvá 5–20+ sekund jen protlačit přes socket zprávu o velikosti 1–2 KB 13:10 <@jrandom> v kombinaci s cestou o 5 hopů (tunnely po 2 hopech) se snadno dostanete do potíží 13:11 <@jrandom> to je vlastně část motivace pro kód dávkování – snížit počet (#) zpráv, které je třeba poslat 13:13 <@jrandom> OK, má ještě někdo dotazy/komentáře/obavy k 0.5.0.3? 13:13 <bla> jrandom: Vypadá to dobře. Zeptám se víc v další „sekci“ 13:14 <@jrandom> w3rd, OK, můžeme se tedy posunout k 2) dávkování 13:15 <@jrandom> email a můj blog (jrandom.dev.i2p</spam>) by měly popsat základy toho, co je plánováno 13:15 <@jrandom> a, no, je to vlastně dost základní věc 13:15 <@jrandom> stávající preprocesor je ten nejjednodušší možný na implementaci (název třídy: TrivialPreprocessor) ;) 13:16 <@jrandom> ten nový má nastavitelné parametry pro frekvenci dávkování a také jistou afinitu k odchozímu tunnelu v rámci jednotlivých poolů tunnelů (kde se snažíme po dobu až např. 500 ms vybírat pro následné požadavky tentýž odchozí tunnel, aby se dávkování optimalizovalo) 13:17 <@jrandom> to je asi vše, co k tomu mám – nějaké dotazy/komentáře/obavy? 13:18 <bla> Vyžaduje to, aby všechny zúčastněné uzly běžely na novém preprocesoru, nebo může koexistovat mix Trivial/NewOne? 13:18 <+Ragnarok> to přidá 0,5 s latence, že? 13:19 <@jrandom> bla: ne, tenhle preprocesor se používá jen na vstupní bráně tunnelu a je na té bráně, jak a zda bude dávkovat 13:20 <@jrandom> Ragnarok: obvykle ne – zpráva č. 1 se může zpozdit až o 0,5 s, ale zprávy 2–15 se přenesou mnohem rychleji, než by se přenesly jinak. Je tam i jednoduchý práh – jakmile je k dispozici objem dat na plnou tunnel message, vypustí se 13:20 <+Ragnarok> super 13:20 <+Ragnarok> kolik režie to ušetří? 13:21 <@jrandom> značně ;) 13:21 <+Ragnarok> značně je fajn, byť neurčitě :P 13:21 <@jrandom> koukni na svůj http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> porovnej to s #tunnel.fullFragments 13:22 <bla> jrandom: Týká se to jen komunikace endpoint->IB-gateway? 13:22 <@jrandom> s dávkováním půjde poměr plných vůči malým nahoru a počet (#) vycpávkových bajtů v malých půjde dolů 13:23 <@jrandom> bla: hmm, týká se to všech brán tunnelů, ať už inbound nebo outbound 13:24 <mihi> plné fragmenty: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: OK 13:24 <mihi> může být počet fragmentů necelý? 13:24 <@jrandom> plné: 1.00 over 807,077.00 events malé: 746.80 over 692,682.00 events 13:25 <@jrandom> heh mihi 13:25 <@jrandom> (to malé: 746 znamená, že u těch 692k zpráv bylo 746 z 996 bajtů vycpávka navíc!) 13:26 <@jrandom> no, ne úplně zbytečná – splnila svůj účel 13:26 <+detonate> každopádně zbytečná režie 13:27 <@jrandom> jo, hodně z toho bychom měli zvládnout odbourat s preprocesorem pro dávkování 13:28 <@jrandom> bohužel to nebude součástí příštího vydání 13:28 <@jrandom> ale bude to v revizi 0.5.0.6 (nebo možná 0.5.1) 13:28 <@jrandom> erm, 0.5.0.5 nebo 0.5.1 13:28 * jrandom má zmatek v číslech 13:29 <bla> jrandom: Proč ne? 13:29 <+cervantes> hašiš a prášky... sakra 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: v 0.5.0.3 (a dřívějších) je bug, kde obsluha fragmentovaných zpráv způsobí, že následující fragmenty v rámci stejné tunnel message jsou zahazovány 13:31 <@jrandom> kdybychom nasadili preprocesor pro dávkování rovnou, měli bychom značný počet ztracených zpráv 13:31 <@jrandom> to ale nevadí, máme v rukávu jiné pěkné věci, takže chystaná 0.5.0.4 nebude úplně nudná ;) 13:31 <bla> jrandom: Aha, tak proto 13:32 <bla> jrandom: Aha, takže proto to musíme udělat až po tom, co bude 0.5.0.4 mainstream.. Chápu. Díky. 13:33 <@jrandom> jo, bylo by fajn, kdyby si s tím obsluha fragmentů poradila – a obecně ano, jen uvolní buffer bajtů příliš brzy a vynuluje následující fragmenty (ups) 13:33 <@jrandom> OK, ještě něco k 2), nebo přejdeme k 3) aktualizace? 13:35 <@jrandom> OK, jak je zmíněno v poznámkách o stavu (a delší dobu probíráno na různých místech), přidáme funkcionalitu pro jednoduché a bezpečné aktualizace, která nevyžaduje, aby koncový uživatel chodil na web, četl mailing list nebo téma v kanálu :) 13:36 <+detonate> super 13:36 <@jrandom> smeghead dal dohromady nějaký kód, který pomůže proces zautomatizovat a zabezpečit, a ve spolupráci s cervantesem ho napojí jak na fire2pe, tak na běžnou routerconsole 13:37 <@jrandom> v mailu je obecný popis toho, co bude k dispozici, a i když většina funguje, pár částí ještě není úplně dořešených 13:37 <@jrandom> na rozdíl od dávkování to v příští revizi dostupné /bude/, i když lidi to moc nevyužijí až do 0.5.0.5 (až přijde čas aktualizovat) 13:39 <+Ragnarok> takže... co je to cool v 5.0.4? 13:42 <@jrandom> s kódem pro aktualizace přijde možnost stahovat oznamovací data, zobrazující např. kousek novinek nahoře v router console. Kromě toho máme v rámci update kódu novou komponentu spolehlivého stahování, která funguje buď přímo, nebo přes eepproxy, cestou opakuje pokusy a navazuje. Možná na tom postavíme i nějaké příbuzné funkce, ale nic neslibuju 13:42 <+Ragnarok> paráda 13:43 <@jrandom> OK, má ještě někdo dotazy/komentáře/obavy k 3) aktualizace? 13:45 <@jrandom> jestli ne, přejdeme k 4) ??? 13:45 <@jrandom> ještě něco, co chce někdo nadnést? Jsem si jistý, že jsem na pár věcí zapomněl 13:45 <+detonate> I2P je známé, že funguje se Sun JVM na OpenBSD 3.7 :) 13:45 <@jrandom> pěkné! 13:47 <bla> Jaký je stav UDP transportu? 13:48 <+detonate> UDP bude ošemetné, myslím, že by bylo lepší ukrást pipelining kód z BT a upravit ho ;) 13:48 <@jrandom> *kašel* 13:49 <@jrandom> nečekám velké potíže, ale práce je tam určitě dost 13:49 <@jrandom> bude zajímavé, jak bude fungovat politika front a omezování šířky pásma pro přijímání do fronty 13:50 <bla> Kdo dělal ty předběžné práce? 13:50 <@jrandom> bla: detonate a mule 13:50 <+detonate> jo... poslední měsíc nebo tak jsem to flákal 13:50 <bla> detonate: Předpokládám, že s tou poznámkou o BT vtipkuješ? 13:51 <+detonate> napůl vážně 13:51 <+detonate> minimálně by se tím dal snížit počet vláken pro transport na polovinu 13:51 * jrandom mrští po detonate kbelík bláta 13:51 <jdot> woohoo. můj router teď běží na mém dedikovaném serveru místo mé POS kabelové přípojky. 13:51 <@jrandom> nice1 jdot 13:52 <@jrandom> v transportní vrstvě si vystačíme se 3–5 vlákny pro veškerou komunikaci se všemi peery 13:52 <bla> detonate: Ale polovina stačit nebude, až se síť zvětší (> pár stovek uzlů) 13:52 <jdot> s 1000GB šířky pásma k dispozici 13:53 <jdot> bohužel j.i2p a chat.i2p budou ještě pár hodin dole, než vše zmigruju 13:53 <duck> detonate: addressbook je taky zastavený? 13:53 <+detonate> jo, je taky zastavený 13:54 <+detonate> jediné, co není zastavené, je monolitické úložiště profilů, to jsem chtěl zprovoznit později dnes 13:54 <@jrandom> w3rd 13:54 <+detonate> pak I2P nebude masivně fragmentovat disk 13:54 <jdot> jrandom: pokud jde o limity šířky pásma, jsou to průměry? 13:54 <+frosk> moderní filesystémy nefragmentují, ty hlavo 13:55 <+detonate> NTFS ano 13:55 <@jrandom> jdot: limity šířky pásma jsou striktní zásobníky žetonů 13:55 <@jrandom> jdot: když nastavíš délku burstu, to je období, přes které se to zprůměrovává 13:56 <@jrandom> (no, 2× burst == perioda) 13:56 <@jrandom> ((plus minus)) 13:56 <jdot> hmmm... mám 1000 GB a chci, aby si I2P mohlo vzít až 800 GB/měsíc.... 13:56 <+ant> <mihi> detonate: ntfs ukládá opravdu malé soubory do mft, což znamená skoro žádnou fragmentaci 13:57 <jdot> a je mi jedno, na kolik to burstuje 13:57 <+detonate> no, když spustíš defragmentaci, stráví 10 minut přesouváním všech 6000 profilů... takže se to asi fragmentuje 13:58 <@jrandom> jdot: hmm, 800 GB je nejspíš víc, než to vůbec bude chtít protlačit, takže asi můžeš jet bez limitů ;) 13:58 <@jrandom> na druhou stranu, kdybys popsal politiku, kterou chceš implementovat, možná ji zvládneme 13:58 <jdot> jrandom: zatím to tak nechám a uvidím, jak to funguje 13:58 <bla> detonate: NTFS je, pokud si dobře pamatuji, žurnálovací FS. Takže i monolitický soubor se roztříští, když do něj zapisuješ malé kousky 13:58 <+detonate> všechno se zapisuje najednou 13:59 <+detonate> a čte najednou 13:59 <bla> detonate: OK. Chápu. 13:59 <jdot> jrandom: no, počkejme, jestli to vůbec bude problém. 13:59 <bla> detonate: v tom případě dobrá práce! 13:59 <+detonate> zajímalo by mě, jak velké bude využití, když to necháš neomezené 14:00 <+detonate> na dobrém připojení 14:00 <jdot> mě taky! 14:00 <@jrandom> moje routery v colu běží bez limitů, ale jsou omezené CPU 14:00 <+Ragnarok> můžeš použít bitbucket, aby se to průměrovalo přes měsíc? 14:00 <jdot> jrandom: omezené CPU? Jaké CPU? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> hmm, čekal jsem méně 14:01 <@jrandom> jdot: omezené CPU, protože na něm běží 3 routery, plus pár dalších JVM, někdy s profilováním 14:01 <+detonate> to budou ti BT lidi 14:01 <+detonate> až poběží dávkování, bude zajímavé vidět, jak se to změní 14:02 <@jrandom> detonate: část toho transferu je i to, že si mezi sebou posílám 50MB soubory ;) 14:02 <+detonate> heh 14:02 <jdot> ahh. OK. Uvidíme, jak si tenhle systém povede. Je to AMD XP 2400 s 512 MB a 10Mbit připojením 14:02 <@jrandom> Ragnarok: zásobníky žetonů takhle úplně nefungují 14:02 <@jrandom> jdot: jasně, jo, tohle je p4 1.6, pokud si dobře pamatuju 14:03 <@jrandom> Ragnarok: v zásobníku žetonů každou (např.) sekundu přidáš podle rychlosti nějaké žetony. Pokud je zásobník plný (velikost = období burstu), žetony se zahodí 14:04 <@jrandom> kdykoli chceš přenést data, potřebuješ mít dostatečné množství žetonů 14:04 <@jrandom> (1 žeton = 1 bajt) 14:04 <+Ragnarok> vím, jak fungují... co se stane, když prostě uděláš zásobník hodně velký? 14:05 <+detonate> pak nikdy nepřestaneš posílat data 14:05 <+detonate> pokud je nekonečně velký 14:05 <+detonate> eh, a je naplněný žetony 14:05 <@jrandom> když je opravdu velký, po období nízkého využití se to může rozjet a burstovat na neomezené rychlosti 14:06 <@jrandom> i když to v některých případech může být žádoucí 14:07 <@jrandom> jde o to, že nemůžeš prostě nastavit zásobník žetonů na 800 GB, protože by to neomezilo celkové přenesené množství 14:08 <+detonate> potřebuješ tam pole, kde nastavíš počet žetonů za sekundu, pak můžeš prostě vydělit měsíční využití šířky pásma počtem sekund 14:08 <+detonate> :) 14:10 <@jrandom> to je totéž jako nastavit rychlost průměrovanou přes měsíc, což by bylo nevyvážené. Každopádně existuje spousta scénářů – pokud má někdo takový, který jeho potřeby s tím, co je k dispozici, nepokrývá, prosím, ozvěte se 14:10 <+Ragnarok> ale když nastavíš rychlost na průměr, který chceš... myslím tady 308 kB/s, a pak nastavíš bitbucket na něco hodně velkého... proč to nefunguje? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> no, můžeš to nastavit tak, aby to nikdy neposlalo víc než 800 GB/44000 v 60sekundovém období burstu 14:12 <+detonate> 44000 je zhruba počet minut v měsíci 14:13 <@jrandom> velikost zásobníku/doba burstu určuje, kolik pošleme bez omezení, a většina lidí omezení /chce/, aby router nenasál 10 Mb/s na 5 minut při vyprazdňování zásobníku (nebo tak něco) 14:14 <@jrandom> je možné i další škrcení žetonů vytékajících ze zásobníku (a má mít to škrcení svůj vlastní zásobník žetonů, a ten zásobník své vlastní škrcení atd.) 14:16 <+Ragnarok> myslel jsem, že se do zásobníku přidává jen tehdy, když se nevyužívá šířka pásma 14:16 <@jrandom> žetony se do zásobníku přidávají konstantní rychlostí (např. 64k žetonů za sekundu) 14:17 <@jrandom> cokoli, co chce šířku pásma, si vždy žádá zásobník 14:18 <+Ragnarok> aha.. OK 14:19 <@jrandom> OK, super, má ještě někdo něco, co chce na meetingu otevřít? 14:21 <@jrandom> OK, jestli ne 14:21 * jrandom se připravuje 14:21 * jrandom *baf* uzavírá meeting