dummynet/queue

[vita at fio.cz]

>       Dobra - zacinam byt vice-mene uspokojen ve sve zvedavosti (zbytek si, 
> zrejme, budu muset stejne vyzkouset a tusim, ze tomu cteni zdrojaku se 
> taky, zrejme, uplne nevyhnu) - zustava mi tedy nevyresena zejmena otazka 
> prichoziho limitu na stejnou hodnotu jako je fyzicky limit linky, 
> odpoved na niz rozhodne, zda jsem to vsechno pochopil spravne nebo vubec.

Ja jsem to pochopil stejne jako ty. Navic jsem zkoumal jesli by se prece jenom
na prichozim toku, ktery je omezeny uz providerem, nedal nejak zaridit
spravedlivy pristup ke kapacite linky.

V pripade, ze si udelam pipe, ktara bude mit o neco nizsi kapacitu nez prichozi
linka, a do te pipe povedou napr. 2 queues se stejnou prioritou, bude to
vypadat takhle:

Trocha znaceni
KL - kapacita linky (omezena providerem nebo schopnosti media, karty atd.)
KP - kapacita pipe (KP < KL)
R = KL - KP rozdil
KQ1 = KQ2 = KP/2 kapacity toku pres fronty q1 a q2

Pokud v nejakem okamziku nastane napr. takova (nespravedliva) situace, ze
toky prislusne frontam q1 a q2 jsou v pomeru napr.
1:2 a jejich soucet je KL, tak pri pruchodu pipou budou zahazovany vyhradne
pakey z fronty q2 a to v mnozstvi odpovidajicim prutoku o velikosti R.

V pripade ze TCP stack bude dostatecne elasticky, melo by dojit k tomu, ze tok
pres q2 se snizi a tudiz vznikne zvysena kapacita pro tok pres q1 a tok pres q1
se zvysi.

Zahazovani vyhradne paketu z q2 bude pokracovat stale, dokud tok pres q1
nedosahne hodnoty KQ1. V tom okamziku bude tok od providera bude:
pres q1 KQ1 
pres q2 KQ2+R
a zahazovat se budou stale vyhradne pakety jdouci pres q2.

Je pravdepodobne, ze jeste bude dochazet k dalsimu vyrovnavani, ale uz je
to trochu slozitejsi analyzovat, co se bude presne dit. 
Vzroste jeste tok paketu do q1 a zacnou sa zahazovat i pakety jdouci pres 
tuhle frontu. 
Je mozne ze dojde k uplenemu vyrovnani toku a stabilizaci na hodnotach KQ1 a
KQ2, ale i kdyby ne k jistemu nastoleni spravedelnosti prece jen doslo.

Zaverem bych chtel dodat, ze je to ode me cista teorie, ktera navic
predpoklada dostecne elasticky TCP stack, ktery je schopen reagovat na
zmenu pruchodnosti o velikosti R. I v pripade, ze by tenhle model byl
spravny, je otazka jestli dostatecne popisuje skutecny stav.

Doufam, ze je to aspon trochu srozumitelny a ze to neni uplnej nesmysl.

vita novy