Re: [LARTC] Problem with HTB and ceil
Quoting Andreas Klauer [EMAIL PROTECTED]: I might've misunderstood you here, but just in case: The HTB prio parameter affects borrowing priority, not packet priority. You mean priority after the guaranteed bitrates have been fullfilled. Which basically means that the proportions which you'd get if all classes had the same priority, will look much different. In other words, low priority classes will not get any bandwidth except their guaranteed rate, as long as a higher priority class is borrowing. More precisely, after the guaranteed bandwidhts have been assigned the excess bandwidth will be spread to the highest prio class first until the ceiling is reached and then any remainin will be assigne to the next highes prio class and the same procedure is repeated until the bandwidht is 0. Correct? If so, that is exactly what I am trying to achieve. Personally, I only use the HTB prio for unwanted traffic class (P2P), because I find that for normal traffic, the restriction is too harsh. This is why I recommend not using the HTB prio parameter at all in the beginning, and only start experimenting with it when you really need it. I think I really need it ;-) But I have observed something else, it looks like if I use two different IP A and B where I sent packets to, and mark those packets with the correct different marks, I can see how the prio works, one of the flows is almost drown by the other as expected from my prio config. So, it _might_ be a problem in the way how I tag the packets. If you remember I had the ACK class which should have prio 1, and I matched them with following rules: iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags ! SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m length --length 0:48 -j MARK --set-mark 200 Is it possible that still some ACKs are not marked correctly? And if so, how would such a set of rules look like to catch all ACK packets? Thanks for your help! nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
Zitat von richard lucassen [EMAIL PROTECTED]: I am trying to setup a shaper for my linux box and I am experiencing some problems. What I am trying to do is priorizing packets on the egress link, therefore I have setup some prio classes etc. The priorizing seem to work but the problem is that the ceil parameter doesnt seem to work on non leafs. This is what stats show: class htb 1:1 root rate 3000bit ceil 3000bit burst 1602b/8 mpu 0b 3000bit you probably mean 3000kbit? No, for debugging purposes I have limit it to 3kbps, to test what is going on. nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
Hi, [EMAIL PROTECTED] schrieb: the problem is that the ceil parameter doesnt seem to work on non leafs. IIRC that is by design. Some time ago, it was explained on this list in a much better way than I could do it now. Regards, Carl-Daniel -- http://www.hailfinger.org/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
Carl-Daniel Hailfinger [EMAIL PROTECTED]: the problem is that the ceil parameter doesnt seem to work on non leafs. IIRC that is by design. Some time ago, it was explained on this list in a much better way than I could do it now. Yes, thanks I found something but I am not sure how to interpret what has been said. It has been said that if the child classes summed up exceed the bitrate of the parent class then the parent ceil setting will be ignored. Now I am not sure if that only applies to the sum of the minimum bitrate or also of the summed ceil bitrates of all child classes. Let me explain what I am trying to achieve: I have a link with 384kbps upstream, I want voip traffic to have the highest prio, they should always leave the upstream first with a ceil limit of 96kbps which is more than enogh, min 16kbit (should matter cause its priorized anyway). Next priority should be ACK packets, they should have a ceil limit of (380-16) 364kbit, default bitrate of 140. This should ensure that downloads are not affected by any outgoing traffic except the voip traffic. SSH traffic is next, I reserved a minimum bitrate of 16kbit with a ceiling of 364, then I got http traffic again with min bitrate 16kbit, ceil limit of 364 and at last bulk traffic, with a min bitrate 16kbit and ceil limit of 364: o root 1:0 | + 1:002 /| || 1:101 | __+__ | | | | | | | | | | | | | | | voip ACKSSHhttp bulk pr 0 pr 1 pr 2 pr 3 pr 4 1:100 1:200 1:300 1:300 1:400 What I have achieved so far is that voip is really priorized agains all other classes. But priorizing the right half does not work, means ACK class has not higher prio than the others. My config so far: ## Root /sbin/tc qdisc add dev $EXTIF root handle 1:0 htb default 400 /sbin/tc class add dev $EXTIF parent 1:0 classid 1:002 htb rate 380kbit ceil 380kbit ## voip /sbin/tc class add dev $EXTIF parent 1:002 classid 1:100 htb rate 16kbit ceil 96kbit prio 0 ## non voip /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil 364 prio 1 ## ACK /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil 364kbit prio 1 ## SSH /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 140kbit ceil 364kbit prio 2 ## http/https traffic /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 140kbit ceil 364kbit prio 3 ## bulk /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 140kbit ceil 364kbit prio 4 Stats show: class htb 1:200 parent 1:101 leaf 200: prio 1 quantum 1750 rate 14bit ceil 364000bit burst 1774b/8 mpu 0b overhead 0b cburst 2066b/8 mpu 0b overhead 0b level 0 Sent 280764 bytes 4995 pkts (dropped 0, overlimits 0) lended: 4995 borrowed: 0 giants: 0 tokens: 79347 ctokens: 34819 class htb 1:500 parent 1:101 leaf 500: prio 6 quantum 1000 rate 16000bit ceil 364000bit burst 1619b/8 mpu 0b overhead 0b cburst 2066b/8 mpu 0b overhead 0b level 0 Sent 3351886 bytes 3165 pkts (dropped 0, overlimits 0) rate 256bit lended: 150 borrowed: 3015 giants: 0 tokens: 237570 ctokens: 17997 As you can see the :200 class (ACK packets) have much lower bitrate than the :500 (bulk packets), which slows down my downloads. Any hints? nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
On Tuesday 19 July 2005 12:54, [EMAIL PROTECTED] wrote: /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil 364 prio 1 ## ACK /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil 364kbit prio 1 ## SSH /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 140kbit ceil 364kbit prio 2 ## http/https traffic /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 140kbit ceil 364kbit prio 3 ## bulk /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 140kbit ceil 364kbit prio 4 By looking at this script, you have a class 1:101 with 364kbit rate, 364 ceil (missing unit!), and it's children got (140+140+140+140)kbit = 560kbit rate. I haven't followed the prior discussion, so this might be intentional or not, but in any case, I don't recommend using HTB that way. It's much easier to tell what is happening when you make sure that your rates always add up properly. That is, the sum of the child class rates should be the same as the parent class rate. HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
Andreas Klauer [EMAIL PROTECTED]: On Tuesday 19 July 2005 12:54, [EMAIL PROTECTED] wrote: /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil 364 prio 1 ## ACK /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil 364kbit prio 1 ## SSH /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 140kbit ceil 364kbit prio 2 ## http/https traffic /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 140kbit ceil 364kbit prio 3 ## bulk /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 140kbit ceil 364kbit prio 4 By looking at this script, you have a class 1:101 with 364kbit rate, 364 ceil (missing unit!), and it's children got (140+140+140+140)kbit = 560kbit rate. I haven't followed the prior discussion, so this might be intentional or not, but in any case, I don't recommend using HTB that way. It's much easier to tell what is happening when you make sure that your rates always add up properly. Just to make sure, when you talk about the sum you are talking about the sum of the minimum bitrates, not the sum of the ceil bitrates, right? That is, the sum of the child class rates should be the same as the parent class rate. Ah damned, that was a copy and paste problem, in fact I used the following script with the bitrates which I mentioned in the previous posts in my description. ## Root /sbin/tc qdisc add dev $EXTIF root handle 1:0 htb default 400 /sbin/tc class add dev $EXTIF parent 1:0 classid 1:002 htb rate 380kbit ceil 380kbit ## voip /sbin/tc class add dev $EXTIF parent 1:002 classid 1:100 htb rate 16kbit ceil 96kbit prio 0 ## non voip /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil 364 prio 1 ## ACK /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil 364kbit prio 1 ## SSH /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 16kbit ceil 364kbit prio 2 ## http/https traffic /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 16kbit ceil 364kbit prio 3 ## bulk /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 16kbit ceil 364kbit prio 4 Any idea? Did I miss something basic? nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
On Tuesday 19 July 2005 22:41, nik-da-39 wrote: Thanks for your comment. From my understanding, I dont rely too much on the exact minimum bitrate, as long as the prios are obeyed by the packets. ... Thats why I also dont need the sum of the min bitrates to be exactly the parental bitrate, if I understand it correctly the remaining abdnwidth after all minimum requirements have been fullfilled will be spread proportionally according to the allocations. ... I might've misunderstood you here, but just in case: The HTB prio parameter affects borrowing priority, not packet priority. Which basically means that the proportions which you'd get if all classes had the same priority, will look much different. In other words, low priority classes will not get any bandwidth except their guaranteed rate, as long as a higher priority class is borrowing. Personally, I only use the HTB prio for unwanted traffic class (P2P), because I find that for normal traffic, the restriction is too harsh. This is why I recommend not using the HTB prio parameter at all in the beginning, and only start experimenting with it when you really need it. HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Problem with HTB and ceil
Hi, I am trying to setup a shaper for my linux box and I am experiencing some problems. What I am trying to do is priorizing packets on the egress link, therefore I have setup some prio classes etc. The priorizing seem to work but the problem is that the ceil parameter doesnt seem to work on non leafs. This is what stats show: class htb 1:1 root rate 3000bit ceil 3000bit burst 1602b/8 mpu 0b overhead 0b cburst 1602b/8 mpu 0b overhead 0b level 7 Sent 770965 bytes 2139 pkts (dropped 0, overlimits 0) rate 178264bit 62pps lended: 0 borrowed: 0 giants: 0 tokens: -5999 ctokens: -5999 How can this be possible? From my understanding it shouldnt be possible to exceed the ceil bitrate, but this happens here. What did I overlook? What do these negative token counters mean? Thanks for your help in advance. nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
