SPYFF blogja

Még tavaly év végén volt egy kis workshop [1] buffer méretezés témában a Stanford Egyetemen. Minden előadó próbálta kicsit más szemszögből bemutatni, milyen hálózati paramétereket kell figyelembe venni mikor a routerek buffereit méretezik. A helyzet az, hogy a bufferek méretei nagyban befolyásolják, hogy milyen lesz a hálózati kapacitás kihasználtsága, meg mennyire lesznek egymással igazságosak a TCP folyamok. Az sem utolsó szempont, mekkora késleltetést szenvednek majd a sorban várakozással a csomagok. Ez egy leterhelt routerben a tényleges körülfordulási idő (TCP csomag, majd rá visszaérkező nyugta) az az RTT többszöröse is lehet. Meg még van egy csomó aspektusa a témának és bármilyen meglepő még napjainkban is lehet érdekes eredményeket kihozni belőle. A továbbiakban röviden ismertetném néhány mérésünk eredményét, aztán pedig a mérések technikai részleteit és pár jótanácsot ha valaki hasonló mérésekre szánja el magát.

A Linux TCP stack nagyjából 80000 sor kód és nagyobb változtatások elég ritkán érik. Most viszont hosszú idő óta a legnagyobb (kb. 4000 sor) pull request jött, ami az MPTCP-t tartalmazza: https://patchwork.ozlabs.org/cover/1117531/. Két éve írtam már itt a protokollról: https://hup.hu/node/155046 [lentebb még pár infó...]

Röviden arról van szó, hogy több hálózati kártya esetén csinál több TCP subflow-ot és ezeken képes egyszerre forgalmazni. Applikációkat nem szükséges módosítani, sima TCP socket alatt a kernel elvégzi az adatok felosztását subflowok között, jó esetben a felhasználó csak azt látja, hogy gyorsabb az átvitel. Az első verzió 2009 környékén készült el, ezt fejlesztették utána, igaz cserélődtek is az emberek. Ez egy eléggé széthekkelt verzió (jelenleg is fejlesztik, feature complete de túl sok dolgot módosít a kernelen ahhoz hogy mergelhető lehessen, 0.94 verziónév alatt található meg a neten). Ettől függetlenül az eredeti fejlesztők és pár Inteles mérnök elkezdtek egy elegánsabb verziót fejleszteni, ami szinkronban van a net-next tree-vel és csak a core funkciókat tartalmazza. Ez az utóbbi 3 év terméke, mostra jutott olyan állapotba, hogy mint RFC patchset be tudták küldeni. Stabil kernelben nem tudom mikorra kerül be, szerintem kell még neki nagyjából fél év. Akit érdekel a dolog addig persze ki tudja próbálni, az MPTCP kernel tree gitje elérhető.

