ADSL sávszélesség-gazdálkodás HOGYANDan Singletary dvsing@sonicspike.net Verziótörténet Verzió: 1.3 2003.04.07 Átdolgozta: ds A [1]hivatkozások rész hozzáadása. Verzió: 1.2 2002.09.26 Átdolgozta: ds Az új [2]levelezőlistára mutató hivatkozás hozzáadása. Hozzáadva egy kis fejtörő a fenntartott részhez az új, továbbfejlesztett Linux QoS-hez, amit specifikusan a hamarosan kiadandó ADSL-hez fejlesztettek. Verzió: 1.1 2002.08.26 Átdolgozta: ds Néhány javítás (Köszönet sokaknak, akik felhívták rájuk a figyelmet!). Információs kikötések hozzáadása a megvalósítási részhez. Verzió: 1.0 2002.08.21 Átdolgozta: ds Jobb ellenőrzés a sávszélesség felett, több teória, frissítve a 2.4-es kernelekhez Verzió: 0.1 2001.08.06 Átdolgozta: ds Első kiadás A dokumentum leírja, hogyan állítsunk be egy Linux útválasztót, hogy hathatósabban kezelje a kimenő forgalmat egy ADSL modemen vagy más olyan eszközön, ami hasonló sávszélesség-tulajdonságokkal rendelkezik (kábelmodem, ISDN stb.). Hangsúlyt fektettünk az interaktív forgalom várakozási, lappangási idejének csökkentésére még akkor is, ha a feltöltési és/vagy letöltési sávszélesség teljesen telített. _________________________________________________________________ Tartalomjegyzék 1. [3]Bevezetés 1.1. [4]A dokumentum új verziói 1.2. [5]Levelezőlista 1.3. [6]A felelősség teljes elhárítása 1.4. [7]Szerzői jog és licenc 1.5. [8]Visszajelzések és javítások 1.6. [9]Magyar fordítás 2. [10]Háttér 2.1. [11]Előzetesen szükséges dolgok 2.2. [12]Elrendezés 2.3. [13]Csomagok várakozósorai 3. [14]Hogyan működik? 3.1. [15]A HTB alkalmazása a kimenő forgalom visszafogására 3.2. [16]Prioritásos várakozósor kialakítása HTB-vel 3.3. [17]A kimenő csomagok osztályozása iptables-szel 3.4. [18]Még néhány fogás... 3.5. [19]Próbálkozás a bejövő forgalom visszafogására 4. [20]Megvalósítás 4.1. [21]Kikötések 4.2. [22]Szkript: myshaper 5. [23]Az új várakozósor tesztelése 6. [24]Rendben, működik! Hogyan tovább? 7. [25]Kapcsolódó hivatkozások 1. Bevezetés Jelen dokumentum célja, hogy ajánljon egy módszert egy internethez kapcsolódó ADSL (vagy kábel) modemen kimenő forgalom kezeléséhez. A probléma az, hogy a legtöbb ADSL vonalat lekorlátozták 128kbs vagy e körüli adatfeltöltési sebességre. Még súlyosabbá teszi a problémát a csomagok várakozási sora az ADSL modemen belül, ami ha tele van, 2 vagy 3 másodpercet is igénybe vesz, míg kiürül. Ez együttesen azt jelenti, hogy amikor a feltöltési sávszélesség teljesen telítve van, a többi csomagnak 3 másodpercet is igénybe vehet, amíg kijutnak az Internetre. Ez megbéníthatja az interaktív alkalmazásokat, mint a telnet vagy a többszereplős játékok. _________________________________________________________________ 1.1. A dokumentum új verziói Mindig megtalálod a jelen dokumentum legújabb verzióját a világhálón a [26]http://www.tldp.org webhelyen. Az új verziók ezen kívül különböző Linux WWW és FTP szerverre is fel vannak téve, beleértve az LDP honlapját a [27]http://www.tldp.org webhelyen. _________________________________________________________________ 1.2. Levelezőlista Az ADSL sávszélesség-gazdálkodást illető kérdések és friss információk vonatkozásában kérlek, iratkozz fel a téma levelezési listájára a [28]http://jared.sonicspike.net/mailman/listinfo/adsl-qos honlapon. _________________________________________________________________ 1.3. A felelősség teljes elhárítása Sem a szerző, sem a terjesztők, sem más közreműködő munkatárs nem felelős semmilyen módon a fizikai, pénzügyi, morális vagy bármely más típusú kárért, amit a szövegben ajánlott dolgok követése okozott. _________________________________________________________________ 1.4. Szerzői jog és licenc A jelen dokumentum Dan Singletary (2002) szellemi tulajdona, amelyet a GNU FDL (GNU Szabad Dokumentációs Licenc) alatt adtak ki, amelyet ezennel hivatkozásként beolvasztottunk. _________________________________________________________________ 1.5. Visszajelzések és javítások Ha kérdéseid vagy ajánlásaid vannak a dokumentumhoz kapcsolódóan, nyugodtan lépj kapcsolatba a szerzővel a [29]dvsing@sonicspike.net e-mail címen. _________________________________________________________________ 1.6. Magyar fordítás A magyar fordítást [30]Szíjjártó László készítette (2002.07.28). A lektorálást [31]Daczi László végezte el (2002.09.05). A dokumentum legfrissebb változata megtalálható a [32]Magyar Linux Dokumentációs Projekt honlapján. _________________________________________________________________ 2. Háttér 2.1. Előzetesen szükséges dolgok A dokumentumban vázolt módszernek működnie kell más Linux konfigurációkon belül is, de nem teszteltük máson, csak a következők alatt: * Red Hat Linux 7.3 * 2.4.18-5 Kernel teljes QoS támogatással (modulok: OK) és beleértve a következő kernel-foltokat (amik történetesen az újabbakban benne is lehetnek már): + HTB várakozósor - [33]http://luxik.cdi.cz/~devik/qos/htb/ Megjegyzés jelentették, hogy a 2.4.18-3 kernelverziót követően a Mandrake (8.1, 8.2) már a HTB-hez adott folttal szállítja a rendszert. + IMQ eszköz - [34]http://luxik.cdi.cz/~patrick/imq/ * iptables v1.2.6a vagy későbbi (a Red Hat 7.3-mal szállított iptables verzióból hiányzik a "length" modul) Megjegyzés a dokumentum előző verzióiban olyan sávszélesség-kezelési módszert adtunk meg, ami magában foglalta a meglévő sch_prio várakozósor megfoltozását. Később úgy találtuk, hogy ez a folt teljesen felesleges. Ezen felül a jelen dokumentumban taglalt módszer jobb eredményt ad (bár a doksi írása idején 2 kernelfolt szükséges :) Szerencsés foltozást.) _________________________________________________________________ 2.2. Elrendezés A dolgok egyszerűsítése érdekében, a dokumentumban az összes hálózati eszközre és beállításra vonatkozó hivatkozás a következő hálózati elrendezést tükrözi: <-- 128kbit/s -------------- <-- 10Mbit --> Internet <--------------------> | ADSL modem | <-------------------- 1.5Mbit/s --> -------------- | | eth0 V ---------------------- -------- | | | Linux útválasztó (ro uter) | | | ---------------------- -------- | .. | eth1..ethN | | V V Helyi hálózat _________________________________________________________________ 2.3. Csomagok várakozósorai A csomagok várakozási sorai (queue) olyan "edények", amik az adatokat tárolják a hálózati eszköz számára, amikor azokat nem lehet azonnal elküldeni. A legtöbb várakozósor egy FIFO ("ami elsőnek megy be, elsőnek megy ki") fegyelmezési rendszert, diszciplínát használ (röviden qdisc - a ford.), hacsak speciálisan másra nem állítják be. Ez azt jelenti, hogy amikor egy eszköz várakozósora teljesen tele van, a várakozási sorba utoljára került csomagot csak akkor továbbítja az eszköz, amikor az összes többit már elküldte. _________________________________________________________________ 2.3.1. A kimenő ág ADSL csatlakozás esetén a sávszélesség aszimmetrikus, tipikusan 1.5Mbit/s a bejövő és 128kbit/s a kimenő ág teljesítménye. Bár ez a vonali sebesség, a Linux útválasztó PC és az ADSL modem közötti illesztő tipikusan 10Mbit/s vagy a feletti sebességet tud. Ha a helyi hálózat felé néző csatoló szintén 10Mbit/s sebességű, akkor tipikusan NEM LESZ várakozósor az útválasztónál, amikor a helyi hálózat küld csomagokat az Internet felé. Az eth0 eszközön keresztül olyan sebességgel mennek ki a csomagok, ahogy a helyi hálózatból érkeztek. Ehelyett viszont a csomagok beállnak a sorba az ADSL modemnél, mivel 10Mbit/s-el érkeznek, és csak 128 kbit/s-el mehetnek ki. Időlegesen a csomagok várakozósora a modemnél megtelhet, és minden további csomag, amit küldenek neki, csendben eldobásra kerül. A TCP protokollt úgy tervezték, hogy kezelje ezt, és be fogja állítani a küldési ablak (transmit window) méretét úgy, hogy teljesen kihasználja a rendelkezésre álló sávszélességet. Amíg a várakozósorok a TCP-vel kombinálva a sávszélesség lehető legjobb kihasználását teszik lehetővé, a nagy FIFO sorok megemelik az interaktív forgalom lappangási idejét. Egy másik, a FIFO-ra hasonlító várakozósor az n-sávos prioritásos sor. Ennél ahelyett, hogy csak egy várakozósort alakítanánk ki a bejövő csomagok számára, az n-sávos sornak n darab FIFO sora van, amibe a csomagokat az osztályozásuk alapján helyezzük be. Minden sornak van egy prioritása, és a csomagok mindig a legnagyobb prioritású, csomagokat tartalmazó sorból jönnek ki. Ezt a fegyelmezési szabályt alkalmazva az FTP csomagok egy alacsonyabb prioritású sorba helyezhetők, mint a telnet csomagjai, így még egy FTP feltöltés alatt is, egy darab telnet csomag is kijuthat a sorból és azonnal továbbküldésre kerülhet. A dokumentumot átalakítottuk az új linuxos várakozósor, a Hierarchical Token Bucket (HTB) használatához. A HTB sor nagyban hasonlít a fent leírt n-sávos sorra, de megvan az a tulajdonsága, hogy képes minden osztályának forgalmát korlátozni. Ezen kívül képes arra, hogy forgalmi osztályokat alakítson ki más osztályok alatt, egy hierarchikus osztályokból álló rendszert létrehozva. A HTB teljes leírása meghaladja a dokumentum kereteit, de további információ található a [35]http://www.lartc.org webhelyen. _________________________________________________________________ 2.3.2. A bejövő ág Az ADSL modembe befelé érkező forgalom a kimenőhöz hasonló módon áll várakozósorba, azonban a sor a szolgáltatódnál helyezkedik el. Emiatt valószínűleg nincs közvetlen befolyásod arra, hogyan álljanak sorba a csomagok vagy melyik fajta forgalom kapjon megkülönböztetett kezelést. Az egyetlen mód a várakozási idő alacsonyan tartására itt az, hogy megbizonyosodsz, miszerint nem küldik az adatokat túl gyorsan számodra. Sajnos nincs mód az érkező csomagok sebességének közvetlen befolyásolására, de mivel a forgalmazás többsége valószínűleg TCP, van néhány módja a küldők lelassításának: * Szándékosan eldobni a bejövő csomagokat - a TCP protokollt úgy tervezték, hogy kihasználja a rendelkezésre álló teljes sávszélességet, miközben próbálja elkerülni a kapcsolaton belül a torlódást. Ez azt jelenti, hogy nagy mennyiségű adat küldésekor a TCP több és több adatot küld, amíg végül is egy csomag eldobásra kerül. A TCP érzékeli ezt, és csökkenti az átviteli ablak méretét. Ez a folyamat ismétlődik a kapcsolat alatt, így biztosítja az adatok lehető leggyorsabb átvitelét. * A meghirdetett vételi ablak manipulálása - A TCP forgalmazás alatt a fogadó oldal az ACK (elfogadás) csomagok folyamatos sorát küldi vissza. Az ACK csomagokban található az ablakméret meghirdetése, ami kifejezi annak a nem elfogadott adatnak a mennyiségét, amit a fogadó küldeni tud. A kimenő ACK csomagok ablakméretének babrálásával szándékosan lelassíthatjuk a küldőt. Ennek a folyamatszabályozásnak jelen pillanatban nincs (szabadon elérhető) megvalósítása Linuxon (de lehet, hogy dolgozom egyen!) _________________________________________________________________ 3. Hogyan működik? Két alapvető lépéssel optimalizálhatjuk a kifelé menő sávszélességet. Először találnunk kell egy módot arra, hogy megakadályozzuk az ADSL modemet a csomagok sorba állításában, mivel nincs ráhatásunk a várakozósor kezelésére. Ennek érdekében visszafogjuk az útválasztó által az eth0-n kiküldött adat mennyiségét, kicsit kevesebbre, mint a modem teljes kimenő sávszélessége. Ez azt eredményezi, hogy az útválasztó rakja várakozósorba a helyi hálózatról érkező csomagokat, amik gyorsabban érkeznek, mint megengedett kiküldésük. A második lépés egy prioritásos várakozósor-fegyelmi szabály felállítása az útválasztón. Meg fogunk valósítani egy olyan sort, amit be lehet állítani úgy, hogy elsőbbséget adjon az interaktív forgalomnak, mint a telnet vagy a többszereplős játékok. A HTB várakozósor használatával meg tudjuk valósítani a sávszélesség korlátozását és prioritásos várakozósort, egyidejűleg meggyőződünk, hogy nincs olyan osztály, amit egy másik "kiéheztetne". A kiéheztetés elkerülése érdekében nem választható a dokumentum 0.1-es javításánál megadott módszer. A végső lépés a tűzfal beállítása, hogy az fwmark segítségével biztosítsa a csomagok elsőbbségét. _________________________________________________________________ 3.1. A HTB alkalmazása a kimenő forgalom visszafogására Bár az útválasztó és a modem közti kapcsolat 10 Mbit/s sebességű, a modem csak 128 kbit/s sebességgel tud adatokat küldeni. Minden ezt a rátát meghaladó sebességű csomag várakozósorba áll a modemnél. Ezért egy ping csomag, amit az útválasztóról küldünk, azonnal elmehet a modemhez, de néhány másodpercet vehet igénybe, amíg ténylegesen kikerül az Internetre, ha a modem várakozósora tartalmaz már valamennyi csomagot. Sajnos a legtöbb ADSL modem esetében nem adhatjuk meg a várakozósor kezelésének módját illetve annak nagyságát. Így először a kimenő csomagokat átirányítjuk oda, ahol mindezt megtehetjük. Ezt a HTB sorral valósítjuk meg, így csökkentve az ADSL modemhez küldött csomagok számát. Még ha a kifelé menő sávszélességünk a 128kbit/s is lehetne, kicsivel ez alá korlátozzuk le a csomagküldés mértékét. Ha csökkenteni akarjuk a lappangási időt, BIZONYOSNAK kell lennünk, hogy soha egyetlen csomag sem áll sorba a modemnél. Kísérletezések során azt találtam, hogy a kimenő forgalom körülbelül 90kbit/s-ra való visszavételével a sávszélesség majdnem 95%-át tudom elérni a HTB vezérlés nélkül. A HTB engedélyezésével ennél a mértéknél kivédjük, hogy a modem várakozósorba rakja a csomagokat. _________________________________________________________________ 3.2. Prioritásos várakozósor kialakítása HTB-vel Megjegyzés Megjegyzés: az ebben a részben lévő előző igények (eredetileg N-sávos prioritásos várakozósor kialakításának hívták) később hibásnak találtattak. LEHETETLEN volt a várakozósor különböző sávjaiba tartozó csomagok megjelölése csak a fwmark mező által, viszont ezt gyengén dokumentáltuk a dokumentum 0.1-es verziójának írásakor. Ennél a pontnál még nem veszünk észre semmi változást a teljesítményben. Pusztán csak áthelyezzük a FIFO sort az ADSL modemtől az útválasztóhoz. Valójában, a Linux alapértelmezésben beállított 100 csomag méretű FIFO sorával, valószínűleg még rosszabbá is tettük a helyzetünket! De nem sokáig... Minden szomszédos osztálynak adhatunk egy prioritást a HTB soron belül. A különböző típusú forgalom különböző osztályokba helyezésével, majd ezen osztályokhoz különböző prioritások csatolásával, vezérelhetjük a csomagok várakozási sorból való kivételét és elküldését. A HTB lehetővé teszi ezt, miközben megakadályozza egy osztály "kiéheztetését", mivel megadhatjuk a minimálisan garantált mértéket minden osztály számára. Ezenfelül a HTB megengedi azt is, hogy megadjuk egy osztálynak: használhatja másik osztályok nem használt sávszélességét, egy bizonyos felső határig. Miután beállítottuk az osztályainkat, szűrőket helyezünk el, hogy a forgalmat elhelyezzük beléjük. Több útja is van ennek, de az itt leírt módszer az ismerős iptables/ipchains-t használja a csomagok fwmark-al (tűzfal jelölése a csomagon) történő megjelölésére. A szűrők a csomagok fwmark-ját figyelembe véve helyezik el a forgalmat a HTB sor osztályaiba. Ezen a módon képesek leszünk megfelelő szabályok felállítására az iptables-en belül, hogy bizonyos típusú forgalmat egy bizonyos osztályba küldjön. _________________________________________________________________ 3.3. A kimenő csomagok osztályozása iptables-szel Megjegyzés eredetileg a dokumentumban az ipchains-t használtuk a csomagok besorolására. Most az újabb iptables-t használjuk. Az utolsó lépés ahhoz, hogy az útválasztó elsőbbséget adjon az interaktív forgalomnak - a tűzfal beállítása: adjuk meg a forgalom besorolásának módját. Ez a csomag fwmark mezőjének beállításával érhető el. Anélkül, hogy túlzottan a részletekbe merülnénk, álljon itt az egyszerűsített leírása annak, hogyan lehet a kimenő csomagokat 4 osztályba sorolni úgy, hogy a legmagasabb prioritású lesz a 0x00: 1. Jelöljünk MINDEN csomagot 0x03-al. Ez alapértelmezésben minden csomagot a legalacsonyabb prioritású sorba helyez el. 2. Jelöljük az ICMP csomagokat 0x00-al. Szeretnénk, ha a ping mutatná a legmagasabb prioritású csomagok várakozási idejét. 3. Jelöljünk minden csomagot, aminek célportja 1024 vagy kisebb, 0x01-el. Ez elsőbbséget biztosít az olyan rendszerszolgáltatásoknak, mint a Telnet és SSH. Az FTP portja szintén ebbe a körbe esik, de az FTP adatforgalom a magasabb portokon helyezkedik el és marad a 0x03 sávban. 4. Jelöljünk minden csomagot, aminek a célportja 25 (SMTP), a 0x03-al. Ha valaki levelet fog küldeni egy nagy csatolt állománnyal, nem akarjuk, hogy elárassza az interaktív forgalmat. 5. Jelöljünk minden csomagot, aminek célja egy többszereplős játék-szerver, 0x02-vel. Ez a játékosoknak alacsony lappangási időt biztosít, de megakadályozza, hogy elfoglalják az alacsony várakozást igénylő rendszerszolgáltatásokat. Jelöljünk minden "kicsi" csomagot 0x02-vel. A kimenő ACK csomagokat a befelé irányuló letöltésekből azonnal ki kell küldenünk, hogy biztosítsuk a megfelelő letöltéseket. Ez az iptables "length" moduljával lehetséges. Természetesen ezeket a kívánalmaknak megfelelően átalakíthatod. _________________________________________________________________ 3.4. Még néhány fogás... Két további dolgot tehetsz a lappangási idő javítására. Először is, a maximális átvihető egység (MTU) méretét kisebbre veheted, mint az alapértelmezett 1500 bájt. Ennek a számnak a csökkentése egyben az átlagos időt is csökkenti, amit az elsőbbséget élvező csomagok elküldésére kell fordítani, ha már egy teljes méretű alacsony prioritású csomag küldése folyamatban van. Ennek az értéknek a csökkentése kicsit csökkenti a teljesítményt is, mivel minden csomag legalább 40 bájtnyi IP és TCP fejléc-információt tartalmaz. A másik dolog a javításhoz, még alacsony prioritású forgalom esetén is, hogy csökkented a várakozási sor méretét az alapértelmezett 100-ról, ami egy ADSL vonalon 10 másodperc alatt ürül ki egy 1500 bájtos MTU-t alapul véve. _________________________________________________________________ 3.5. Próbálkozás a bejövő forgalom visszafogására A "közbenső várakozósor-eszköz" (Intermediate Queuing Device, IMQ) használatával az összes bejövő csomagot ugyanúgy egy várakozósoron futtathatjuk át, mint amilyen módon a kimenőket is. A csomagok prioritása ebben az esetben jóval egyszerűbb. Mivel csak a bejövő TCP forgalmat (próbáljuk meg) vezérelni, az összes nem-TCP forgalmat a 0x00 osztályba rakjuk, az összes TCP forgalmat pedig a 0x01 osztályba. A "kis" TCP csomagokat szintén a 0x00 osztályba soroljuk, mert ezek nagy valószínűséggel a már elküldött kimenő adatok ACK csomagjai. Egy standard FIFO sort állítunk be a 0x00 osztályhoz, illetve egy "véletlenszerű korai eldobás" (Random Early Drop, RED) várósort a 0x01 osztályhoz. A RED jobb a FIFO-nál a TCP vezérlését tekintve, mert eldobja a csomagokat már a sor olyan túlcsordulása előtt, mikor megpróbálja lelassítani a forgalmat az ellenőrzés fenntartása érdekében. Ezen kívül mindkét osztályt le fogjuk korlátozni egy maximális bejövő forgalmi határra, ami kisebb, mint a valós, ADSL modemen bejövő sebesség. _________________________________________________________________ 3.5.1. Miért nem olyan jó a bejövő forgalom korlátozása? Korlátozni szeretnénk a bejövő forgalmunkat, hogy elkerüljük a várakozósor betelését a szolgáltatónál, ami néha 5 másodpernyi adat pufferelését jelentheti. A probléma abban áll, hogy jelenleg a bejövő TCP forgalom korlátozásának egyetlen módja a teljesen jó csomagok eldobálása. Ezek a csomagok már foglaltak némi sávszélességet az ADSL modemen, csak a Linux gép dobta el őket abból a célból, hogy a jövőbeni csomagokat lelassítsa. Ezek az eldobott csomagok időnként újra elküldésre kerülnek, még több sávszélességet foglalva. Amikor korlátozzuk a forgalmat, korlátozzuk azon csomagok mértékét, amiket elfogadunk a hálózatunk számára. Mivel az aktuális bejövő adatráta valahol efölött van az eldobott csomagok miatt, a bejövő águnkat sokkal jobban le kell korlátoznunk az ADSL modem aktuális rátájánál, az alacsony lappangási idő biztosítása érdekében. A gyakorlatban az én 1.5Mbit/s bejövő ágamat 700kbit/s-re kellett korlátoznom, hogy elfogadható szinten tartsam a lappangást 5 egyidejű letöltésnél. Minél több TCP folyamatod van, annál több sávszélességet vesztesz az eldobott csomagok miatt, és annál kisebbre kell venned a korlátozás mértékét. A bejövő TCP forgalom ellenőrzésének sokkal jobb módja a TCP ablak manipulációja, de ebben a pillanatban nincs (szabadon elérhető) megvalósítása ennek Linuxra (amennyire én tudom...). _________________________________________________________________ 4. Megvalósítás Mindezen okfejtés után most már ideje, hogy megvalósítsuk a sávszélesség-gazdálkodást Linuxon. _________________________________________________________________ 4.1. Kikötések A DSL modemhez aktuálisan küldött adatok mértékének korlátozása nem olyan egyszerű, mint amilyennek látszik. A legtöbb DSL modem igazából csak egy ethernet híd, amik továbbítják az adatokat oda-vissza a Linux gép és a szolgáltatónál lévő gateway között. A legtöbb DSL modem ATM-et használ adatátviteli csatolófelületként. Az ATM mindig 53 bájtos cellákban küldi az adatokat. Ezekből 5 bájt a fejléc információ, és 48 bájt marad az adatoknak. Még ha csak 1 bájt adatot küldesz is, a teljes 53 bájt sávszélességet foglal, mivel az ATM cellák mindig 53 bájt hosszúak. Ez azt jelenti, hogy ha egy tipikus TCP ACK csomagot küldesz, ami 0 bájt adatot + 20 bájt TCP fejlécet + 20 bájt IP fejlécet + 18 bájt Ethernet fejlécet tartalmaz. Valójában, még ha a kiküldött ethernet csomagnak csak 40 bájtnyi "hasznos terhe" van is (TCP és IP fejléc), a legkisebb méret egy Ethernet csomagnál 46 bájtnyi adat, így a maradék 6 bájt 0-val töltődik ki. Ez azt jelenti, hogy az Ethernet csomag plusz a fejléc információk aktuális hossza 18 + 46 = 64 bájt. Az ATM-mel 64 bájt átküldéséhez két ATM cellát kell küldened, ami 106 bájt sávszélességet foglal. Vagyis minden TCP ACK csomagnál 42 bájt sávszélességet vesztesz. Ez rendben van, ha a Linux figyelembe veszi a DSL modem által használt csomag-beágyazást, de ehelyett a Linux csak a TCP és IP fejlécet és 14 bájtos MAC címet jegyzi (a Linux nem számolja a 4 bájtos CRC-t, mivel ezt a hardver szint kezeli). A Linux nem számol a 46 bájtos minimális Ethernet csomagmérettel, sem a fix méretű ATM cellával. Mindez azt jelenti, hogy a kimenő sávszélességet valamivel kisebbre kell állítani, mint a valós kapacitás (amíg nem találunk egy csomag-időzítőt, ami jegyzi a különböző típusú csomag-beágyazásokat). Azt találhatod, hogy sikerült egy jó értékre beállítani a sávszélességet, de amikor egy nagy fájlt töltesz le, a lappangás felszökik 3 másodperc fölé. Ez legvalószínűbben amiatt van, mivel a Linux rosszul számítja ki a bizonyos kis ACK csomagok által igényelt sávszélességet. Néhány hónapot dolgoztam ennek a problémának a megoldásán, és majdnem lezártam a dolgot egy olyan megoldással, amit hamarosan közreadok további tesztelésre. A megoldás egy felhasználói szintű várakozósor használatát mutatja be a Linux QoS-e helyett a csomagok korlátozására. Alapvetően egy egyszerű HTB sort alkalmaztam, ami a Linux felhasználói szintű sorait használja. Ez a megoldás (eddig) képes volt a kimenő forgalom OLYAN JÓ korlátozására, hogy még egy masszív letöltés (több szálon) és ugyanilyen feltöltés (gnutella, több szálon) alatt is, a lappangás 400 ms CSÚCSÉRTÉKET ért csak el a névleges, forgalom nélküli 15 ms-hoz képest. További információért erről a QoS módszerről, iratkozz fel a frissítések levelezőlistájára vagy később nézd meg ennek a HOGYANnak a frissebb változatait. _________________________________________________________________ 4.2. Szkript: myshaper A következőkben egy általam a Linux útválasztón a sávszélesség korlátozására használt szkript listája található. Ez több, a dokumentumban foglalt koncepciót is felhasznál. A kimenő forgalom a 7 típustól függő várósor egyikébe kerül. A bejövő forgalom két sorba kerül, a TCP csomagokat (alacsonyabb prioritásúak) előbb eldobjuk, ha a bejövő adatok a mérték fölöttiek. A szkriptben megadott ráták úgy tűnik, jól működnek az én beállításomban, de az eredmények változhatnak. A szkript eredetileg az ADSL WonderShaper-en alapult, amint megtalálható a [36]LARTC webhelyen. #!/bin/bash # # myshaper - DSL/kabelmodem kimeno forgalmanak szabalyozasa. # Az ADSL/Cable wondershaper (www.lartc.org) szkripten alapszik. # # Irta: Dan Singletary (8/7/02) # # FIGYELEM: a szkript feltetelezi, hogy a kernelt megfoltoztuk a megfelelo HTB # sor és IMQ foltokkal, amik hozzaferhetok itt (megj.: az ujabb kerneleknel # lehet, hogy nem kell folt): # # http://luxik.cdi.cz/~devik/qos/htb/ # http://luxik.cdi.cz/~patrick/imq/ # # Konfiguracios beallitasok: # DEV - ethX-re allitsuk, ami kapcsolodik a DSL/kabelmodemhez # RATEUP - allitsuk valamivel kisebbre, mint a modem kimeno savszelessege. # Nekem 1500/128 DSL vonalam van, es a RATEUP=90 jol mukodik a # 128 kbps-os feltoltessel. De ahogy jonak latod. # RATEDN - allitsd valamivel kisebbre, mint a bejovo savszelesseg. # # # Teoria az imq hasznalatarol a bejovo forgalom alakitasahoz: # # # BEJOVO TCP KAPCSOLATOK BEFOLYASOLASAT. Ennek ertelmeben minden nem-TC P # forgalmat egy magas prioritasu osztalyba kell sorolnunk, mivel egy nem-TC P # csomag eldobasa valoszinuleg a csomag ujrakuldeset okozza. Ez semmi mast ne m # jelent, csak a savszelesseg szuksegtelen lefoglalasat, hogy specifikusa n # valaszthatunk: NEM dobunk el bizonyos tipusu csomagokat, amiket magasab b # prioritasu tarolokba helyezunk el (ssh, telnet stb). Ez azert van, mert a # csomagok mindig az alacsonyabb prioritasu osztalybol jonnek elo azzal a # kikotessel, hogy a csomagok meg minden osztalybol egyforman egy minimali s # mertekben jonnek ki (ebben a szkriptben minden tarolo legalabb a tisztessege s # 1/7 savszelessegnyivel A TCP csomag eldobasa egy kapcsolaton belul a fogada s # alacsonyabb mertekehez vezet, a torlodas-elkerulo algoritmus miatt. # # * Semmit nem nyerunk a nem-TCP csomagok eldobasaval. Valojaban, h a # fontosak voltak, ugyis ujra elkuldik oket, igy megprobaljuk azt, hog y # sosem dobjuk el oket. Ez azt jelenti, hogy a telitett TCP kapcsolatok ne m # befolyasoljak negativan azokat a protokollokat, amelyeknel nincs a # TCP-hez hasonlo beepitett ujrakuldes. # # * A TCP kapcsolatok lelassitasa ugy, hogy a teljes bejovo rata kevesebb , # mint az eszkoz valos kapacitasa AZT OKOZHATJA, hogy keves vagy egyetle n # csomag sem all varakozosorba a szolgaltatoi oldalon (DSLAM , # kabel-koncentrator stb). Mivel ezek a sorok kepesek megtartani 4 # masodpercnyi adatot 1500Kbps sebessegen vagy 6 megabitnyi adatot, ha eg y # csomag sem all sorba, az alacsonyabb lappangast okoz. # # Kikotesek (kerdesfeltevesek a teszteles elott): # * A bejovo forgalom ezen a modon valo korlatozasa gyenge TCP-teljesítmenyt ad ? # - Az elozetes valsz: nem! Ugy nez ki, hogy az ACK csomagok prioritasana k # beallitasa (kicsi <64b) anelkul maximaljuk a kimeno telesitmenyt, hog y # nem vesztunk savszelesseget a mar meglevo ujrakuldott csomagok miatt . # Megjegyzes: a kovetkezo konfiguracio jol mukodik az en beallitasaimmal: # 1.5M/128K ADSL a Pacific Bell Internet-en keresztul (SBC Global Services) DEV=eth0 RATEUP=90 RATEDN=700 # Figyeld meg, hogy ez jelntosen kisebb mint az 1500-as kapacit as. # Emiatt nem kell a bejovo forgalom korlatozasaval torodnod, a mig # nem hasznalhatunk jobb megvalositast, mint például a TCP ab lak # manipulacioja. # # konfiguracios beallitasok vege # if [ "$1" = "status" ] then echo "[qdisc]" tc -s qdisc show dev $DEV tc -s qdisc show dev imq0 echo "[class]" tc -s class show dev $DEV tc -s class show dev imq0 echo "[filter]" tc -s filter show dev $DEV tc -s filter show dev imq0 echo "[iptables]" iptables -t mangle -L MYSHAPER-OUT -v -x 2> /dev/null iptables -t mangle -L MYSHAPER-IN -v -x 2> /dev/null exit fi # Mindent visszaalitunk alapallapotba (torlunk) tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev imq0 root 2> /dev/null > /dev/null iptables -t mangle -D POSTROUTING -o $DEV -j MYSHAPER-OUT 2> /dev/null > /dev/n ull iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -D PREROUTING -i $DEV -j MYSHAPER-IN 2> /dev/null > /dev/nul l iptables -t mangle -F MYSHAPER-IN 2> /dev/null > /dev/null iptables -t mangle -X MYSHAPER-IN 2> /dev/null > /dev/null ip link set imq0 down 2> /dev/null > /dev/null rmmod imq 2> /dev/null > /dev/null if [ "$1" = "stop" ] then echo "Shaping removed on $DEV." exit fi ########################################################### # # Kimeno korlatozas (a teljes savszelesseg RATEUP-ra allitva) # a varakozosor meretet ugy allitjuk be, hogy kb. 2 mp lappangas legyen az alac sony # prioritasu csomagoknal ip link set dev $DEV qlen 30 # a kimeno eszkozon MTU-t allitunk. Az MTU csokkentese alacsonyabb lappangast # ad, de valamivel kisebb kimeno teljesitmenyt is az IP es TCP protokoll # felulvezerlese miatt ip link set dev $DEV mtu 1000 # a HTB-t gyoker qdisc-nek allitjuk be tc qdisc add dev $DEV root handle 1: htb default 26 # hozzaadjuk a fobb korlatozo osztalyokat tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit # hozzadjuk az alosztalyokat - garantaljuk minden osztalynak LEGALABB a # "tisztesseges" osztozast a savszelessegen. Emiatt egy osztalyt sem fog eg y # masik kieheztetni. Ezenkivul mindegyik osztaly hasznalhatja a rendelkezesr e # allo savszelesseget, ha a tobbi nem hasznalja. tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 0 tc class add dev $DEV parent 1:1 classid 1:21 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 1 tc class add dev $DEV parent 1:1 classid 1:22 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 2 tc class add dev $DEV parent 1:1 classid 1:23 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 3 tc class add dev $DEV parent 1:1 classid 1:24 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 4 tc class add dev $DEV parent 1:1 classid 1:25 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 5 tc class add dev $DEV parent 1:1 classid 1:26 htb rate $[$RATEUP/7]kbit ceil ${ RATEUP}kbit prio 6 # az alosztalyokhoz qdisc-eket adunk - SFQ-t adunk minden osztalyhoz. Az SFQ # biztositja, hogy minden osztalyon belul a kapcsolatokat (majdnem) egyenloen # kezeljuk. tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10 tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10 tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10 tc qdisc add dev $DEV parent 1:24 handle 24: sfq perturb 10 tc qdisc add dev $DEV parent 1:25 handle 25: sfq perturb 10 tc qdisc add dev $DEV parent 1:26 handle 26: sfq perturb 10 # az fwmark-kal szurjuk osztalyokba a forgalmat - itt a csomagon beallitot t # fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot a z # iptables segitsegevel kesobb allitjuk be). Figyeld meg, hogy fentebb a z # alapertelmezett prioritasu osztalyt 1:26-ra allitottuk, igy a nem jelol t # csomagok (vagy a nem ismert ID-ju csomagok) alapertelmezesben az alacsonyab b # prioritasu osztalyba mennek. tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 23 fw flowid 1:23 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 24 fw flowid 1:24 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 25 fw flowid 1:25 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26 # # a MYSHAPER-OUT lanc hozzadasa az iptables "mangle" tablajahoz - ez beallitja # azt a tablat, amit a csomagok szuresehez es megjelolesehez hasznalunk. iptables -t mangle -N MYSHAPER-OUT iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT # a fwmark ertekek beallitasa a kulonbozo tipusu forgalomhoz - a fwmark-ot 2 0-26 # kozottire allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb priori tas. iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 0:1024 -j MARK --set-mark 23 # Alapertek az # alacsony portokon zajlo forgalomhoz iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 0:1024 -j MARK --set-mark 23 # "" iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 20 -j MARK --set-mark 26 # ftp-data port, alacsony prioritas iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 5190 -j MARK --set-mark 23 # aol instant messenger iptables -t mangle -A MYSHAPER-OUT -p icmp -j MARK --set-mark 20 # ICMP (ping) - magas prioritas, baratok ismertetojegye iptables -t mangle -A MYSHAPER-OUT -p udp -j MARK --set-mark 21 # DNS nevfeloldas (kis csomagok) iptables -t mangle -A MYSHAPER-OUT -p tcp --dport ssh -j MARK --set-mark 22 # secure shell iptables -t mangle -A MYSHAPER-OUT -p tcp --sport ssh -j MARK --set-mark 22 # secure shell iptables -t mangle -A MYSHAPER-OUT -p tcp --dport telnet -j MARK --set-mark 22 # telnet (ew...) iptables -t mangle -A MYSHAPER-OUT -p tcp --sport telnet -j MARK --set-mark 22 # telnet (ew...) iptables -t mangle -A MYSHAPER-OUT -p ipv6-crypt -j MARK --set-mark 24 # IPSec - viszont nem tudjuk, mi a "hasznos teher"... iptables -t mangle -A MYSHAPER-OUT -p tcp --sport http -j MARK --set-mark 25 # helyi webszerver iptables -t mangle -A MYSHAPER-OUT -p tcp -m length --length :64 -j MARK --set- mark 21 # kis csomagok (valoszinuleg csak ACK-k) iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26 # redundans- jeloljunk minden nem jelolt csomagot 26-tal (alacsony prioritas) # vegeztunk a kimeno korlatozassal # #################################################### echo "Outbound shaping added to $DEV. Rate: ${RATEUP}Kbit/sec." # tavolitsd el a megjegyzest a kovetkezo sor elol, ha csak kimeno forgalomszaba lyozast akarsz # exit #################################################### # # Bejovo korlatozas (a teljes savszelesseg RATEDN-re allitva) # megnezzuk, hogy az imq modul betoltodott-e modprobe imq numdevs=1 ip link set imq0 up # a qdisc hozzadasa - alapertelmezett alcsony prioritasu 1:21-es osztaly tc qdisc add dev imq0 handle 1: root htb default 21 # a fo korlatozo osztalyok hozzaadasa tc class add dev imq0 parent 1: classid 1:1 htb rate ${RATEDN}kbit # alosztalyok hozzaadasa - TCP forgalom a 21-ben, nem-TCP forgalom a 20-ban # tc class add dev imq0 parent 1:1 classid 1:20 htb rate $[$RATEDN/2]kbit ceil ${ RATEDN}kbit prio 0 tc class add dev imq0 parent 1:1 classid 1:21 htb rate $[$RATEDN/2]kbit ceil ${ RATEDN}kbit prio 1 # az alosztalyokhoz qdisc-eket adunk - SFQ-t adunk minden osztalyhoz. Az SFQ # biztositja, hogy minden osztalyon belul a kapcsolatokat (majdnem) egyenloen # kezeljuk. tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev imq0 parent 1:21 handle 21: red limit 1000000 min 5000 max 100 000 avpkt 1000 burst 50 # az fwmark-kal szurjuk osztalyokba a forgalmat - itt a csomagon beallitot t # fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot a z # iptables segitsegevel kesobb allitjuk be). Figyeld meg, hogy fentebb a z # alapertelmezett prioritasu osztalyt 1:21-re allitottuk, igy a nem jelol t # csomagok (vagy a nem ismert ID-ju csomagok) alapertelmezesben az alacsonyab b # prioritasu osztalyba kerulnek. tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20 tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21 # a MYSHAPER-IN lanc hozzadasa az iptables "mangle" tablajahoz - ez beallitja a zt a tablat, # amit a csomagok szuresehez es megjelolesehez hasznalunk. iptables -t mangle -N MYSHAPER-IN iptables -t mangle -I PREROUTING -i $DEV -j MYSHAPER-IN # a fwmark ertekek beallitasa a kulonbozo tipusu forgalomhoz - a fwmark-ot 20-2 6 kozottire # allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb pr ioritas. iptables -t mangle -A MYSHAPER-IN -p ! tcp -j MARK --set-mark 20 # A nem-tcp csomagokat a legnagyobb prioritasura allitja iptables -t mangle -A MYSHAPER-IN -p tcp -m length --length :64 -j MARK --set-m ark 20 # rovid TCP csomagok, valoszinuleg ACK-k iptables -t mangle -A MYSHAPER-IN -p tcp --dport ssh -j MARK --set-mark 20 # secure shell iptables -t mangle -A MYSHAPER-IN -p tcp --sport ssh -j MARK --set-mark 20 # secure shell iptables -t mangle -A MYSHAPER-IN -p tcp --dport telnet -j MARK --set-mark 20 # telnet (ew...) iptables -t mangle -A MYSHAPER-IN -p tcp --sport telnet -j MARK --set-mark 20 # telnet (ew...) iptables -t mangle -A MYSHAPER-IN -m mark --mark 0 -j MARK --set-mark 21 # redundans- minden nem jelolt csomagot 21-el jelolunk (alacsony priorit as) # vegul utasitjuk ezeket a csomagokat, hogy menjenek keresztul a fent beallitot t imq0-on iptables -t mangle -A MYSHAPER-IN -j IMQ # vegeztunk a bejovo forgalommal # #################################################### echo "Inbound shaping added to $DEV. Rate: ${RATEDN}Kbit/sec." _________________________________________________________________ 5. Az új várakozósor tesztelése A legkönnyebben azzal tesztelheted az új beállítást, hogy telíted a felfelé irányuló ágat alacsony prioritású forgalommal. Ez a prioritások beállításától függ. A példa kedvéért, mondjuk a telnet és a ping forgalmat helyezted magasabb prioritásba (alacsonyabb fwmark), a többi magasabb portot (amik FTP átvitelhez stb. használatosak) pedig alacsonyabba. Ha indítasz egy FTP feltöltést a kifelé menő sávszélesség telítésére, csak a gateway felé (a DSL vonal másik felén lévő) menő ping idők kis mértékű növekedését tapasztalhatod, összehasonlítva a prioritásos várósor nélküli értékekkel. A 100 ms alatti ping idők tipikusak attól függően, hogyan állítottad be a dolgokat. Az egy vagy két másodpercnél nagyobb idők valószínűleg az jelzik, hogy nem működnek rendben a dolgok. _________________________________________________________________ 6. Rendben, működik! Hogyan tovább? Most, hogy sikeresen elkezdtél gazdálkodni a sávszélességeddel, elgondolkodhatsz azon, hogyan használod ki. Végül is, valószínűleg fizetsz érte! * Gnutella kliens használata és FÁJLJAID MEGOSZTÁSA a hálózat teljesítményének kedvezőtlen befolyásolása nélkül. * Web szervert futtathatsz anélkül, hogy a weblapok kiszolgálása lelassítaná a Quake partit. _________________________________________________________________ 7. Kapcsolódó hivatkozások * Bandwidth Controller for Windows - [37]http://www.bandwidthcontroller.com * [38]dsl_qos_queue - (béta) Linuxhoz. Nincs kernel-foltozás, és jobb a teljesítmény. References 1. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#links 2. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#emaillist 3. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#intro 4. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN43 5. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#emaillist 6. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN53 7. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#copyright 8. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN59 9. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN63 10. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#background 11. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN71 12. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN93 13. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN97 14. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#how-it-works 15. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN122 16. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN126 17. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN133 18. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN152 19. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN156 20. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#implementation 21. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN168 22. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN173 23. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#testing 24. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#onward 25. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#links 26. http://www.tldp.org/ 27. http://www.tldp.org/ 28. http://jared.sonicspike.net/mailman/listinfo/adsl-qos 29. mailto:dvsing@sonicspike.net 30. mailto: laca[AT]janus.gimsz.sulinet.hu_NO_SPAM 31. mailto:dacas[AT]freemail.hu_NO_SPAM 32. http://tldp.fsf.hu/index.html 33. http://luxik.cdi.cz/~devik/qos/htb/ 34. http://luxik.cdi.cz/~patrick/imq/ 35. http://www.lartc.org/ 36. http://www.lartc.org/ 37. http://www.bandwidthcontroller.com/ 38. http://www.sonicspike.net/software#dsl_qos_queue