RE: lug-bg: htb, cbq, wrr, red, gred, csz, wfq, hfsc, blue, etc.

[bkrosnov@email.domain.hidden (Boyan Krosnov)]

<em class="quotelev1">> A zashto ne htb + wrr kato leaf? Ot tova koeto znam za traffic control
<em class="quotelev1">> vav Linux, ne stava iasno dali classful queueing moje da bade leaf na
<em class="quotelev1">> drug classful queueing...
I tova probvahme. Ako prochetesh pyrviq mi mail v tozi thread, shte
vidish vsichki varianti, koito sme probvali. da se citiram sebe si za da
ne rovish:
"HTB za obshtite klasove + WRR za otdelnite potrebiteli (samo
razpredelenie, bez ogranichenie) - raboti, no e znachitelno po-tochno"
Raboti i tova, no kakto moje da se ochakva ne mojesh s nego da
ogranichavash vseki otdelen ip adres na nqkakva maksimalna skorost, a
tova e koeto ni trqbva v sluchaq. T.k. potrebitelite sa mnogo i imat po
tochno edin ip adres i uslugata e ot takyv (ogranichen ot gore) tip.
V tozi sluchaj polzvahme htb-to za ogranichenie na golemi grupi useri i
wrr-to za ravno razpredelenie mejdu potrebitelite v edna grupa.

<em class="quotelev1">> Tova koeto az polzvam e obsht htb class za tip usluga, razdelen na po
<em class="quotelev1">> malki podklasove ot po 10-ina potrebitelia (IP-ta) sas zakacheni dst
<em class="quotelev1">> matching sfq kato leaf clasove za fair queueing. Raboti 
<em class="quotelev1">> gore-dolu dobre.
<em class="quotelev1">> Vsashtnost edinstvenia nedostatak e, che sfq niakaksi ne e dostatachno
<em class="quotelev1">> barz ili "fair". Kogato niakoi okupira kanala, drugite mogat da go
<em class="quotelev1">> izmestiat, no dosta bavno (10-ina secundi?) i laga (ping do 
<em class="quotelev1">> koe da e IP
<em class="quotelev1">> ot grupata) kato cialo e golemichak. S namaliavane na daljinata na
<em class="quotelev1">> opashkite na sfq saobrazno skorostta laga malko vliza v granici
<em class="quotelev1">> (default-a ot 128 packets e too long za 64kbps napr.), no vse 
<em class="quotelev1">> oshte ne e
<em class="quotelev1">> "dostatachno" dobre ;-)
Mislil li si dali efekta s golemite delay-i ne se dylji na prekomerna
preupotreba na kapaciteta?
Primerno 64 kilobita s 10 aktivni (tegleshti) potrebitelq vseki ot koito
popada v otdelen service flow i imash 1500 baitovi paketi za vseki
potrebitel.
Ednoposochniq delay za prekarvane na edin paket kym 11-ti potrebitel
prez takava opashka e _sredno_ 2 sekundi. Delay-a idva ot tova che
trqbva vseki potrebitel da byde obslujvan i ne mojesh da obslujvash
po-malko ot quantum (minimum 1500 bytes) na potrebitel.
Ta ako imash prekomerna preupotreba na kapaciteta, t.e. mnogo
potrebiteli za koito imash paketi chakashti na opashka pri teb ne mojesh
da reshish problema sys zakysneniqta po prostata prichina che vsichki
potrebiteli trqbva da bydat obslujeni.
Ima nachin da dropish paketi pri preupotreba ot nqkoj potrebitel, no
taka ili inache ne mojesh da pazish po-malko ot edin paket na opashka na
potrebitel, koeto e dostatychno za da se vdigne delay-a do nebesata, v
sluchaj che imash seriozno pretovarvane.

BR,
Boyan
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================