A netdev (https://www.netdevconf.org/) egy szakmai konferencia, ahol a Linux kernel hálózati moduljaival kapcsolatos előadások, workshopok és tutorialok vannak. Bárki küldhet be saját előadást, ezt aztán egy szakmai bizottság (aktív commitolói a network stacknek) bírálja és fogadja- vagy utasítja el. Linuxra fejlesztő cégek is bemutatják a legfrissebb munkáikat, nem egyszer a konferenciára időzítve küldik be a patchsetet a bemutatott eredményekről. A továbbiakban egy élménybeszámoló következik a konferenciáról (főleg a szakmai dolgokra koncentrálva).

A konferencia teljes programja itt található: https://www.netdevconf.org/0x13/schedule.html

Idén január közepétől május végéig volt szerencsém szétnézni az IBM Zürichi kutatólaboratóriumában. Egy itteni, HUP-os blogposztomat látta meg NagyZ és ajánlotta fel ezt a lehetőséget, én pedig éltem vele. Lentebb pár személyes élmény és az IBM-nél szerzett tapasztalataim leírása következik.

Néhány levélváltás és telefonos egyeztetés után megkaptam a szerződést, aláírtam, scannelve visszaküldtem, ezek után jött meg csomagban az érvényes szerződés egy másolata. Ez azért volt nagyon fontos, mert később már Svájcban minden hivatalos ügyintézésnél tudtam rá hivatkozni: vízum igénylésnél, bankszámla létrehozásnál, lakhely bejelentésnél, egészségbiztosítás megkötésekor, stb.
Az IBM kutatólaborja Zürich kanton Rüschlikon városában van, sikerült itt albérletet találnom, így 10 perc sétára voltam csak tőle. Egyébként ez egy kis város, nagyjából 5000 fős, így túl sok dolog nincs itt, viszont Zürich nagyjából fél órányira van busszal vagy vonattal így ez nem jelent semmilyen problémát. Első látásra a hely olyasmi, mint egy nagy autószalon, új autók mindenfelé, sétáló embereket nem is nagyon látni, aki csak tud Volvo XC90-ben, M5 BMW-ben vagy Porschéban ül. Aki sétálni vagy futni akar annak egyébként is ott az erdő a város szélén, nekem nagyjából 5 perc sétára volt így elég sokat futottam benne.
A svájciakkal kapcsolatos sztereotípiákat én is meg tudom erősíteni. Legtömörebben (lehet egyben leghülyébben is) úgy tudnám leírni az egészet, hogy kevésbé jellemző az emberekre az entrópia felesleges növelése. A hivatalos ügyekben nem tapasztaltam túlszabályozást, ahogy fentebb írtam, a szerződéssel nyíltak a kapuk, pár telefonnal és minimális személyes megjelenéssel mindent el tudtam intézni, sokszor ímélben elküldött scannelt dokumentum is elég volt. Nagyjából ennyi amit egyelőre meg tudok említeni, ha bármi eszembe jut majd bővítem a posztot.

Videón a végeredmény: https://www.youtube.com/embed/1xQQuT9BGuI
Akit érdekel a projekt, lentebb megtalálja a részleteket.

A Google Summer of Code egy kis program olyan diákoknak, akik valami open source vagy free software projektbe való besegítéssel szeretnék tölteni a nyarat. Röviden annyi történik, hogy tetszőleges projektek képviselői megírják a projekt ötleteiket a GSoC szervezésének, azok kiválogatják a legjobbakat (vagy inkább legszimpatikusabbakat) amiket támogatni tudnak nyáron. Ezeket meghirdetik a projekt oldalán, majd várják rájuk a jelentkezéseket, kisebb önéletrajzzal, motivációs levéllel. Idén nyáron én is részt vettem benne, ebben a blog bejegyzésben igyekszem nem túl személyes hangvétellel ismertetni a projekt lényegét, fontosabb részeit és eredményét. Röviden: a végberendezések számára transzparens, több hálózati útvonal kapacitását MPTCP segítségével kihasználó proxy, OpenWRT/LEDE környezetben implementálva.

Kiindulási alap: van kép program, amik TCP-n kommunikálnak egymással. Mindjárt egyszerre két streamen is, egyik csak küldésre, másik csak fogadásra használt.
Cél: Kipróbálni, hogyan viselkednek, ha a tényleges Wi-Fi/LTE hálózaton már nem TCP-n, hanem UDP-n mennének, a kód fix, nem lehet átírni
Kisebb csavar: a két stream egyszerűség kedvéért legyen egy duplex UDP kapcsolatként jelen. Persze nem ugyan az a helyi TCP küldő mint aki a fogadó
(folyt. köv.)

Jó eséllyel meg lehet oldani a problémát például egy apró C programmal, egyszerűbbnek gondoltam netcat-el. Aztán kis idő múlva beláttam, hogy mégis bölcsebb lett volna C-ben vagy Pythonban megcsinálni, de ekkor már bosszantott, hogy nincs erre egy soros kész megoldás. Lehet az bármi, lehetőleg azért egyszerűbb mint netfilter/iptables ruleok hozzáadása (nem kétség, hogy aki ért hozzá annak azok lesznek egyszerűbbek).

PC vásárlást időzítettem erre az időszakra, kezd kevés lenni a 4 éves laptopom i3-as procija már egy kényelmes böngészéshez is. Bár nem fűztem túl nagy reményeket ahhoz, hogy ez kedvez a PC vásárláshoz, volt pár kellemes meglepetés, de be akadt jó néhány pofátlanság is.

emag-on láttam egy egész jó Corsair tápot, 550W, 20 ezerről 14-re akciózva. Egész jó ajánlatnak tűnt, míg meg nem láttam, hogy árukeresőben 16-17k környékén már lehet kapni ezt... Ugyan itt billentyűzeteket néztem, 4 ezret szántam rá, de az alatt csak a halálgagyi és a tipikus kínai gaymer kategória van, ahol színes a WASD +1-2 multimédia gomb. Végül egy pofás kis gépházat azért sikerült vennem (személyes átvétel nem játszik vidéken, így örültem az ingyen szállításnak). 7000 forintról 6000-re volt leakciózva, ami nem sok de még kevesebb ha az árukeresős 6300-as ajánlatot nézzük, viszont ott még lett volna szállítási díj tehát modhatjuk jól jártam. A többi ajánlaton végignézve viszont PC kategóriában, szinte tisztán eladhatatlan kacatok voltak csak, és azok sem olyan vastag akciókkal.

Éééés így történt, hogy 200 gigásak lettek a játékok és 32 Gb VRAM alatt már meg sem jelenik semmi a képernyőn :-)

https://www.youtube.com/watch?v=CjQbd5TQ9jc

https://youtu.be/BnSekpFSLnU