On Tuesday 27 December 2005 21:51, Leo Bogert wrote: > $addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492 > > $addclass parent $cMAIN classid $cEMULE htb rate 8kbps ceil $IFUP prio 4 > $addclass parent $cMAIN classid $cAPACHE htb rate 32kbps ceil $IFUP prio 2 > $addclass parent $cMAIN classid $cDEFAULT htb rate $IFUP burst 6k prio 1 So, the parent class offers $IFUP rate, but the children are trying to use 8kbps+32kbps+$IFUP. It's hard to tell what HTB will do in this case. > As you can see, eMule can use all bandwidth as long as nobody is requesting > something from the webserver. If somebody is downloading from the server, he > should receive 32kbps and eMule should be slowed down. Yes, apache should be able to receive 32kbps, emule 8kbps, and everything else the full bandwidth, all together at all times. But since there is not that much bandwidth available (it's just $IFUP in total after all), something has to give way. > BUT now I have checked the speed of my webserver, and when eMule is running > it is only at 4 kb/s instead of 32 kb/s. > > AND I have found the reason for this: If I remove the SFQs, scheduling > seems to work - at least at the "bad precision" of HTB: Apache receives over > 20 kb/s and eMule is limited to 12 kb/s instead of 8. The way I understand HTB, your class structure is simply overallocated, and the results you get from that are random at best. Before continuing, you should make sure that the sum of children class rates is equal to the parent class rate. > Martin Devera told me that it is wrong that the sum of the child-HTB's > rates is larger than my interface speed. Well, I reconfigured to have > the sum equal the available bandwidth and even then QoS did not work. Well, if even the author says so, you should heed his advice. :-) Even if this is not the main problem in your case, keeping this kind of HTB tree around won't make things better. Could you post your reconfigured setup, possibly with proper class names and rates instead of variables that could be anything? Regards, Andreas Klauer _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
