dummynet/queue

[Martin Horcicka]

Dan Lukes (2002-11-29 14:36 +0100):

> Martin Horcicka wrote:
>
> > > > 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.

Mas naprostou pravdu - tohle je muj omyl. To dokazuje, ze to chapes spravne,
nebo, presneji receno, tak jak jsem to pochopil ja, coz nemusi byt totez. ;-))

Martin