Létezik egy classful qdisc (PRIO). A PRIO képes real-time ütemezésre, tehát az interfészen elérhető sávszélességtől függetlenül működik. A PRIO ütemezője a dequeue eseményeket osztja szét a benne lévő osztályok között. Ebbe a qdisc-ben maximum 16 osztály tehető és a felosztás nem lehet több szitű (hierarchikus). Mindezek mellett nem képes azonos sávsélesség elosztásra vagy súlyozott elosztásra az osztályok között. A PRIO-ban ha van magasabb rendű forgalom akkor a többi teljesen elnyomódik.
A HTB, CBQ, HFSC képes egyenlő felosztásra és hierarchikusan rendezhetők bennük az osztályok. A PRIO-val szemben viszont ezek a módszerek igénylik, hogy az interfész sebessége meg legyen adva. Ha rossz a megadott érték, mert a sávszélesség változik (pl wifi), akkor ezek a módszerek nagyon rosszul működnek.
A PRIO jó, de nagyon buta. Létezik a HTB-hez hasonló eszköz a változó sávszélesség arányos felosztására? Esetleg a HTB/CBQ/HFSC is tudja, csak én nem tudok valamit?
- 1843 megtekintés
Hozzászólások
Nem írtad le egyszerűen a problémát amire a megoldást keresed.
Ha csak egyenlő elosztást akarsz, akkor szerintem az ESFQ felé kéne keresgélned, ami forrás/cél IP alapján több queue -ba rendezi a csomagokat ahonnan az interfész round-robin -al küldi ki őket. Itt a súlyozás necces, talán a megoldás az lehet, hogy bizonyos ügyfélhez több queue -t rendelsz.
- A hozzászóláshoz be kell jelentkezni
Ez az ESFQ figyelemre méltó qdisc. Most hallottam először. A mainline kernelnek bár nem része (http://lxr.linux.no/#linux+v2.6.33/net/sched/), de ez nem feltétlen jelent rosszat. Bár úgy látom csak src ip alapján lehet vele dolgozni. Ez feltöltési sebesség szabályozására jó így csak. Illetve nem lenne hátrány osztályos módszer. A filterek igen nagy szabadságot adnak a forgalmak szétválogatásában.
Egyébként igen. Súlyozottan szeretném elosztani a sávszéleséget. Azt szeretném, hogy legyen egy htb-hez hasonló fa hierachia, amiben az első szinten például 3 osztály osztozna 80%/10%/10% arányban. Majd ezek az osztályok adnák tovább az ő sávszélességüket a userek osztályaiba szintén súlyozva.
- A hozzászóláshoz be kell jelentkezni
Az ESFQ README -je szerint dst, src, fwmark, conntrack alapján is tud hash -elni, ergó jó a bejövő sávszél korlátozására is.
A HTB "prio" paraméterét nézted, hogy az pontosan mire jó? Az ESFQ -t lehet kombinálni ugye a HTB -vel, azzal is lehet operálni.
Csak érintőlegesen foglalkoztam még ezzel a témával, kész megoldást nem tudok sajna. Meg amúgy se értem, hogy pontosan mi a cél. :)
- A hozzászóláshoz be kell jelentkezni
Megnéztem aztán az ESFQ-t közelebbről és valóban tud sok szempont szarint hash-elni. Ezért bocs, túl gyorsan válaszoltam utánajárás nélkül.
A htb prio, rate és ceil paramétereivel csodásan felosztható a sávszélesség, de csak egy fix sávszélesség. A gyökérosztály egy fix sebességgel ürít az interfész buffer-jébe. Ha a gyökérosztálynál lassabb az interfész, akkor attól függően, hogy éppen mit kapott a puffer a tetejére, összevissza elkezdi a csomagokat eldobálni. A szabályrendszered 2x -es sebesség deficitnél mármár nem is látszik létezni. Mintha nem is lenne. A wifi-nél meg aztán nemhogy kétszeres de gyakran 20x-os sebesség deficit is van a max-hoz képest.
Tehát a cél az az lenne, hogy olyan módon mint a htb fával Mbit-ekben, ugynezt súlyokkal szétosztva megvalósítani, hogy ne függjön az aktuális sávszélességtől. Wifi esetén ez az egyetlen járható út szerintem.
- A hozzászóláshoz be kell jelentkezni
Reg volt hogy ilyesmivel foglalkoztam, szoval lehet hogy rosszul emlekszem, de ha HFSC-nek real-time (rt) curve nelkul csak link-sharing (ls) curve-oket adsz, akkor annak mukodnie kene valtozo savszel mellett is, nem? (Es olyankor csak a rate ertekek hanyadosai szamitanak.)
Egy probat valoszinuleg meger, hogy igy mukodik-e.
Ezeket olvastam regen:
http://linux-ip.net/articles/hfsc.en/
http://www.trash.net/~kaber/hfsc/SIGCOM97.pdf
- A hozzászóláshoz be kell jelentkezni
Igen ezen vagyok rajta jelenleg. Neked működött tc filter-ekkel az osztályozás akkoriban? Esetleg az iptables -j CLASSIFY -jét használtad az osztályokba rendezéshez? Mert én most egy ubuntun és egy frugalware linux-on próbáltam és ha tc filter-el dobtam az osztályba a csomagokat, akkor kb 10s után(változó) lehal minden forgalom, annyira hogy az osztályba se jut már be. Száz hogy ez nem bug. Bennem lesz a hiba. A doksik a filterezésre nem adnak istrukciókat. Gondolom azért nem említik, mert működni kéne neki mint minden más módszer esetében. Valami mégsem az igazi. Nem maradt valahol egy példakonfigod, vagy valami emléked? Ja és köszi a hozzászólást!
- A hozzászóláshoz be kell jelentkezni
A tc filterrel megesett, hogy volt bajom (nem emlekszem pontosan, de valami patch hianyzott a vanilla kernelbol), helyette ha csak tehettem, akkor
iptables -j CLASSIFY-jal osztalyoztam.
Illetve talaltam neked egy 2008-as HFSC-t hasznalo scriptet, de ha az adott wifi chipset nem kenyszeritett volna ra, hogy 2.4-es kernelt hasznaljak, akkor IMQ helyett IFB-t es MARK helyett CLASSIFY-t hasznaltam volna.
http://hup.pastebin.com/GEBBE21a
Ez valaha egy WRT54GL-re keszult, emlekeim szerint mukodott (most ugyan toroltem par nem publikus adatot tartalmazo iptables szabalyt, de ennek nem szabadna gondot okoznia). Fokepp a
tc_{egress,ingress}_*fuggvenyek erdkelhetnek.
update: kozben megtalaltam, hogy a tc filterrel meg 2004-ben volt bajom, szoval oszinten remelem, hogy az mar nem all fonn :-)
- A hozzászóláshoz be kell jelentkezni