hello again,

I got some just preliminary results .... hope someone can explain them to me...
As I already told I have the following config :

egress {
	class (30kbps) {sfq};
	class (50kbps) {sfq};
	class (80kbps) {sfq};
	class (30kbps) {sfq};
	class (50kbps) {sfq};
	...hundreds like this...
	class (10kbps,default) {sfq};
}

What I got is traffic starvation very often for a period of  ~30 sec.. as
proposed I've done :

egress {
	...hundreds classes...
	class (10kbps, prio 7, default) {sfq};
}

It seemed a litlle bit better the starvation seemed to be just ~10sec but this
time happen much often...
then I made a final touch :

egress {
	...hundreds classes...
	class (55kbps, prio 7, default);
}

No "sfq" this time and it seemed much much better now...
I have done my tests mostly with :

hping2 host-behind-qos --fast --icmp
fping host1 host2 -l

I made second and third test for very short periods of time so this is not a
final "say" of the success...

------------ ?! SO COULD U EXPLAIN ME WHY THIS HAPPEN ?!
--------------------------

And most importantly is there a better solution, I don't know what will happen
if I want more complex solution but not this flat structure...
Or at least give me some directions how to go further and eradicate this
"STARVATION" problem..

Can I lower "class (55kbps, prio 7, default);" to "class (10kbps,
prio 7, default);" ....
Giving more bandwith to DEFAULT class is not solution but a ANTI-SOLUTION, my
idea is not to give all my bandwith to spammers and viruses :")

Expecting explanation :"))

tia

Hello raptor,

Sunday, October 19, 2003, 2:53:19 AM, you wrote:

At me latest class:
tc filter add dev eth1 parent 1:0 protocol ip prio 200 u32 match ip dst
0.0.0.0/0 police rate 1kbit burst 1k drop flowid 1:0


r> hello again,

r> I got some just preliminary results .... hope someone can explain them to
me...
r> As I already told I have the following config :

r> egress {
r>         class (30kbps) {sfq};
r>         class (50kbps) {sfq};
r>         class (80kbps) {sfq};
r>         class (30kbps) {sfq};
r>         class (50kbps) {sfq};
r>         ...hundreds like this...
r>         class (10kbps,default) {sfq};
r> }

r> What I got is traffic starvation very often for a period of  ~30 sec.. as
proposed I've done :

r> egress {
r>         ...hundreds classes...
r>         class (10kbps, prio 7, default) {sfq};
r> }

r> It seemed a litlle bit better the starvation seemed to be just ~10sec but
this time happen much often...
r> then I made a final touch :

r> egress {
r>         ...hundreds classes...
r>         class (55kbps, prio 7, default);
r> }

r> No "sfq" this time and it seemed much much better now...
r> I have done my tests mostly with :

r> hping2 host-behind-qos --fast --icmp
r> fping host1 host2 -l

r> I made second and third test for very short periods of time so this is not
a final "say" of the success...

r> ------------ ?! SO COULD U EXPLAIN ME WHY THIS HAPPEN ?!
--------------------------

r> And most importantly is there a better solution, I don't know what will
happen if I want more complex solution but not this flat structure...
r> Or at least give me some directions how to go further and eradicate this
"STARVATION" problem..

r> Can I lower "class (55kbps, prio 7, default);" to "class
(10kbps, prio 7, default);" ....
r> Giving more bandwith to DEFAULT class is not solution but a ANTI-SOLUTION,
my idea is not to give all my bandwith to spammers and viruses :")

r> Expecting explanation :"))

r> tia








r> _______________________________________________
r> LARTC mailing list / LARTC@mailman.ds9a.nl
r> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/



--
Best regards,
 nuclearcat                            mailto:nuclearcat@nuclearcat.com