Hello, First of all, I already contacted Martin Devera, the developer of HTB, and he told me to search for help on this mailinglist, thus I am describing my problems here now... I am kind of seriously annoyed by QoS as I have been trying for over 3 years to get it working properly - first I did not understand how it works, then it seemed not to work, then it was working perfectly for half a year, or at least it seemed to do so, and now it seems to be broken. I have read so many QoS HOWTOs and I''m quite sure that I have understood the default approach for upstream bandwidth limiting/prioritizing - it is always the same in these HOWTOs: A root HTB qdisc is added to the network interface. This HTB receives a child class HTB to allow bandwidth sharing between the different classes (for example peer2peer, ftp, etc.). The actual HTB leaf classes are then attached to this class. These leaf classes finally each receive a SFQ which serves the purpose of fair queueing AND giving a package queue to HTB so that it does not have to drop packets. Here is my implementation of it: IFUP=48kbps tc qdisc add ppp0 root handle 1:0 htb default 20 r2q 4 $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 $addqdisc parent $cEMULE handle 10: sfq perturb 10 $addqdisc parent $cAPACHE handle 20: sfq perturb 10 $addqdisc parent $cDEFAULT handle 30: sfq perturb 10 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. Normal traffic (browser requests, multiplayer gaming, etc.) should receive all bandwidth if necessary, and have the highest priority, thus allowing good ping times. Well, I have written that script about half a year ago, and back then it was working well, and I even installed a linux router for someone and there it is still working. 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. Now what exactly is the reason for this? I thought it was absolutely normal to have these SFQ queues? Removing them is no solution because HTB starts dropping packets then. 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. And finally the most weird fact: On the other box where I have installed my QoS script it is still working properly. When Apache is uploading, eMule is slowed down to 4kb/s. So I copied the script back to my box and there it does not work!? I did not change the configuration of my linux router very much, I only usually update all packages with aptitude and install the latest kernel myself. Feel free to ask many questions, and thanks for your help, Leo Bogert
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 1So, 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
Also, when the problem is happening run this command: tc -s class show dev ppp0 And email those results? With correct rates that don''t add upto more than the parent, HTB should be working fine. Output of this command will show if the problem is with HTB, or instead how you''re classifying packets. Could very well be everything is going into the wrong subclasses. - Jody On 12/27/05, Andreas Klauer <Andreas.Klauer@metamorpher.de> wrote:> > 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@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Andreas Klauer wrote:> On Tuesday 27 December 2005 21:51, Leo Bogert wrote: >> $addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492 >> >> classid $cEMULE htb rate 8kbps ceil $IFUP prio 4 >> classid $cAPACHE htb rate 32kbps ceil $IFUP prio 2 >> 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.When configuring this, I thought the priorities would make that work. They even DID that because it was working once. The whole point why I configured it like that: I (and everyone else probably) want the scheduler to be like: "Give all bandwidth to eMule if nothing else is running. If miranda filetransfer is running give all bandwidth to it UNLESS Apache is running, then Apache should receive all bandwidth." This is not possible if the bandwidth reservations dont overlap, is it? Or can anyone tell me a different qdisc / solution which allows this?>> 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.I did that for testing purposes, and it still does not work. Results follow below...> Could you post your reconfigured setup, possibly with proper > class names and rates instead of variables that could be anything?In this case, Miranda (instant messenger equal to ICQ) filetransfer is used for testing instead of Apache. The following script works, the assignment of the packages to the classes by the firewall also works (has been working for years :), output of tc show follows also. -------------------------------- IF=dev ppp0 IFUP=48kbps cMAIN=1:1 cEMULE=1:11 cMIRANDA=1:13 cDEFAULT=1:20 q1="quantum 1492" q2="quantum 2984" addc="tc class add $IF parent" addq="tc qdisc add $IF parent" tc qdisc add $IF root handle 1:0 htb default 20 r2q 4 $addc 1:0 classid $cMAIN htb rate $IFUP mtu 1492 $addc $cMAIN classid $cEMULE htb rate 8kbps ceil $IFUP $q1 prio 5 $addc $cMAIN classid $cMIRANDA htb rate 30kbps ceil $IFUP $q2 prio 2 $addc $cMAIN classid $cDEFAULT htb rate 10kbps ceil $IFUP burst 6k $q2 prio 1 $addq $cEMULE handle 10: sfq perturb 10 $addq $cMIRANDA handle 30: sfq perturb 10 $addq $cDEFAULT handle 90: sfq perturb 10 -------------------------------- Only eMule running, without upload limit: (eMule) class htb 1:11 parent 1:1 leaf 10: prio 5 rate 64000bit ceil 384000bit burst 1631b cburst 1791b Sent 4317513 bytes 4779 pkts (dropped 0, overlimits 0) rate 357184bit 50pps backlog 6p lended: 864 borrowed: 3909 giants: 0 tokens: -233470 ctokens: -59031 class htb 1:1 root rate 384000bit ceil 384000bit burst 1683b cburst 1683b Sent 4322505 bytes 4955 pkts (dropped 0, overlimits 0) rate 358768bit 51pps lended: 3909 borrowed: 0 giants: 0 tokens: -61335 ctokens: -61335 (Miranda) class htb 1:13 parent 1:1 leaf 30: prio 2 rate 240000bit ceil 384000bit burst 1719b cburst 1791b Sent 178 bytes 4 pkts (dropped 0, overlimits 0) rate 16bit lended: 4 borrowed: 0 giants: 0 tokens: 57344 ctokens: 37376 (default) class htb 1:20 parent 1:1 leaf 90: prio 1 rate 80000bit ceil 384000bit burst 6Kb cburst 1791b Sent 11666 bytes 178 pkts (dropped 0, overlimits 0) rate 976bit 1pps lended: 178 borrowed: 0 giants: 0 tokens: 625051 ctokens: 37376 -------------------------------- Miranda filetransfer started then and running for some time: (eMule) class htb 1:11 parent 1:1 leaf 10: prio 5 rate 64000bit ceil 384000bit burst 1631b cburst 1791b Sent 8932587 bytes 10702 pkts (dropped 0, overlimits 0) rate 221400bit 37pps backlog 9p lended: 2413 borrowed: 8280 giants: 0 tokens: -176116 ctokens: -27978 class htb 1:1 root rate 384000bit ceil 384000bit burst 1683b cburst 1683b Sent 11132785 bytes 13156 pkts (dropped 0, overlimits 0) rate 381240bit 57pps lended: 8336 borrowed: 0 giants: 0 tokens: -106565 ctokens: -106565 (Miranda) class htb 1:13 parent 1:1 leaf 30: prio 2 rate 240000bit ceil 384000bit burst 1719b cburst 1791b Sent 2181127 bytes 2032 pkts (dropped 0, overlimits 0) rate 155336bit 17pps lended: 1976 borrowed: 56 giants: 0 tokens: -40140 ctokens: -23550 class htb 1:20 parent 1:1 leaf 90: prio 1 rate 80000bit ceil 384000bit burst 6Kb cburst 1791b Sent 27726 bytes 431 pkts (dropped 0, overlimits 0) rate 952bit 1pps lended: 431 borrowed: 0 giants: 0 tokens: 617677 ctokens: 35840
Jody Shumaker wrote:> Also, when the problem is happening run this command: > tc -s class show dev ppp0I been using that one so often that I even forgot to mention it.> And email those results? With correct rates that don''t > add upto more than the parent, HTB should be working fine. > Output of this command will show if the problem is with > HTB, or instead how you''re classifying packets. Could very > well be everything is going into the wrong subclasses.The classes are assigned correctly by iptables using the classify target. You can also see that in my reply to Andreas Klauer.
> When configuring this, I thought the priorities would make that work. > They even DID that because it was working once. > The whole point why I configured it like that: > I (and everyone else probably) want the scheduler to be like: > "Give all bandwidth to eMule if nothing else is running. > If miranda filetransfer is running give all bandwidth to it > UNLESS Apache is running, then Apache should receive all bandwidth." > This is not possible if the bandwidth reservations dont overlap, is it? > Or can anyone tell me a different qdisc / solution which allows this?It''s undefined what happens when you overallocate, and is certainly not required to do what you want. ''rate'' is guarenteed rate, ''ceil'' is maximum bandwidth useable through borrowing, and ''prio'' is priority this class gets when borrowing bandwidth. You should give emule next to nothing for guarenteed, but with a ceil either the max bandwidth or very close. It is then guarenteed little, but will borrow up to its ceil. Then guarentee apache most, with some left for default. the prio will mean apache has first access to any borrowable bandwidth, then default, then emule. I would use something like this: IFUP=48 $addc $cMAIN classid $cEMULE htb rate 4kbps ceil ${IFUP}kbps $q1 prio 5 $addc $cMAIN classid $cMIRANDA htb rate 30kbps ceil ${IFUP}kbps $q2 prio 2 $addc $cMAIN classid $cDEFAULT htb rate $[$IFUP - 30 - 4]kbps burst 6k $q2 prio 1 I''m using something fairly similar: #root tc qdisc add dev $DEV root handle 1: htb default 122 #main rate limiter tc class add dev $DEV parent 1:0 classid 1:1 htb burst 30k rate ${UPLINK}kbit ceil ${UPLINK}kbit #high priority low bandwidth traffic (75% bandwidth guarentee) tc class add dev $DEV parent 1:1 classid 1:11 htb burst 30k prio 0 rate $[($UPLINK - 4) * 3 / 4]kbit ceil ${UPLINK}kbit cburst 4k #most traffic (25% bandwidth guarentee) tc class add dev $DEV parent 1:1 classid 1:12 htb burst 30k prio 1 rate $[($UPLINK - 4) / 4]kbit ceil $[$UPLINK - 16]kbit #no priority traffic (4kbit guarentee, ceil torrentpercent) tc class add dev $DEV parent 1:1 classid 1:13 htb prio 7 rate 4kbit ceil $[($UPLINK - 4) * $torrentpercent / 100]kbit #further split most traffic into game, and non-game #games tc class add dev $DEV parent 1:12 classid 1:121 htb burst 30k prio 1 rate $[(($UPLINK - 4) / 4) - 4]kbit ceil $[$UPLINK - 4]kbit #non-games tc class add dev $DEV parent 1:12 classid 1:122 htb burst 15k prio 6 rate 4kbit ceil $[$UPLINK - 4]kbit # tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 10 tc qdisc add dev $DEV parent 1:121 handle 121: sfq perturb 10 tc qdisc add dev $DEV parent 1:122 handle 122: sfq perturb 10 tc qdisc add dev $DEV parent 1:13 handle 13: sfq perturb 10 Few things i remember tweaking is increasing the burst for the higher priority classes. I found they were quicker to take over bandwidh and hold it that way. Could you possibly check emule off, and file transfer going? With my setup often even if I kill bittorrent downloads, other file transfers don''t go any faster. They''re not using up the full pipe because of the full route to the other person, nothing to do with p2p getting in the way. http://webpages.charter.net/falconx/ppp0-8-tc-cumulative.png My irc sends varied very little when a bittorrent download started, and then when an ftp transfer started with someone who can use most of my bandwidth you can see around 17:30 the blue spiked to using nearly all the bandwidth. - Jody _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> It''s undefined what happens when you overallocate, and is certainly not > required to do what you want. ''rate'' is guarenteed rate, ''ceil'' is maximum > bandwidth useable through borrowing, and ''prio'' is priority this class > gets when borrowing bandwidth. You should give emule next to nothing for > guarenteed, but with a ceil either the max bandwidth or very close. It is > then guarenteed little, but will borrow up to its ceil. Then guarentee > apache most, with some left for default. the prio will mean apache has > first access to any borrowable bandwidth, then default, then emule.It _does_ seem to be necessary that the guranteed rates overlap. Let me explain: I have 45 kb/s of upstream. I basically offer 4 services: eMule, FTP, Apache, Miranda filetransfer. To me, these four have different priorities: eMule should be consuming the whole bandwidth if nothing else is being used. If someone is downloading from FTP, he should take away most bandwidth from eMule, let''s say 32 kb/s. But then it might happen that I want to send a file to somebody via Miranda because he does not have an FTP account. Then the filetransfer has to be higher priority than the FTP transfer and receive about 30 kb/s, FTP and eMule should use the remaining bandwidth. But now it might also happen that - while somebody is downloading from FTP and a miranda filetransfer is running - I want to show a picture to someone which is stored on my webserver. Thus, Apache needs a guranteed rate of 30 kb/s, i.e. higher priority than FTP and filetransfer. Furthermore, while all this stuff is happening, I might be gaming or browsing the web and for this I need a good response time. But I don''t know anything about the bandwidth requirement of games or webbrowsing, thus in my old script I gave a rate of $IFUP with priority 0 to the default traffic so that it can take anything which it needs. This complex situation with all classes being active at once shows quite clearly why I want to have overlapping guranteed bandwidths. It will never happen probably, but the situation that I''m running a Miranda filetransfer and want to show somebody a picture on Apache happens very often. The fact why I don''t like reserving bandwidth with the sum of child rates being _correct_ (not larger than available upstream) is that this would make me "lose" much bandwidth, look at this example which I created for testing: eMule rate 8kbps prio 5 FTP rate 4kbps prio 4 Miranda rate 12kbps prio 3 Apache rate 8kbps prio 2 Skype rate 6kbps prio 0 default rate 10kbps prio 1 The sum of the child rates is correct, but I cannot make Miranda or apache receive a guranteed 30 kb/s while eMule is running. Thus, some kind of overlapping might be necessary for a perfect scheduler. I hope it is possible to understand what I was aiming for now. Thanks, Leo Bogert
> Thus, some kind of overlapping might be necessary for a perfect > scheduler. > > I hope it is possible to understand what I was aiming for now. > > Thanks, Leo Bogert...Besides, let me stress again that even though I would prefer overlapping guranteed rates, the default usage of HTB with sum of child rates = parent rate just seems BROKEN for me as it does no scheduling at all, the logs in one of my last mail show that HTB completely ignores the bandwidth reservations. That problem is what I need a solution for :)
Have you run a comparison when emule isn''t running? As I mentioned before, even with emule off you may not be capable of sending any faster to those hosts. Did you also try adjusting the burst rates? Once again I stress that you do NOT need to over guarentee bandwidth. It still makes absolutely no sense to me, and your thinking is flawed. It is the rate guarenteed for that class, if you guarentee MORE bandwidth than there is, then it gets really ugly for HTB figuring out how to divvy up the bandwidth. Your goals are perfectly reachable by using correct guarenteed rates, priorities, and ceilings. You have a complex way you want bandwidth to be lended around, and you just need to set priorities and guarenteed rates with that in mind. In fact, you might want to consider the exct opposite setup. You should be thinking of guarenteed rate to be the rate you want a class to get if every single class is trying to and capable of using up to its ceil bandwidth. Anything beond guarenteed rate you should be thinking of adjusting prio and ceil. You should also consider that they don''t have to add up to the max rate, they just can''t go over it. It is perfectly acceptable for the guarenteed rates to be below the max, every class will just have to borrow to get the full rate. Also in your example you cited above, you didn''t use one of the things I suggested, guarenteeing practically no bandwidth for emule. You actually had it on par with apache and greater than skype or ftp. Why give it such a high guarentee? That doens''t fit at all with what you stated your target result as. I think the problem is likely either the transfers not capable of the full bandwidth regardless, or possibly something that can be adjusted by using the burst values as I mentioned. The defaults of ~1719b seem really poor for a lower priority fewer connections class to reclaim its bandwidth. However, testing any of this with incorrect guarenteed rates makes no sense to me. Just because it worked in the past doesn''t mean its the correct thing to do. The fact it isn''t working now certainly is not evidence that you want to use settings in a way where the result is undefined. So please understand that overlapping is not neccasary for your perfect scheduler, please focus on what "guarenteed" rate means. Please actually try my suggestions. Even try them in both cases of incorrect rates, and correct rates. Over guarenteeing I still don''t think is the best way to do things, but heck if with the burst settings or some such you can get it working how you want with over guarenteeing, then why mess with what works? I just want you to understand, it should not be neccasary. Also, I want to point out that with the tc statistics you last emailed, you''re shaping 384kbit, fairly close to the 512kbit I''m shaping. I''m getting the exact results you want, so you might want to take a look at my class setup. If even with a fairly identical setup you don''t get results, I wonder if its possibly a bug with your exact version of the kernel. - Jody On 12/28/05, Leo Bogert <spam-goes-to-dev-null@gmx.net> wrote:> > > Thus, some kind of overlapping might be necessary for a perfect > > scheduler. > > > > I hope it is possible to understand what I was aiming for now. > > > > Thanks, Leo Bogert > > ...Besides, let me stress again that even though I would prefer > overlapping guranteed rates, the default usage of HTB with > sum of child rates = parent rate just seems BROKEN for me > as it does no scheduling at all, the logs in one of my last > mail show that HTB completely ignores the bandwidth > reservations. That problem is what I need a solution for :) > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
On 12/28/05, Leo Bogert <spam-goes-to-dev-null@gmx.net> wrote:> > > It''s undefined what happens when you overallocate, and is certainly not > > required to do what you want. ''rate'' is guarenteed rate, ''ceil'' is > maximum > > bandwidth useable through borrowing, and ''prio'' is priority this class > > gets when borrowing bandwidth. You should give emule next to nothing for > > guarenteed, but with a ceil either the max bandwidth or very close. It > is > > then guarenteed little, but will borrow up to its ceil. Then guarentee > > apache most, with some left for default. the prio will mean apache has > > first access to any borrowable bandwidth, then default, then emule. > > It _does_ seem to be necessary that the guranteed rates overlap. > Let me explain: I have 45 kb/s of upstream. > I basically offer 4 services: eMule, FTP, Apache, Miranda filetransfer. > To me, these four have different priorities: eMule should be consuming > the whole bandwidth if nothing else is being used. If someone is > downloading from FTP, he should take away most bandwidth from eMule, > let''s say 32 kb/s. But then it might happen that I want to send a > file to somebody via Miranda because he does not have an FTP account. > Then the filetransfer has to be higher priority than the FTP transfer > and receive about 30 kb/s, FTP and eMule should use the remaining > bandwidth. But now it might also happen that - while somebody is > downloading from FTP and a miranda filetransfer is running - > I want to show a picture to someone which is stored on my webserver. > Thus, Apache needs a guranteed rate of 30 kb/s, i.e. higher priority > than FTP and filetransfer.Wrong, it doesn''t need a higher guarenteed rate. It only needs higher priority when borrowing bandwidth, and for there to be available bandwidth to borrow. If there''s no bandwidth to borrow, then you''re guarenteeing too much to other classes. Furthermore, while all this stuff is happening, I might be gaming> or browsing the web and for this I need a good response time. > But I don''t know anything about the bandwidth requirement of games > or webbrowsing, thus in my old script I gave a rate of $IFUP with > priority 0 to the default traffic so that it can take anything which > it needs.This is unneccasary. Setting a guarenteed rate , and then giving it an appropiate priority, it will use up to the full connection by borrowing. Also in my experience, depending on the game, they use 3-10kbyte/s. This complex situation with all classes being active at once> shows quite clearly why I want to have overlapping guranteed > bandwidths. It will never happen probably, but the situation that > I''m running a Miranda filetransfer and want to show somebody a picture > on Apache happens very often.It quite clearly shows, you need to think more closely how it works. You''re trying to use guarenteed rate to control lending/borrowing which is the wrong way to think of it. The fact why I don''t like reserving bandwidth with the sum of> child rates being _correct_ (not larger than available upstream) > is that this would make me "lose" much bandwidth, look at this > example which I created for testing: > > eMule rate 8kbps prio 5 > FTP rate 4kbps prio 4 > Miranda rate 12kbps prio 3 > Apache rate 8kbps prio 2 > Skype rate 6kbps prio 0 > default rate 10kbps prio 1 > > The sum of the child rates is correct, but I cannot make Miranda > or apache receive a guranteed 30 kb/s while eMule is running. > Thus, some kind of overlapping might be necessary for a perfect > scheduler.You don''t do this through guarenteed rate, you instead do this with priority on who gets dibs on free bandwidth first. Having a higher priority, a class should use up to its ceil if the bandwidth is available to be borrowed. If all the bandwidth is over allocated as guarenteed then there is nothing to borrow from! Think of it this way, say every single class is trying to use up to its ceil in bandwidth. When the base class has available bandwidth, it is going to look at all of its subclasses to choose who to grab a packet from. With over guarenteed rates, it may negelect classes because it will always grab packets from other classes since they haven''t gone over their guarenteed rate. With your setup, say 30kb/s for apache. If an apache and ftp both start they may consume ALL of the bandwidth and completely starve things you don''t want it to, like voice or games. The problem with over guarenteeing is that all of HTB''s rules on lending/borrowing get bypassed and instead things just get allocated randomly. I''m sorry for the double email, but I think my previous one was sent too early in the morning before I could think. I really want to explain in a way you can understand why over guarenteeing is not something you want. Now, as for your actual problem, I don''t think overguarenteeing is even becoming an issue based on the tc -s class show dev results you posted. As I mentioned in the other emails, the basis of where i think the problem you''re seeing is has to do with how TCP throttles bandwidth itself. Either the transfer can''t perform any faster regardlesss of eMule, OR it can but the burst setting should be tweaked. I''ve found that with some people, the transfers tend to be very bursty. I can get 70% of my bandwidth used on average for them, but it varies between 40% and 100%. With a small default burst, and the bandwidth otherwise used what will tend to happen is the tcp transfer will cap out instead near the 40%. If i increase the burst size for higher priority classes, they have a better chance of bursting to 100% of the bandwidth occasionally to give a better average rate. Based on how I''ve gotten things working with my setup, I would suggest these changes to your script atleast for testing: tc qdisc add $IF root handle 1:0 htb default 20 r2q 4 $addc 1:0 classid $cMAIN htb rate $IFUP mtu 1492 burst 30k $addc $cMAIN classid $cMIRANDA htb rate 30kbps ceil $IFUP $q2 prio 2 burst 30k $addc $cMAIN classid $cDEFAULT htb rate 10kbps ceil $IFUP burst 6k $q2 prio 1 $addc $cMAIN classid $cEMULE htb rate 4kbps ceil $IFUP $q1 prio 5 And as previously mentioned, check tc -s class show dev $IF results for atleast these 2 scenarios, ftp only, ftp and emule. Checking emule only might be useful to make sure it behaves as you want, but your previous stats missed the important comparison. You really want to be sure that ftp or whatever gets the same bandwidth with emule on or off. Your last stats only showed that emule will use up what''s available, and gave no basis to know if the ftp portion was working correctly or not. The ftp only portion would give the comparison you need to see if it is working. I hope I''m not ranting too much, and that some of this is understandable. - Jody _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc