dummynet/queue

[Martin Horcicka]

Dan Lukes (2002-11-28 19:35 +0100):

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

Ted si nejsem jisty, jestli chapu tvou otazku spravne. Zkusim podrobneji
popsat svou hypotezu funkcnosti prikladu vyse:

- Kazda struktura queue i pipe obsahuje vlastni frontu paketu, v pripade
pouziti masek dokonce pro kazdy tok samostatnou frontu.

- Pri pouziti pravidel 1000 a 1001, se paket zaradi na konec fronty u
prislusne struktury queue, nebo, pokud je plna, zahodi se.

- Z prislusnych front struktur queue, ktere nejsou v tu chvili prazdne, se
vybiraji pakety do fronty struktury pipe ve stejnem pomeru jako je pomer vah
techto front (numericky vetsi vaha = vetsi frekvence zvoleni). Takze vahy
prazdnych front se podle me pro vyber paketu do fronty struktury pipe
nepouzivaji. Jak je to presne udelane nevim - zrejme se nejak porad
prepocitava aktualni pomer a hleda se nejaka rozumna cesta k dosazeni
pozadovaneho pomeru.

- 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.

- Fronta struktury pipe se vyprazdnuje rychlosti danou jeji konfiguraci, coz
uz je jasne.

> 	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 ?)

Podle me ano.

> 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).

Zda se mi ale, ze se ptas i na smysl zahazovani neceho, co uz stejne proslo
tou fyzicky uzkou linkou, jen kvuli "spravedlnosti". Nemam presnou predstavu o
funkci TCP, ale mozna to alespon trochu brzdi rychlost posilani TCP dat od
vzdalenych serveru pres linku smerem k nam. Nebo ne?

> 	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.

Ale jak jsem rekl, vsechno co tu pisu je jen moje hypoteza nabyta z manu
ipfw(8) a drobneho zkouseni. Zdrojaky jsem necetl, ani jsem to vsechno
nezkousel.

Martin