Queue Tree a nastaveni type Queue

net_work

asi mas pravdu, ale ja jen rikam to, ze jak si rikal ze staci nahazet usery do jedne nadrazene skupiny a ono se to samo rozdeli, tak takhle to urcite nefunguje, resp bez PCQ ne.. jinak nezda se vam ze v pripade pouziti PCQ se lehce pomaleji nacitaji web stranky, resp. odezva po kliknuti neni takova rychla? nebo se mi to jen zdalo?...... :

hapi

jo takhle, já to myslel jako, že nahážu každýho usera do svojí queue a všichni maji stejnou nadřazenou queue. Pak je to stejný jako PCQ ale můžu si u každýho udělat co potřebuju.

Je možný že PCQ má pomalejší reakce, musí přepočítat celej ten společnej tok defakto přidá na tu dobu stahování další pomyslnou queue a to nějakej čas trvat bude. Určitě tam někde bude vnitřně nastavenej čas přepočítávání jako tomu je u SFQ což může bejt ta doba chvilkový nereakce.

net_work

jo takhle, já to myslel jako, že nahážu každýho usera do svojí queue a všichni maji stejnou nadřazenou queue. Pak je to stejný jako PCQ ale můžu si u každýho udělat co potřebuju.

Vsak ano, presne tak... takhle to fakt ale nefunguje... mam to odzkousene... jeden user je pak schopny nejaky torrentem zabrat celou linku... vazne.... pokud to PCQ nepouzijes, tak to fakt nebude rovnomerne...

hapi

ale ono to fakt rovnoměrný je. Musíš mít správně vypočítaný jejich "limit at". Od toho se to všechno odvíjí dál. Je to něco jako že i kdyby na chleba nebylo, "limit at" jim to bude pouštět stejně. Prostě minimální rychlost v mém příkladě.

net_work

ale ono to fakt rovnoměrný je. Musíš mít správně vypočítaný jejich "limit at". Od toho se to všechno odvíjí dál. Je to něco jako že i kdyby na chleba nebylo, "limit at" jim to bude pouštět stejně. Prostě minimální rychlost v mém příkladě.

no to ja chápu samozřejmě jak funguje limit at... ja teda mam limit at 0 u klientu a mam jen limit max. ale to by vicemene nemelo vadit - samozrejme nadrazeny parrent uz svuj limit at ma....

hocimin1

ale ono to fakt rovnoměrný je. Musíš mít správně vypočítaný jejich "limit at". Od toho se to všechno odvíjí dál. Je to něco jako že i kdyby na chleba nebylo, "limit at" jim to bude pouštět stejně. Prostě minimální rychlost v mém příkladě.

no to ja chápu samozřejmě jak funguje limit at... ja teda mam limit at 0 u klientu a mam jen limit max. ale to by vicemene nemelo vadit - samozrejme nadrazeny parrent uz svuj limit at ma....

Tak to je pak jasny kdyz mas limit-at 0 , ze ti to nejakej jinej klient sebere torrentem.

limit-at je minimum co mu potece at se deje co se deje. A jak mu ma neco tyct, kdyz to mas nastaveny jako 0 a torrentem mu jiny klient sebral vsechno limit-max

net_work

ale to je nesmysl... prece kdyz budou v cele te parrent queue aktivni jen 2 klienti z 20 a bude mit limit at treba 30k tak prece nebude mit jeden klient 1970k a druhy 30k.... to je prece nesymsl.. ten limit at ma smysl az tehdy kdyz vsichni klienti zacnou stahovat, pak se tedy zacne aplikovat to ze kazdy bude mit tech 30k ... a nebo se pletu? rekl bych ale ze ne... limit at je prece garantovane minimum... a nema nic co docineni se spravedlivym rozdelenim rychlosti.....

maxik

No teda ze se neshodnete na zakladnich vecech kolem front to koukam. kdyz ma limat. 30k a maxlim. 1M tak jakmile zacne nadrizena fronta jit pres maxlimit. zacne dynamicky prepocitavat a podle priorit podrizenych Q rozdelovat rychlost, 30k se muze dostat ale jen za urcitych podminek.

hapi

"limit at" dostane vždy, bez ohledu na úplně cokoliv. "Max limit" je limit maximálního pučení od nadřazený třídy.

reset

koukam to pcq front a

zjistuji nasledujici,

pokud je pcq nastaveno na konci stromu at uz SQ nebo TQ , tak se vytvareji jednotlive front a te Q .

Pokud je to ale na zacatku nebo uprosred stromu, pcq queue je vzdy 0 !!!

ve winboxu ve statistikach se nezobrazi nic pokud to neni na konci stromu

pri vypisu /queue simple print stats nebo /queue tree print stats

Mel by k tomu nekdo vysvetleni ?

hapi

