Já nemohu souhlasit s "QoS je značkování jednotlivých paketů. Nic jiného."
Naopak - jak ostatně p. Soukup sám uvedl, je to jen jedna z mnoha cest a navíc jí NIKDO nerespektuje, protože by jí např. někdo okamžitě zneužil a svým paketům nastavil max. prioritu. Takže doufat, že všechny směrovače na cestě budou DSCP podporovat je holý nesmysl.
Co naopak jako jediné použitelné je, je prioritizace v bufferu - a tedy zahazování paketů, což u TCP vyvolá odezvu snížením toku.
Kupříkladu můj Huawei obsahuje kromě nastavování DSCP (na nic) i práci s frontami - viz
http://en.wikipedia.org/wiki/Weighted_fair_queuing
http://en.wikipedia.org/wiki/Weighted_round_robin
Ještě pozn. k p. Soukupovi: " Pokud váš router občas schválně zahodí nějaký stahovaný ne VoIP paket, docílí tím snížení rychlosti stahování a tím zmenší celkové zatížení download linky.."
Ano - to by bylo hezké, ale znáte snad nějaká router/ADSL, který by něco takového umožňoval ?
Tedy umožňoval preventivní, aniž by ho k tomu nutil plný buffer, zahazování paketů za účelem snížení dat. toku ?
Jak jsem uvedl - download je vždy do rychla (WAN->LAN) - takže o nějakém zahazování či vlivu nastavení QoS pro směr download (pokud to vůbec nastavovat lze) nemůže být řeč.
Jak (ne)funguje QoS ?
Re: Jak (ne)funguje QoS ?
V SOHO zařízeních udělal každý výrobce z QoS pouze atrapu v podobě (více či méně zvládnutého) řízení datových toků. Skutečné QoS se dá najít akorát na kabelovkách typu UPC, kde má telefon opravdu přednost před tím ostatním a celá síť je takto stavěná. U O2 a jejich VoIP tomu asi bude stejně.
Re: Jak (ne)funguje QoS ?
Já jen trošku přispěju mojí zkušeností i když to neni u plně o QOS, ale problém u nás byl vyřešený.
Přešli jsme od jednoho poskytovatele k druhému, protože už to připojení bylo čímdál horší a mělo i výpadky a navíc ten druhý byl připojený optikou. My sme připojení bezdrátem k té optice. To nové připojení bylo, ale hrozné a byli hrozné ztráty pingu. Poskytovatel ale furt nějak nechápal o co mi jde, že u něho to na grafech vypadá v normálu a že ta ztrátovost je vytěžováním linky. Tak hrozně se to připojení ještě nikdy u žádného providera nechovalo a když jo, tak to byl vždycky v něčem problém. VoIP taky nešel provozovat pokud se stahovalo na max.. Chtěl jsem ať mi teda nastaví QOS nebo něco a byl jsem přesvědčený, že mají oni něco spatně. Co mají špatně jsem se nedozvěděl, ale pomohla taková zajímavá věc. Omezil nám rychlost na našem routeru místo na jejich AP a hned byl internet uplně vpohodě, jak jsem byl zvyklý. Teď už můžu mít zaplý klidně torrent a stahovat a odesílat na max přitom stahovat a odesílat přes http do toho sledovat klidně 4 videa ve fullHD z youtubu a volání přes voip a pingy jsou vpohodě.
Problém byl podle mě v přetíženém nebo špatně nastaveném routeru providera a závěr je podle mě takový, že prostě TCP/IP protokol je navržený tak, aby si stím vším vpohodě poradil (když mu teda někdo nějkým blbým nastavením neháže klacky pod nohy).
Přešli jsme od jednoho poskytovatele k druhému, protože už to připojení bylo čímdál horší a mělo i výpadky a navíc ten druhý byl připojený optikou. My sme připojení bezdrátem k té optice. To nové připojení bylo, ale hrozné a byli hrozné ztráty pingu. Poskytovatel ale furt nějak nechápal o co mi jde, že u něho to na grafech vypadá v normálu a že ta ztrátovost je vytěžováním linky. Tak hrozně se to připojení ještě nikdy u žádného providera nechovalo a když jo, tak to byl vždycky v něčem problém. VoIP taky nešel provozovat pokud se stahovalo na max.. Chtěl jsem ať mi teda nastaví QOS nebo něco a byl jsem přesvědčený, že mají oni něco spatně. Co mají špatně jsem se nedozvěděl, ale pomohla taková zajímavá věc. Omezil nám rychlost na našem routeru místo na jejich AP a hned byl internet uplně vpohodě, jak jsem byl zvyklý. Teď už můžu mít zaplý klidně torrent a stahovat a odesílat na max přitom stahovat a odesílat přes http do toho sledovat klidně 4 videa ve fullHD z youtubu a volání přes voip a pingy jsou vpohodě.
Problém byl podle mě v přetíženém nebo špatně nastaveném routeru providera a závěr je podle mě takový, že prostě TCP/IP protokol je navržený tak, aby si stím vším vpohodě poradil (když mu teda někdo nějkým blbým nastavením neháže klacky pod nohy).
-
xsouku04
- Administrátor
- Příspěvky: 8160
- Registrován: pát 15. říj 2010 11:11:44
- Bydliště: Brno
- Kontaktovat uživatele:
Re: Jak (ne)funguje QoS ?
Které pakety začít zahazovat jako první, když dochází k přetížení linky a na jakém místě je celá věda. Určitě je lepší je začít zahazovat nějak plánovaně, aby se "jen snížila" rychlost než to neřešit a počkat si, který že se to někde ztratí sám.
Bohužel i takoví velcí poskytovatelé internetu jako Poda to mají někdy velmi nevhodně nastaveno, takže k zahlcení linky dojde snadno. Mluvím nyní o naší pobočce v Brně před přestěhováním. Může tedy být lepší přiškrcovat se sám a dobrovolně, než to nechat dělat vašeho poskytovatele internetu nevhodným způsobem. Pro Linux toho můžete dosáhnout třeba pomocí stařičkého wondershaper skriptu http://lartc.org/wondershaper/ . Ten nedělá nic jiného než pomocí vhodných bash příkazů nastaví umělé omezení rychlosti pro příslušnou síťovou kartu. S Windows nemám zkušenost, ale předpokládám, že to tak jednoduché nebude.
Naštěstí Linux se používá často i v routerech, tudíž je tato možnost poměrně běžná, navíc do části routerů je možné nahrát svobodný software založený na Linuxu a tam jsou možnosti opravdu pestré.
Jinými slovy wondershaper a podobné mechanizmy fungují tak, že si zjistíte jakou máte k dispozici rychlost a nastavíte se o něco málo nižší rychlost. Omezení rychlosti je pak u vás a ne u vašeho poskytovatele internetu, který to může dělat ne zrovna dobrým způsobem. Nevím přesně jak wondershaper funguje, ale může např. dělat to, že menší pakety mají přednost před většíma a pod, menší toky před většíma a pod. Tedy VoIP projde OK, za cenu toho, že se stahování velkých souborů nepatrně zpomalí a to především jen když je to nutné.
A/VDSL modem má přesnou představu jakou máte k dispozici rychlost, dokonce má představu o tom, jak kvalitní dráty jsou mezi vámi a O2 ústřednou,takže by takové věci mohl dělat zcela automaticky. Jen je na chytrosti/hlouposti výrobce, jestli se s tím obtěžuje nebo nikoli. Mějte na paměti, že kvalita internetu může zlobit, protože je váš DSL modem prostě celkově přetížen a nestíhá. Nestíhá mu procesor. V tom případě jakákoli chytrá strategie přestává fungovat. Výrobci takových zařízení, zdá se, obecně moc chytrosti nepobrali. A to je to s čím zde bojujeme především.
Bohužel i takoví velcí poskytovatelé internetu jako Poda to mají někdy velmi nevhodně nastaveno, takže k zahlcení linky dojde snadno. Mluvím nyní o naší pobočce v Brně před přestěhováním. Může tedy být lepší přiškrcovat se sám a dobrovolně, než to nechat dělat vašeho poskytovatele internetu nevhodným způsobem. Pro Linux toho můžete dosáhnout třeba pomocí stařičkého wondershaper skriptu http://lartc.org/wondershaper/ . Ten nedělá nic jiného než pomocí vhodných bash příkazů nastaví umělé omezení rychlosti pro příslušnou síťovou kartu. S Windows nemám zkušenost, ale předpokládám, že to tak jednoduché nebude.
Naštěstí Linux se používá často i v routerech, tudíž je tato možnost poměrně běžná, navíc do části routerů je možné nahrát svobodný software založený na Linuxu a tam jsou možnosti opravdu pestré.
Jinými slovy wondershaper a podobné mechanizmy fungují tak, že si zjistíte jakou máte k dispozici rychlost a nastavíte se o něco málo nižší rychlost. Omezení rychlosti je pak u vás a ne u vašeho poskytovatele internetu, který to může dělat ne zrovna dobrým způsobem. Nevím přesně jak wondershaper funguje, ale může např. dělat to, že menší pakety mají přednost před většíma a pod, menší toky před většíma a pod. Tedy VoIP projde OK, za cenu toho, že se stahování velkých souborů nepatrně zpomalí a to především jen když je to nutné.
A/VDSL modem má přesnou představu jakou máte k dispozici rychlost, dokonce má představu o tom, jak kvalitní dráty jsou mezi vámi a O2 ústřednou,takže by takové věci mohl dělat zcela automaticky. Jen je na chytrosti/hlouposti výrobce, jestli se s tím obtěžuje nebo nikoli. Mějte na paměti, že kvalita internetu může zlobit, protože je váš DSL modem prostě celkově přetížen a nestíhá. Nestíhá mu procesor. V tom případě jakákoli chytrá strategie přestává fungovat. Výrobci takových zařízení, zdá se, obecně moc chytrosti nepobrali. A to je to s čím zde bojujeme především.
Re: Jak (ne)funguje QoS ?
Kromě Huawei mám i Zyxel, který jsem dostal o T-mobile k ADSL smlouvě.
Jde zjevně o zjednodušenou obdobu nastavené Huawei.
Výhodou naopak je poměrně podrobný popis v úplném manuálu - myslím, že by zájemcům o toto téma mohl stát za shlédnutí:
ftp://ftp.zyxel.com/P-660HN-T1A/user_gu ... 40_ed2.pdf
Přednastavené nastavení (od T-mobile ?) pro SIP je následující:
http://www.2i.cz/dec685af7c
Poznámky:
- ač jednoznačně nevyřčeno, lze z textu soudit, že se nastavení QoS týká toliko upload směru
- text (s.177) obsahuje tabulku přednastavených reakcí směrovače - není-li uživ. pravidly změněno. ZyXEL má celkem 7 prioritních front (nicméně v pravidlech jen 4?!) kam rámce dle nastavení QoS na linkové/síťové vrstvě či dle velikosti sám umisťuje.
- návod žel neudává, jak jsou pravidla vyhodnocována, je-li jich pro paket použitelných více. Nicméně z přednastavení pro SIP by se dalo usuzovat, že se použije POSLEDNÍ (dle indexu) uplatnitelné pravidlo. Použití nejspecifičtějšího (jako je to např. u směrování) takřka vylučuji, neboť by se těžko určovalo, co paket více specifikuje (zda např. IP, port(y), MAC, původní QoS, 802.1p, ...)
Jde zjevně o zjednodušenou obdobu nastavené Huawei.
Výhodou naopak je poměrně podrobný popis v úplném manuálu - myslím, že by zájemcům o toto téma mohl stát za shlédnutí:
ftp://ftp.zyxel.com/P-660HN-T1A/user_gu ... 40_ed2.pdf
Přednastavené nastavení (od T-mobile ?) pro SIP je následující:
http://www.2i.cz/dec685af7c
Poznámky:
- ač jednoznačně nevyřčeno, lze z textu soudit, že se nastavení QoS týká toliko upload směru
- text (s.177) obsahuje tabulku přednastavených reakcí směrovače - není-li uživ. pravidly změněno. ZyXEL má celkem 7 prioritních front (nicméně v pravidlech jen 4?!) kam rámce dle nastavení QoS na linkové/síťové vrstvě či dle velikosti sám umisťuje.
- návod žel neudává, jak jsou pravidla vyhodnocována, je-li jich pro paket použitelných více. Nicméně z přednastavení pro SIP by se dalo usuzovat, že se použije POSLEDNÍ (dle indexu) uplatnitelné pravidlo. Použití nejspecifičtějšího (jako je to např. u směrování) takřka vylučuji, neboť by se těžko určovalo, co paket více specifikuje (zda např. IP, port(y), MAC, původní QoS, 802.1p, ...)
Re: Jak (ne)funguje QoS ?
Učinil jsem pár pokusů:
- zatížený download: VoIP funguje překvapivě dobře - bez rozdílu zda QoS ano/ne. Vzhledem k dříve učiněným závěrům se
a/ nedivím nulovému vlivu QoS
b/ divím kvalitě VoIP nezasažené zahazováním paketů, které přitom MUSÍ probíhat (<= Internet->modem je dopomala)
Jediné vysvětlení, co mě napadá je, že O2 router (před/na DSLAMu) QoS má a bez mého přičinění SIP/RTP prioritizuje.
- zatížený upload. Tak zde se QoS projeví zásadně. Jak jsem uvedl, Huawei (oproti ZyXELu) nabízí vice QoS disciplín:
Strict Priority/WFQ/WRR
Ta Strict Priority znamená, že pakety z vyšších front mají striktní přednost před těmi z nižších (HH>High>Medium>Low).
Ty zbylé 2 disciplíny jsou vážené - viz Google.
Používám tu defaultní = Strict Priority.
Mám pravidlo na dest. IP 81.31.45.0/24 (== Odorik)
Výsledek:
a/ pokud tyto rámce přiřadím do fronty Low nebo Medium - na hovor mohu zapomenout.
b/ pokud použiji High nebo dokonce Highest (HH), tak jde i při 100% uploadu bez zakoktnutí
=> standardní priorita pro pakety, na než není pravidlo bude asi někde mezi Medium a High.
Ještě zkusím prozkoušet použití pravidla pro "ostatní" provoz (jako to má pro VoIP ten ZyXEL). Když jsem ho dal na 1. místo a dal mu Low, Tak VoIP běžel. Když jsem mu dal Medium a tomu VoIP Low ( ve 2.pravidle) tak VoIP také běžel - tak nevím.
Problém je v tom, že nevím, jak jsou pravidla vyhodnocována: pořadí, specifičnost, ...
- zatížený download: VoIP funguje překvapivě dobře - bez rozdílu zda QoS ano/ne. Vzhledem k dříve učiněným závěrům se
a/ nedivím nulovému vlivu QoS
b/ divím kvalitě VoIP nezasažené zahazováním paketů, které přitom MUSÍ probíhat (<= Internet->modem je dopomala)
Jediné vysvětlení, co mě napadá je, že O2 router (před/na DSLAMu) QoS má a bez mého přičinění SIP/RTP prioritizuje.
- zatížený upload. Tak zde se QoS projeví zásadně. Jak jsem uvedl, Huawei (oproti ZyXELu) nabízí vice QoS disciplín:
Strict Priority/WFQ/WRR
Ta Strict Priority znamená, že pakety z vyšších front mají striktní přednost před těmi z nižších (HH>High>Medium>Low).
Ty zbylé 2 disciplíny jsou vážené - viz Google.
Používám tu defaultní = Strict Priority.
Mám pravidlo na dest. IP 81.31.45.0/24 (== Odorik)
Výsledek:
a/ pokud tyto rámce přiřadím do fronty Low nebo Medium - na hovor mohu zapomenout.
b/ pokud použiji High nebo dokonce Highest (HH), tak jde i při 100% uploadu bez zakoktnutí
=> standardní priorita pro pakety, na než není pravidlo bude asi někde mezi Medium a High.
Ještě zkusím prozkoušet použití pravidla pro "ostatní" provoz (jako to má pro VoIP ten ZyXEL). Když jsem ho dal na 1. místo a dal mu Low, Tak VoIP běžel. Když jsem mu dal Medium a tomu VoIP Low ( ve 2.pravidle) tak VoIP také běžel - tak nevím.
Problém je v tom, že nevím, jak jsou pravidla vyhodnocována: pořadí, specifičnost, ...
Re: Jak (ne)funguje QoS ?
Dokončení testů:
Tak jsem ověřil i fungování pořadí pravidel.
Závěr pro Huawei HG520i je:
- na paket se použije 1. pasující pravidlo (dle jejich očíslování).
- defaultní fronta je Low (vím - dle pokusů s VoIP jsem zjistil, že by mělo být asi Medium nebo pod High, na čistých upladech jsem ověřil, že je to Low)
Důkaz:
Mám připraveny ke spuštění 2 upload aplikace:
1. destP=25 (odeslání velké přílohy na SMTP server 46.255.224.90 - přes rozhraní wlan0)
2. destP=80 (upload velkého souboru přes www rozhraní kamsi)
nastavil jsem 2 spojení k HG520i (eth0 a wlan0 pro snadné sledování datových toků pomocí iptraf):
QoS pravidla:
2. pravidlo destP=80 -> fronta Medium
a/ nic jiného => default==Low => P80 zcela potlačí P25
b/ 1.pravidlo default=Medium (=> použije se i pro P80) => P80 a P25 běží paralelně na +/- 1/2 rychlosti
c/ 1.pravidlo default=High => použije se i pro P80 => P80 a P25 běží paralelně na +/- 1/2 rychlosti
tedy: neuplatní se 2. pravidlo na P80 s Medium a P25 ho tudíž nepotlačí
d/ 1.pravidlo smazáno a 3. pravidlo default=High se uplatní jen na P25, jehož tok pak potlačí P80
Pozn.: zkoušel jsem i pravidlo pro destP=25 s různými prioritami (bez definice ručního default pravidla)a vždy to mělo očekávaný efekt.
Doufám, že mé celodenní úsilí bude ku prospěchu i někomu dalšímu
Ýrbod rečev.
P.S.: Mé finální nastavení QoS pravidel je toto: http://2i.cz/fcc685af7c
Přičemž:
- nastavení DSCP Remarkingu je na 99,99999% nanic
- pravidlo 16 - alá default je zbytečné - chová se to tak zřejmě "od přírody"
- pravidla pro P80 a P443 mám pro upřednostnění surfování před věcmi jak P2P, Ubuntu One, ... a jinými uploady
- disciplína "Strict Priority" má tu nevýhodu, že prioritnější provoz zcela uzemní ten méně prioritní. Tedy např. uload přes www (na destP=80) zcela takto utlumí např odesílání přes SMTP. Asi zvážím spíše disciplinu WFQ - viz http://en.wikipedia.org/wiki/Weighted_fair_queuing
Tak jsem ověřil i fungování pořadí pravidel.
Závěr pro Huawei HG520i je:
- na paket se použije 1. pasující pravidlo (dle jejich očíslování).
- defaultní fronta je Low (vím - dle pokusů s VoIP jsem zjistil, že by mělo být asi Medium nebo pod High, na čistých upladech jsem ověřil, že je to Low)
Důkaz:
Mám připraveny ke spuštění 2 upload aplikace:
1. destP=25 (odeslání velké přílohy na SMTP server 46.255.224.90 - přes rozhraní wlan0)
2. destP=80 (upload velkého souboru přes www rozhraní kamsi)
nastavil jsem 2 spojení k HG520i (eth0 a wlan0 pro snadné sledování datových toků pomocí iptraf):
Kód: Vybrat vše
# route -n
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
0.0.0.0 10.6.6.138 0.0.0.0 UG 0 0 0 eth0
10.6.6.0 0.0.0.0 255.255.255.0 U 1 0 0 wlan0
10.6.6.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
46.255.224.90 10.6.6.138 255.255.255.255 UGH 0 0 0 wlan0
2. pravidlo destP=80 -> fronta Medium
a/ nic jiného => default==Low => P80 zcela potlačí P25
b/ 1.pravidlo default=Medium (=> použije se i pro P80) => P80 a P25 běží paralelně na +/- 1/2 rychlosti
c/ 1.pravidlo default=High => použije se i pro P80 => P80 a P25 běží paralelně na +/- 1/2 rychlosti
tedy: neuplatní se 2. pravidlo na P80 s Medium a P25 ho tudíž nepotlačí
d/ 1.pravidlo smazáno a 3. pravidlo default=High se uplatní jen na P25, jehož tok pak potlačí P80
Pozn.: zkoušel jsem i pravidlo pro destP=25 s různými prioritami (bez definice ručního default pravidla)a vždy to mělo očekávaný efekt.
Doufám, že mé celodenní úsilí bude ku prospěchu i někomu dalšímu
Ýrbod rečev.
P.S.: Mé finální nastavení QoS pravidel je toto: http://2i.cz/fcc685af7c
Přičemž:
- nastavení DSCP Remarkingu je na 99,99999% nanic
- pravidlo 16 - alá default je zbytečné - chová se to tak zřejmě "od přírody"
- pravidla pro P80 a P443 mám pro upřednostnění surfování před věcmi jak P2P, Ubuntu One, ... a jinými uploady
- disciplína "Strict Priority" má tu nevýhodu, že prioritnější provoz zcela uzemní ten méně prioritní. Tedy např. uload přes www (na destP=80) zcela takto utlumí např odesílání přes SMTP. Asi zvážím spíše disciplinu WFQ - viz http://en.wikipedia.org/wiki/Weighted_fair_queuing
-
xsouku04
- Administrátor
- Příspěvky: 8160
- Registrován: pát 15. říj 2010 11:11:44
- Bydliště: Brno
- Kontaktovat uživatele:
Re: Jak (ne)funguje QoS ?
Díky za shrnutí, snad se to bude někomu hodit.
Re: Jak (ne)funguje QoS ?
Douška:
Ještě jsem zkusil tu disciplínu WFQ: http://en.wikipedia.org/wiki/Weighted_fair_queuing
a ačkoli fronta pro VoIP dostala dostatek % z upload pásma (aby mohly odejít všechny VoIP pakety), stejně docházelo k výpadkům (test na *081 - echo).
Na jiném upload testu (opět onen P80 (medium fronta) a P25 (low fronta - default) upload) nicméně WFQ fungovalo přesně dle očekávání:
- při jednou proudu (P80 xor P25) ten proud zaujal celou kapacitu upload linky
- při souběžném uploadu se se mezi ně kapacita rozdělila +- přesně dle nastavených vah pro jejich fronty.
Škoda, že u VoIP to nefunguje (proč ?!) => musel jsem se vrátit ke "Strict Priority" disciplíně.
Ještě jsem zkusil tu disciplínu WFQ: http://en.wikipedia.org/wiki/Weighted_fair_queuing
a ačkoli fronta pro VoIP dostala dostatek % z upload pásma (aby mohly odejít všechny VoIP pakety), stejně docházelo k výpadkům (test na *081 - echo).
Na jiném upload testu (opět onen P80 (medium fronta) a P25 (low fronta - default) upload) nicméně WFQ fungovalo přesně dle očekávání:
- při jednou proudu (P80 xor P25) ten proud zaujal celou kapacitu upload linky
- při souběžném uploadu se se mezi ně kapacita rozdělila +- přesně dle nastavených vah pro jejich fronty.
Škoda, že u VoIP to nefunguje (proč ?!) => musel jsem se vrátit ke "Strict Priority" disciplíně.
Re: Jak (ne)funguje QoS ?
Tak jsem při seedování torrentu zjistil, že to zase koktá.
Wireshark napověděl, že že RTP data tentokrát tečou přes 81.31.33.117 patřící (dle whois):
person: Tuy Mai Qui
address: Mity plus s.r.o.
Tak jsem upravil QoS na prioritizaci 81.31.0.0/16 namísto původního 81.31.45.0/24.
Otázka zní: z jakých všech IP rozsahů lze čekat RTP proxy Odoriku ?
Wireshark napověděl, že že RTP data tentokrát tečou přes 81.31.33.117 patřící (dle whois):
person: Tuy Mai Qui
address: Mity plus s.r.o.
Tak jsem upravil QoS na prioritizaci 81.31.0.0/16 namísto původního 81.31.45.0/24.
Otázka zní: z jakých všech IP rozsahů lze čekat RTP proxy Odoriku ?