dummynet/queue

[Dan Lukes]

Martin Horcicka wrote:

> >	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 ?
>
>
> Ted si nejsem jisty, jestli chapu tvou otazku spravne. Zkusim 


> - Presun z front struktur queue do fronty struktury pipe probiha az 
> kdyz je ve
> fronte struktury pipe misto, takze pakety se v tomto stadiu nezahazuji.


	Neni dulezite chapat otazku, pokud zvladas poskytnout odpoved ... ;-)

	Tohle byla hledana informace.

> >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 ?
>
>
> Zrejme opet chapu jen castecne, ovsem z toho Petrova prikladu ani neni 
> uplne
> jasne, co se skryva za ${inet}. Pokud je to opet 192.168.1.0/24 (nic 
> jineho me
> nenapada), pak se na prichodu pakety take zahazuji - pri zaplneni 
> prislusne
> fronty u struktury queue 12 (tady je diky pouziti masek u kazde struktury
> queue samostatna fronta pro kazdy pocitac z vnitrni site).


	No, to se mi prave zda neplatit. Uvedom si, ze mame takovouhle 
strukturu prutoku prichozich dat:

                      /-- Queue 12/.1 -\
                     /-- Queue 12/.2 ---\
                    /-- Queue 12/.3 -----\
 >->-Linka 64kbps->/   .......           /--SW pipe 64 kbps->->
                   \-- Queue 12/.254 ---/


	Celkovy pritok do vsech Queue tedy nemuze v souctu presahnout 64kbps a 
na stejnou vysi je nakonfigurovan take odtok v souctu.

	Pohledneme na problem "od konce" - tedy od pipe. Mirne zjednodusene 
receno - pipe sahne do nejake queue pro paket (podle vah), vytahne ho a 
doruci - pokud ve vybrane queue nahodou zadny paket neni, tak si najde 
jinou kde je - kazdopadne, pipe taha z queues onech pozadovanych 64kbps. 
To jsou queues prave tak schopny dohromady dodat, protoze prave a presne 
tolik cini jejich celkovy pritok. Rozhodne se nema kde vzit "nadbytecny" 
paket, ktery by nebyl v zapeti "vycucnut" do hladove pipe a byl misto 
toho zahozen. V zasade nema vubec jak dojit k situaci, ze by ve fronte 
od Queues nebo ve fronte od pipe cekal jediny paket - a tedy se nemohou 
preplnit a tedy se nikdy nic nezahodi.

	Dokonce i kdyby celych 64kbps smerovalo na jedinou cilovou adresu, pak 
se stejne vsechny pakety doruci, protoze pipe bude obsluhovat jedinou 
neprazdnou queue - a obdobne to plati pro jakekoliv rozdeleni prichoziho 
trafficu podle cilovych adres.

	Nejde mi tedy ani tak o problem "kdyz uz se to tou slabou linkou 
protlacilo, tak proc to kvuli "spravedlnosti" zahazovat" - jde mi o to, 
ze pokud jsem vase vysvetlovani funkcnosti pochopil spravne, tak 
efektivni funkce vyse uvedene konfigurace je "NOP" - tedy az na overhead 
a komplikovanost konfigurace.

	Neni-li tomu tak, pak jsem stale jeste funkci queues nepochopil dobre. 
Pokud jsem te nepresvedcil o tom, ze to fakticky nic nedla (pro prichozi 
toky) - muzes vykonstruovat nejakou situaci (pocatecni podminky si zvol 
libovolne realne mozne) kdy se dosly prichozi paket zahodi ?

> >	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 ?
>
>
> Jak uz jsem snad vysvetlil, tak pokud se nemylim, mylis se. :-) Tenhle 
> pripad
> je myslim idealni pro pouziti Petrova prikladu, kdy pomoci front 
> zajistujes
> spravedlnost.


	Dobra, v tomto pripade jsi me presvedcil - takrka. Pokud se budou 
pakety delit do queues podle destinace - a, nejlepe, pokud zahazovani 
"nevejdoucich se" paketu z nich bude ridit (G)RED, pak to skutecne 
zespravedlnuje pristup k mediu (bez g/RED by to asi fungovalo take, ale 
zrejme zdaleka ne vzdy spravedlive) - a v pripade dobre napsanych TCPIP 
stacku na strane odesilatele to skutecne muze ovlivnit flow-control a 
zpomalit realnou kadenci odesilanych dat ...


	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.

				Zatim diky

						Dan


-- 
Dan Lukes,  SISAL, MFF UK  tel: +420 2 21914205, fax: +420 2 21914206
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz, dan at fio.cz