Re: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
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:#roottc qdisc add dev $DEV root handle 1: htb default 122#main rate limitertc 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#gamestc 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-gamestc 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 10tc qdisc add dev $DEV parent 1:121 handle 121: sfq perturb 10tc qdisc add dev $DEV parent 1:122 handle 122: sfq perturb 10tc 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.pngMy 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
RE: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
Jody Shumaker wrote: > Also, when the problem is happening run this command: > tc -s class show dev ppp0 I 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. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC in Wireless Environment
Dnia wtorek, 27 grudnia 2005 23:10, Azim Samjani napisał(a): > Hi, > > Has anyone used TC in a wireless environment, which is dynamic. I > understand that the parameters for queuing are static and cannot be changed > unless the queuing discipline is deleted and reloaded with different > parameters. > > If anyone can share any experience, that would be helpful. Hello! I'm not sure if I fully understand Your problem but tc is able to change specified class without destroying all classes and disciplines on network interface. I use perl and php webpanel for setting up speed limits for my clients. Loading all tc rules for all interfaces (and imqs) after every single change is very slow, but I am able to change the one I need after changing settings of one client with `tc class change`, after which I put all the stuff that normally goes with `tc class add`. -- | pozdrawiam / greetings | powered by Trustix, Gentoo and FreeBSD | | Kajetan Staszkiewicz | JID: [EMAIL PROTECTED] | |Vegeta | IMQ devnames: http://tuxpowered.net| `^' ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
Andreas Klauer wrote: > On Tuesday 27 December 2005 21:51, Leo Bogert wrote: >> $addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492 >> >> classid $cEMULEhtb 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 $cEMULEhtb 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 24bit 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 8bit 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 24bit ceil 384000bit burst 1719b cburst 1791b Sent 2181127 bytes 2032 pkts (dr
Re: [LARTC] class exceeds its ceil
On Tuesday 27 December 2005 23:34, Jody Shumaker wrote: > Also, that email is partially incorrect. Nothing done in that email > will prevent lending from the 1:40 to the 1:2 class and subclasses. The way I see it, the email is correct. A class that has the same rate and ceil will never borrow, simply because it does not have to. As for lending, that will happen only if one of it siblings wants to borrow bandwidth. As for children classes, they are restricted by their parent. They cannot take bandwidth from outsiders, unless their parent borrows it for them. That does not help the original poster in any way, however. Sorry for this useless message. ;-) Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
Also, when the problem is happening run this command:tc -s class show dev ppp0And 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. - JodyOn 12/27/05, Andreas Klauer <[EMAIL PROTECTED]> 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 $cEMULEhtb 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 touse 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 everythingelse the full bandwidth, all together at all times. But since there is notthat 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 tothe 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 thiskind of HTB tree around won't make things better.Could you post your reconfigured setup, possibly with proper class namesand rates instead of variables that could be anything? Regards,Andreas Klauer___LARTC mailing listLARTC@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
[LARTC] PMTU - ICMP type 3/subtype 4 on 2.4.x
Hello,
I try to set up my
Linux 2.4.x system to respond by "ICMP Destination
Unreachable message" subtype 4 ("fragmentation needed and DF set") in order
to support the Path MTU Discovery (RFC 1191) as a router.
There is any /proc/xxx parameter to do
this?
Thanks
Mugur
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] class exceeds its ceil
On 12/27/05, Ratel <[EMAIL PROTECTED]> wrote:
Jody Shumaker wrote:> Andreas Klauer wrote:>>Uh... huh? Your P2P class has 100kbit rate with a 5600kbit ceil,>but you say you don't want it to borrow bandwidth from other classes.>However, to go over the 100kbit rate, it _has_ to borrow.
>Oh yes, my mistake - I've confused ceil with rate. Anyway, the thing Iwanted to achieve was to allowp2p class to use even 5600kbit of my bandwidth, but without guaranteeslike rate. So guarantee a minimum bandwidth to a class - about 100kbit,
but allow it to reach 5600kbit or more e.g. when there's no other traficpresent. (Now I know I did it wrong)I believe you did this portion correctly. ceil is the hard limit, the rate is the guarentee. Class will use up to its rate, then after that it will borrow up to its ceil. What confused him was that you said you didn't want p2p to borrow from the other classes. If its to go above 100kbit, it has to borrow. However it should never borrow guarenteed rate bandwidth they are using.
>So, if you don't want it to borrow like you said, the solution would>be to set the ceil of the P2P class to 100kbit as well. The other
>classes will still be able to borrow from it if the P2P class is not>using it's bandwidth.>>Are you sure? In my previous post I was refering to this example
http://mailman.ds9a.nl/pipermail/lartc/2002q2/003958.htmlwhich says this class won't be able to exchange any bandwidth at all.And in that example, rate and ceil are set to the same value, which means it will use up to its rate and never try to borrow more. You seem to want it to be able to borrow, but not up to the full connection, only up to ~75%. Also, that email is partially incorrect. Nothing done in that email will prevent lending from the 1:40 to the 1:2 class and subclasses. However, I don't think this is a problem for you. If no p2p, then what is wrong with lending the 100kbit.
> Jody Shumaker wrote:> What are you basing this on? the P2P app or tc -s class show dev ?
I simply block p2p traffic for some time and see that bandwidth usage(according to iptraf) falls down to ~20% of total link's "capacity" +classes that are supposed to send p2p traffic send nothing. (I also get
feedback that indeed p2p apps aren't working) After allowing p2pthrough, bandwidth usage jumps to ~100% of the total available bandwidth.> Are you using thee CONNTRACK module? It's simple to block P2P without
> CONNTRACK but if you want to shape it, you need it. Otherwise you'll> only be marking the first packets for p2p connections, and not the rest.I am aware of that, but didn't you mean CONNMARK target (module)?
WOops :) yeah I meant CONNMARK. It sounds like your htb classes are setup perfectly fine, you should really check the tc statistics and see how things are actually being classified. I'm using CONNMARK like this to mark p2p:
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-markiptables -t mangle -A PREROUTING -p tcp -m mark --mark $MARKP2P -j ACCEPTiptables -t mangle -A PREROUTING -m ipp2p --bit --edk --kazaa --gnu --dc -j MARK --set-mark ${MARKP2P}
iptables -t mangle -A PREROUTING -p tcp --dport 3010 -j MARK --set-mark ${MARKP2P}iptables -t mangle -A PREROUTING -p tcp -m mark --mark ${MARKP2P} -j CONNMARK --save-markiptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
Personally, I don't have much experience with IMQ and have only been shaping upload, but I've done something similar and it works fine. I cap P2P to only 95% of the upload (used to be 85%) and give it a guarenteed rate of only 4kbit. It will use its full 95%, but as soon as I use something else, i'll use 100% of the line and as much as possible for the non P2P traffic.
http://webpages.charter.net/falconx/eth1-50-tc-cumulative.pngThis image shows how this ends up working in reality for me, orange is P2P, blue is default, and red is priority.
I'm not sure on the exact command to use for an imq, but possibly something like `tc -s class show dev imq0`? However from what I know right now, it seems like you've setup things very similar to how I have for upload which I know works.
- Jody
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] TC in Wireless Environment
Hi, Has anyone used TC in a wireless environment, which is dynamic. I understand that the parameters for queuing are static and cannot be changed unless the queuing discipline is deleted and reloaded with different parameters. If anyone can share any experience, that would be helpful. Thanx. Azim. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
On Tuesday 27 December 2005 21:51, Leo Bogert wrote: > $addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492 > > $addclass parent $cMAIN classid $cEMULEhtb 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] Yet another htb rules generator
Dears I wrote a small program that converts a ASCII hierarchical HTB model (nice name, no!) to those nasty bunch of tc statments. It is a 0.0.0-prealpha code so be gentle! ;-) This means a lots of buffer overflows and the like. I am not worried with these by now. My concern is: is this a good idea? any future on that? is it a duplicated effort? Would somebody tell me if it could be of some help? I would not like to waste more time on this if it will be of no help. The code still has vestiges from some earlier unsuccessful tests. http://www.inexo.com.br/~ethy/htbgen-0.0.0-prealpha.tar.gz Regards 5 days to go!! -- Ethy H. Brito /"\ InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL S.J.Campos - Brasil / \ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] 2.6.14 - HTB/SFQ QoS broken?
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 $cEMULEhtb 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 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] class exceeds its ceil
Jody Shumaker wrote: Andreas Klauer wrote: Uh... huh? Your P2P class has 100kbit rate with a 5600kbit ceil, but you say you don't want it to borrow bandwidth from other classes. However, to go over the 100kbit rate, it _has_ to borrow. Oh yes, my mistake - I've confused ceil with rate. Anyway, the thing I wanted to achieve was to allow p2p class to use even 5600kbit of my bandwidth, but without guarantees like rate. So guarantee a minimum bandwidth to a class - about 100kbit, but allow it to reach 5600kbit or more e.g. when there's no other trafic present. (Now I know I did it wrong) So, if you don't want it to borrow like you said, the solution would be to set the ceil of the P2P class to 100kbit as well. The other classes will still be able to borrow from it if the P2P class is not using it's bandwidth. Are you sure? In my previous post I was refering to this example http://mailman.ds9a.nl/pipermail/lartc/2002q2/003958.html which says this class won't be able to exchange any bandwidth at all. Jody Shumaker wrote: What are you basing this on? the P2P app or tc -s class show dev ? I simply block p2p traffic for some time and see that bandwidth usage (according to iptraf) falls down to ~20% of total link's "capacity" + classes that are supposed to send p2p traffic send nothing. (I also get feedback that indeed p2p apps aren't working) After allowing p2p through, bandwidth usage jumps to ~100% of the total available bandwidth. Are you using thee CONNTRACK module? It's simple to block P2P without CONNTRACK but if you want to shape it, you need it. Otherwise you'll only be marking the first packets for p2p connections, and not the rest. I am aware of that, but didn't you mean CONNMARK target (module)? W ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] class exceeds its ceil
Ratel wrote: it exceeds its ceil and reaches the rate of my internet link What are you basing this on? the P2P app or tc -s class show dev ? Are you using thee CONNTRACK module? It's simple to block P2P without CONNTRACK but if you want to shape it, you need it. Otherwise you'll only be marking the first packets for p2p connections, and not the rest. - Jody ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] class exceeds its ceil
On Tuesday 27 December 2005 13:33, Ratel wrote: > I need to allow other classes to borrow bandwidth from a p2p class, but > I do not want to allow a p2p class to borrow bandwidth from other > classes. Is there a way to achieve it ? maybe I should redesign > something in the above diagram. Uh... huh? Your P2P class has 100kbit rate with a 5600kbit ceil, but you say you don't want it to borrow bandwidth from other classes. However, to go over the 100kbit rate, it _has_ to borrow. So, if you don't want it to borrow like you said, the solution would be to set the ceil of the P2P class to 100kbit as well. The other classes will still be able to borrow from it if the P2P class is not using it's bandwidth. If this does somehow not seem to be what you want, please restate your requirements. :-) Kind regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] class exceeds its ceil
Hi, I have a setup like this: class 1:1 rate 7600kbit (on a imq device) | |\class 1:10 rate 100kbit ceil 5600kbit prio 7 (here goes p2p traffic) \class 1:12 rate 7500kbit ceil 7600kbit | |\class 1:121 rate 3100 ceil 7500kbit prio 0 |\class 1:122 rate 2200 ceil 7500kbit prio 2 \class 1:123 rate 2200 ceil 7500kbit prio 3 (default) My problem is: the 1:10 class consumes the whole bandwidth. This is caused by a massive p2p traffic. I've read similar posts on this list, and I can't use the solution proposed by Stef Coene here: http://mailman.ds9a.nl/pipermail/lartc/2002q2/003958.html. I match p2p packets with both ipp2p and layer7 filters and mark them with iptables MARK. I can easily block p2p traffic, but when I allow it - it exceeds its ceil and reaches the rate of my internet link, which is unacceptable. I need to allow other classes to borrow bandwidth from a p2p class, but I do not want to allow a p2p class to borrow bandwidth from other classes. Is there a way to achieve it ? maybe I should redesign something in the above diagram. W ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] queue placing
yes, I thought so thanks...On 12/27/05, Denis Ovsienko <[EMAIL PROTECTED]> wrote: > My question is, if I QOS the traffic on the LINUX-ROUTER going out> from the LAN towards the frame relay cloud, and this traffic is> re-queued on the CISCO-ROUTER ... this would make all of my shapping If you don't configure QoS at cisco router, it will process packets on aFIFO basis. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] luca buratti è assente dall'ufficio.
Sarò assente dall'ufficio a partire dal 26/12/2005 e non tornerò fino al 09/01/2006. Risponderò al messaggio al mio ritorno. Trend Scan Mail: this message is virus free. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
