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 0bcburst 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: -59999999 ctokens: -59999999How 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
On Tue, 19 Jul 2005 07:52:03 +0200 nik39_nospam@usenet.entertain-men.de wrote:> 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 0b3000bit you probably mean 3000kbit? R. -- ___________________________________________________________________ It''s so simple to be wise. Just think of something stupid to say and say the opposite. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht | | Public key and email address: | | http://www.lucassen.org/mail-pubkey.html | +------------------------------------------------------------------+
Zitat von richard lucassen <mailinglists@lucassen.org>:> > 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
Hi, nik39_nospam@usenet.entertain-men.de 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/
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>:> > 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 ACK SSH http 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 140000bit 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
On Tuesday 19 July 2005 12:54, nik39_nospam@usenet.entertain-men.de 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 4By 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
Andreas Klauer <Andreas.Klauer@metamorpher.de>:> On Tuesday 19 July 2005 12:54, nik39_nospam@usenet.entertain-men.de 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
On Tuesday 19 July 2005 15:51, you wrote:> 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?Yes. The only rules for the ceil should be that it''s the same or bigger than the rate, and that it does not exceed the parent''s ceil.> ## non voip > /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate > 364kbit ceil 364 prio 1^ Unit is missing, might cause problems.> ## 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 4This time, the sum is lower than the parent. This is not nearly as bad as having a too high sum; together with the prio it can even make sense if it''s intentional. I''m just commenting because you should be aware of it, that''s all. If this was my script, I''d add a comment explaining as to why it is done this way. HTH Andreas
Andreas Klauer <Andreas.Klauer@metamorpher.de>:> Yes. The only rules for the ceil should be that it''s the same or bigger > than the rate, and that it does not exceed the parent''s ceil.Thanks for the info. Its not clearly enough stated in the HTB "manual".> > ## non voip > > /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate > > 364kbit ceil 364 prio 1 > ^ Unit is missing, might cause problems.Yeah, I messed copy+paste again.> This time, the sum is lower than the parent. This is not nearly as bad as > having a too high sum; together with the prio it can even make sense if > it''s intentional. I''m just commenting because you should be aware of it, > that''s all. If this was my script, I''d add a comment explaining as to why > it is done this way.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. So, for me its fine if the proportion would be kept. Anyhow, in this special case this doesnt matter at all, cause I would like to have priorized traff. I think I will start a new thread as the original problem why I started this thread is solved. And then I will make sure I post my original script with comments etc. nik
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
Quoting Andreas Klauer <Andreas.Klauer@metamorpher.de>:> 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