forum.odorik.cz

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č.

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ě.

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).

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.

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, ...)

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, ...

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

Díky za shrnutí, snad se to bude někomu hodit.

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ě.

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 ?