dummynet/queue

[Dan Lukes]

Martin Horcicka wrote:
> Pokud si dobre vzpominam resil jsem neco jako sdileni roury (pipe) s omezenou
> rychlosti dvema ruznymi toky, aby pri plnem vytizeni roury byl jeden z toku v
> urcitem pomeru preferovany nad druhym (tedy rychlejsi), ale zaroven, aby pri
> nevyuzivani roury jednim z toku mel ten druhy k dispozici plnou kapacitu
> roury. (Snad tohle krkolomne vysvetleni pochopis.)

	Tak, to jsem si zhruba predstavoval, ze presne k tomu je to dobre.

> ipfw pipe 1 config bw 128Kbit/s
> 
> ipfw queue 1 config pipe 1 weight 60
> ipfw queue 2 config pipe 1 weight 40
> 
> ipfw add 1000 queue 1 ip from ... to ....
> ipfw add 1001 queue 2 ip from ... to ....
> 
> Snad je to spravne - nemam ted moc cas to zkouset. Takhle pravidly 1000 a 1001
> rekneme rozdelis provoz do dvou front, kde kazdy z toku ziska jinou vahu a
> postupuje dal do roury. Do roury se pak pakety z jednotlivych front vybiraji v
> pomeru danem jejich vahou.

	Well - jenze me zajima funkcnost trochu detailneji.
Pripustme, ze do obou front rveme pakety co to da.
Pakety se radi do QUEUE 1 a QUEUE 2 odkud jsou v pomeru 3:2 (ve prospech 
fronty 1 ?) vybirany a zarazovany do fronty pipe 1, ktera je vybavuje 
rychlosti 128Kbit/s zpet do jadra, ktere je cpe uz, zrejme, do nejakeho 
interface.

	Kdychom meli konfiguraci pouze s pipe bez queue, pak by pipe 1 mela 
vlastni fromtu, a kdybych do ni rval pakety prilsi rychle, nakonec by 
pretekla a pakety mi zahazovala (vzdy ten posledni, co se nevejde).

	V teto konkretni prikladme konfiguraci je to take tak ? Tedy:
Pakety se z queues vybavuji v pomeru 3:2 (jakou rychlosti ?) a zakladaji 
do fronty u pipe, a je-li preplnena tak se vlastne s pravdepodobnosti 
3:2 zahazuji, nebo jsou queue a pipe svazany tak, ze pokud je fronta u 
pipe plna, tak se paket z queue nevybavi ?

	A ted jina situace - predstavme si, ze tok prichazi prakticky pouze z 
jednoho smeru - chova se "vybavovaci" algoritmus tak, ze neni-li paketu 
v queue, ktera by jinak mela byt na rade, sahne do jine ? A je-li queues 
na pipe vicee nez dve, tak s jakymi pomery bude realne obsluhovat 
zatizene queue kdyz nektere jsou "prazdne" (napriklad mame do pipe 
smerovany 3 queue s vahami 10:10:40 pricemz v posledni queue neni 
traffic - budou se tedy prvni dve fromty vybavovat pomerem 1:1 ?)

Petr Spodniak wrote:
 > Jen na doplneni mala ukazka... sdilena linka 64kbps, kdy je datovy tok
 > do internetu rovnomerne rozdelen mezi vice uzivatelu (kteri v dane cvili
 > komunikuji) vnitri site:
...
 > ipfw pipe 11 config bw 64kbps queue 2
 > ipfw pipe 12 config bw 64kbps queue 2
 > ....
 > ipfw queue 11 config pipe 11 mask src-ip 0x000000ff queue 2
 > ipfw queue 12 config pipe 12 mask dst-ip 0x000000ff queue 2
 > ....
 > ipfw add 410 queue 11 ip from 192.168.1.0/24 to any in via rl1
 > ipfw add 410 queue 12 ip from any to ${inet} out via rl1

 > - je potreba vydefinovat pipe i queue 2x - pro oba smery samostatne
 > (full duplex) - bude-li pipe jen jedna pro oba smery simuluje half
 > duplex provoz

	Coz o to, toto je jasne, zajimavy je sam o sobe jiny problem - 
predpokladam, ze 64kbps je fyzicky strop dane linky. Ma nejaky prakticky 
vyznam omezovat tok na prichodu prostrednictvim cehokoliv (pipe nebo 
queue) kdyz fyzicky vice dat stejne nepritece ? A pokud to ma nejaky 
prakticky vyznam, tak jaky ? Mam, mozna, spatny dojem, ze tato 
konfigurace "spravedlnost" na prichodu nezajisti, protoze v predestrene 
konfiguraci dummynet na prichodu zadne pakety nikdy nezahazuje. Nebo ano ?

	Tak - pripustme, ze fyzicka linka je silnejsi nez 64kbps, nicmene, na 
tuto hladinu je omezena ze smluvnich duvodu (jeden cas jsem skutecne 
spravoval sit pripojenou pres mikrovlnu s fyzickou kapacitou okolo 
300kBps, pricemz skutecne vyuzivana kapacita byla omezena na zaklade 
dohody na 128kbs a to nastavenim na me strane, nikoli na strane ISP). V 
takovem pripade je prichozi traffic limitovan na smluvni hodnotu pomoci 
proste "pipe" - cokoliv slozitejsiho nema zadny prakticky vyznam. Nebo 
se mylim ?

Robert Kania wrote:
 > doufam, ze se na mne nebudete Dane (a ostatni) zlobit, ale toto si
 > nemuzu odpustit.
 >
 > Pokud opravdu netrvate na cestine, tak zaklady naleznete zde:
 > 
http://staff.mybsd.org.my/nik/artikel/traffic-shaping/traffic-shaping.html


	Ne, nebudu se zlobit - puvodne jsem ve svem dopisu napsano, ze netrvam 
na cestine, ze pripustny je jakykoliv jazyk zapisovany latinkou a 
azbukou - a ve vysledne verzi jsem to nakonec zkratil.

	U techto odbornych textu se natolik pouzivaji anglicke vyrazy (obvykle 
z nedostatku lokalni terminologie), ze text je ramcove srozumitelny tak 
jako tak - a platilo to i pro tento priklad, a to navzdory tomu, ze 
vlastne vubec netusim v jakem jazyku je text napsan. Nicmene, v textu 
odpovedi na me otazky nejsou ...


						Dan