to bych teda měl, protože fronty se nepoužívaji v průběhu stromu. Sice je tam vyplníš ale nefungujou. Aktivní jsou vždy až na konci stromu, už jsem to tu někde psal. Pohledej na netu manuál HTB, tam se dočteš jak to všechno funguje. Je to stejný jako v linuxu akorát rate je limit at a ceil je max limit. Navíc PCQ dávat do stromu je kravina, tohle zařídí SFQ. PCQ je spíš pro SQ.

http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

existuje nebo možná existovala i česká verze stránky ale nemůžu jí najít. Tam je přesně od autora (čech co to vymyslel) popsáno jak to funguje.

iTomB

hapi me predbehl.

Jinak ceska verze je tez u devika. Jen ne vse je v cestine.

To ze QUEUE je pouze na konci stromu je jasne. Jinak se to totiz omezit neda. Z konce stromu pridelim kazdemu kolik je potreba a celkove treba 10M (z 10M) a dalsi omezeni v tom samem strome je blbost, protoze by se ani nemusela vyuzit cela kapacita linky.

iTomB

hapi

fronty jsou jenom na koncích už jenom z toho důvodu, že jsou to buffery. Protože tam probíhá omezování a tam se brzději data. Jinde ve stromě se nic nebrzdí, to slouží jenom pro vnitřní výpočty. Konečný třídy slouží pro brždění a proto že tam je buffer, ta se tam daji nasadit fronty a můžeme si tam dát obyč fifo nebo sfq pro rovnoměrnější rozložení datových toků uvnitř třídy (queue). Ve třídách jinde než na konci to nemá smysl, tam už se o to postará logika sama podle nastavení konečných tříd.

jako fakt doporučuji si slovo od slova přeložit anglickou stránku a pak pochopíte jak to má bejt správně nastavený a jak to perfektně funguje. Pak zjistíte co ovlivňujou parametry a jak se s nima dál zachází a to že priorita neovlivňuje limit at tříd ale max limit a jejich pučování rychlosti od nadřazený třídy a podobný věci.

farmar

vem si třeba situaci. Máš 10Mbit linku. 3 APčka. Na každym 3 lidi. Lidem dáváš 2Mbit. Dejme tomu, že každý APčko utahne maximálně 4Mbity. Je jasný, že když tam budou všichni, tak nebudou stačit jak APčka přenášet data, tak i hlavní linka.

Napíšu tedy hlavní třídu 10Mbit, což je moje linka. Správně by se mělo dávat trochu míň aby se nestalo že omezování tvýho toku bude dělat ten co ti dává net protože pak ti bude omezování chodit blbě.

Na hlavní třídu navěsim rychlosti APček. A tady pozor. V QT jsou v queue dvě volby. Limit at a Max limit. Součet všech "limit at" pod jednou třídou, by neměl přesahnout "limit at" třídy nadřazený. "Max limit" je defakto kolik si můžu pučit rychlosti od nadřazený třídy když bude dostupná kapacita. Takže pokud mám rychlost linky 10Mbit a rychlost APček 4Mbit, vytvořim pod hlavní třídou která má "limit at" 10Mbit a "max limit" 10Mbit , tři třídy který budou mít "limit at" 3,3Mbit a "max limit" 4Mbit. Je to jednoduchý, součet "limit at" nepřekročí "limit at" hlavní linky a "max limit" je max kolik si můžu vzít na víc když bude.

No a teď samotný usery, platí to samí. Takže jednotliví useři budou mít "limit at" na 1.1Mbit a "max limit" na 2Mbit. Až tady můžu navěsit konečně nějakou frontu a jediná co v tomhle jde použít kromě pfifo a bfifo je sfq.

Když se nad tim člověk zamyslí, tahle agregace nemá chybu. Každej dostane svoje. Zároveň ochránim APčka proti přetížení a tedy zaručim i dobrý odezvy.

Pokud sečtu "limit at" všech userů, vyjde mi 9,9Mbit takže naprostá dokonalost. Mimo to když budou tahat dvá na každym APčku, tak se jim rychlost toho třetího rozdělí až do limitu jejich třídy, či limitu APčka. Čili když je max na APčku 4Mbit, oni dvá dosahnou každej 2Mbit.

Ukázka s trochu jinými rychlostmy.

Hodně taky záleží na poměru "limit at" mezi usery pod jednou třídou. Proto jsou taky vypočítaný v poměru aby si pak i v poměru kradly rychlost. Dá se říct, že user22 má garantovanou linku 850kbit ale může stahovat rychlostí až 2Mbity pokud tam jeho kolegové nebudou ale zároveň s nim může stahovat i user21 ale když nebude stahovat user21 ale user23, tak se podělí o zbývající rychlost AP2 a v poměru svích "limit at" se podělí. Nepojedou dohromady 5Mbit ale 4Mbit a user22 rychlostí 1.6Mbit a user23 2.4Mbit

Mam len jednu otázočku .

Celkom sa my to páči ,hlavne to že týmto spôsobom ochrániš každý wifi prístupový bod v sieti a dáš mu určitý limit-max.

Zaujíma ma ,ak traffic ide na maximum svojho rodiča ,čiže sa tam sťahuje a príde niekto čo iba surfuje ,stránky idú svižne ??

Burst tam nemusí byť???

Dik.

hapi

Dobrá otázka, hmm, bursty tam zatim nemám ale i tak se to chová dobře. Když tak se tam daji dopsat.

pepulis

Prosím jaky queue type pouzivate v nastaveni Interface queues? Defaultne je tam nastavena ethernet-default a jeho kind na pfifo. Pokud to mate takto, jakou hodnotu mate u pfifo - kolik packets? Resim jak spravne nastavit hodnotu, aby se mi linka pri nastaveni QT max limit 950 Mbit spravne "dobrzdila" do 1 Gbit, ktery je do GW priveden. Jamile linku vytizim na max (iperfem a dalsimy testy), tak ma tendenci navysovat odezvu. Snazim se to tedy zoptimalizovat tak, aby k tomu nedochazelo. Poradi prosim nekdo?

hapi

Fronta je na výstupu. Ty omluvis o vstupu. Dvě různý věci. Nemůžeš brzdit věci který ti přichází. Vždy dojdou.

pepulis

hapi A Hapi, tady nastavujes prosim co?

V defaultu je tam only-hardware-queue a tomu odpovida kind none. Za jakych podminek se toto meni napr. na ethernet-default (kind pfifo), tj. kdy to ma smysl zmenit? Diky za odpoved.

hapi

Mikrotik má defaultně nastaveno only-hardware-queue což znamená že softwarový buffer žádný není a použije se pouze hw buffer - vyrovnávací paměť v daném hw iface. Data z CPU jdou přímo do iface bez bufferu v ram. Před lety to zavedly jako default s tím že to bude mít menší zátěž na cpu když to nebude strkat do RAM a pak do iface. Což je sice pravda ale jakmile bude větší průtok na routeru, přestane hw buffer stačit a zařízení bude dropovat protože nebude mít prostor kam peaky ukládat. Je třeba taky dodat že to zavedli v době RB411.

Když si vemeš linux a použiješ příkaz ifconfig

eth0 Link encap:Ethernet HWaddr 09:00:12:90:e3:e5 inet addr:192.168.1.29 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe70:e3f5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:54071 errors:1 dropped:0 overruns:0 frame:0 TX packets:48515 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:22009423 (20.9 MiB) TX bytes:25690847 (24.5 MiB) Interrupt:10 Base address:0xd020

tam vidíš položku "txqueuelen: 1000" což je výstupní softwarový buffer než se data odešlou do interface. To je to samí jako ta tabulka co si poslal akorát mikrotik defaultně nastavuje txqueuelen: 0

Já doporučuju minimálně přepnout na ethernet-queue což je tuším fifo 50 paketů. Se zátěží cpu si nedělej hlavu. Mikrotik u flapování portů u RB3011 doporučil přenastavit porty na fifo 500 paketů a hodně lidem to pomohlo. Na hlavní GW například máme 5000. Osobně raději preferuji zvýšenou latenci při problémech než drop paketu. Zvýšení toho bufferu pomáhá například i při použití flow control tam kde je jich hodně. A vyhnul bych se jiného typu než je FIFO. Na wifi iface klidně nech SFQ.

pepulis

hapi Díky za odpověď. Já jsem si procházel různé diskuze, např. tady https://forum.mikrotik.com/viewtopic.php?t=148156 se píše o tom, že velká hodnota pfifo size může mít vliv na max. rychlost tj. jestli to dobře chápu, tak při velkých tarifech bych nemusel na tak velkou rychlost dosáhnout. Máš s tím zkušenosti, zaznamenal jsi něco podobného s pfifo limit nastaveným na 5000,jak píšeš?

ekrajnak

hapi nechapem, preco tato odpoved po pomaly dvoch rokoch, ale vdaka za nu!!!

Uz vo vedlajsom vlakne som pisal ze vsetky RB3011 a RB4011 u nas na sieti maju vysoky discard rate na portoch a nastavenie pfifo front, ako teraz skusam, robi zazraky - samozrejme s rozumnou velkostou fronty, aby nedochadzalo k dicardom ale zaroven ani velmi velkemu oneskorenie, lebo aj to vplyva na TCP priepustnost a samozrejme pre latency critical sluzby je velky jitter nepripustny.

Ale ak ma prepocty neklamu, fronta 500 paketov s 1500 bajtami pri 1Gbps porte sposobi oneskorenie max. 5ms. To je zanedbatelna hodnota.

Ja mam problem na RB4011 naplnit 1Gbps port na 400M bez discardov. Ci je horsie, saturacia napr. 100Mbps portu Ether7 sposobuje brutalne discardy na 1Gbps porte Ether9. Viď. príklad:

Ether7 Traffic

Ether9 Discards

« Předchozí stránka Další stránka »