Re: [LARTC] HTB deadlock
Greetings, Hi, I've been experiencing problems with HTB where the whole machine locks up. This usually happens when the whole qdisc is being removed and occasionally when a leaf is being removed. You may be interested in reading these two: http://bugzilla.kernel.org/show_bug.cgi?id=9318 http://bugzilla.kernel.org/show_bug.cgi?id=9632 cheers, Marek Kierdelewicz KoBa ISP ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB performance improvement
gypsy wrote: gypsy wrote: tc qdisc add dev eth0.2 root handle 1: htb tc class add dev eth0.2 parent 1: classid 1:1 htb rate 1 ceil 1 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:10 htb prio 1 rate 7000 ceil 7000 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:11 htb prio 2 rate 1000 ceil 1000 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:12 htb prio 3 rate 1000 ceil 1000 burst 100 quantum 1600 I just noticed that you're trying to shape aliases. You can't. You must shape eth0 because you can't shape eth0.2. I'm just repeating what I've heard/read, so do your own research. But I bet you a quarter I'm right :) -- Could be vlans - in which case OP could try adding child b/pfifos to the leafs and use the limit parameter to specify buffer length. HTB and HFSC both pick up default queuelengths from the device, but it's 0 on vlans (they use 2 or 3 packet pfifos IIRC in this case). I do notice there are no drops in the stats though, but it's still worth specifying queue length and type in the script. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB performance improvement
gypsy wrote: tc qdisc add dev eth0.2 root handle 1: htb tc class add dev eth0.2 parent 1: classid 1:1 htb rate 1 ceil 1 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:10 htb prio 1 rate 7000 ceil 7000 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:11 htb prio 2 rate 1000 ceil 1000 burst 100 quantum 1600 tc class add dev eth0.2 parent 1:1 classid 1:12 htb prio 3 rate 1000 ceil 1000 burst 100 quantum 1600 I just noticed that you're trying to shape aliases. You can't. You must shape eth0 because you can't shape eth0.2. I'm just repeating what I've heard/read, so do your own research. But I bet you a quarter I'm right :) -- gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb on Gigabit Interfaces
On 9/18/07, hhoxha [EMAIL PROTECTED] wrote: Hi every body I have a linux server with Intel(R) Xeon(TM) CPU 3.20GHz , and 2 Gigabit of RAM , kernel version 2.6.22.6 , and 2 Intel 82541PI Gigabit Ethernet controllers In simple situation i would like to limit bandwidth for 2 customers 1) ( to 34 Mb/s ) and 2) 68 Mb/s . My conf is as below / #IFACE FACONG THE CUSTOMERS /sbin/tc qdisc add dev eth0 root handle 1:0 htb #IFACE FACING THE INTERNET /sbin/tc qdisc add dev eth1 root handle 1:0 htb /sbin/tc class add dev eth0 parent 1:0 classid 1:1 htb rate 150mbit quantum 3 /sbin/tc class add dev eth1 parent 1:0 classid 1:1 htb rate 150mbit quantum 3 #second customer download /sbin/tc class add dev eth0 parent 1:0 classid 1:2 htb rate 68mbit ceil 68mbit quantum 3 try parent 1:1 #seconf customer upload /sbin/tc class add dev eth1 parent 1:0 classid 1:2 htb rate 68000kbit ceil 68000kbit quantum 3 and here # first customer download /sbin/tc class add dev eth0 parent 1:0 classid 1:3 htb rate 34mbit ceil 34mbit quantum 3 and here # first customer upload /sbin/tc class add dev eth1 parent 1:0 classid 1:3 htb rate 34mbit ceil 34mbit quantum 3 aand here #then iptable classify rules #TO_FIRST CUSTOMER /opt/sbin/iptables -t mangle -I POSTROUTING -o eth0 -d $DESTINATIONIP -j CLASSIFY --set-class 1:2 #FROM_FIRST CUSTOMER /opt/sbin/iptables -t mangle -I POSTROUTING -o eth1 -s $SOURCEIP -j CLASSIFY --set-class 1:2 #TO_SECOND CUSTOMER /opt/sbin/iptables -t mangle -I POSTROUTING -o eth0 -d $DESTINATIONIP -j CLASSIFY --set-class 1:3 #FROM_SECOND CUSTOMER /opt/sbin/iptables -t mangle -I POSTROUTING -o eth1 -s $SOURCEIP -j CLASSIFY --set-class 1:3 / For the customer with 34 Mb/s of bandwidth i can hardly reach 8 Mb/s and at this point i can notice an increased number of packets in the htb scheduler queue . With the tc ( htb disabled ) the line rate of nearly 100 Mb.s of the customer can be reached easily Is there any special tunning or conf that should be done considering the gig interfaces in place Thank you Hysen Hoxha AlbTelecom Albania ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Marco Casaroli SapucaiNet Telecom +55 35 34712377 ext. 5 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb : server trafficcontrol
On 16 Sep 2007, [EMAIL PROTECTED] wrote: Suppose we have simple router with upstream interface connected to internet (eth0) and downstream interface connected to lan (eth1). Lan uses private addressing so there is NAT rule used for traffic leaving eth0. You can redirect lan-internet traffic from ingress qdisc of eth1 to ifb0. Traffic on ifb0 will be in before-nat state, so private address based shaping will be possible. So no need for classifying de-nated traffic. Yes, this is of course possible. But then you don't shape the traffic from/to the server itself which is what the original poster wants to do. Some people here on lartc list shared opinions that shaping in ingress is not effective. It worked for me well on routers with hundreds of clients. It works for me quite well, too. (And IMHO would work really well if ECN would be in widespread use) (using IMQ + kernel 2.6.18 - as long as nobody floods me with UDP packets ;-) Greetings Jens ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb : server trafficcontrol
On 15 Sep 2007, [EMAIL PROTECTED] wrote: Hi everyone, I have a small problem. I have my debian server setup in my home. I have setup htb that is working perfectly. The only problem I have is to control the traffic server - internet I have a daemon (bittorrent) and I would like to limit its download to a certail amount. How can I do that ? I have tried layer7 but it seems I'm doing something wrong in the htb script. Any idea how to control that traffic (serv - net) Its the same problems with apt etc etc When I use it, it uses the entire amount of bandwidth... With Kind Regards Matt Assuming your server does NAT for your LAN you probably want to use IMQ http://www.linuximq.net/ Greetings Jens ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb : server trafficcontrol
Any idea how to control that traffic (serv - net) Its the same problems with apt etc etc When I use it, it uses the entire amount of bandwidth... You can shape download to server on ingress using IFB: http://linux-net.osdl.org/index.php?title=IFB IMQ could also be helpfull, but IFB is included in vanilla kernels. IMQ isn't and never will be. Cheers, Marek Kierdelewicz ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb : server trafficcontrol
On 15 Sep 2007, [EMAIL PROTECTED] wrote: You can shape download to server on ingress using IFB: http://linux-net.osdl.org/index.php?title=IFB But AFAIK at the moment practically only if there is no NAT involved (or if you do not want to classify de-nated traffic). Any news regarding this problem? Greetings Jens ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB does not respect the prio parameter
Is quantum not perhaps a bit high? Try setting it lower, and see what happens? -justin On 2007-08-29 08:06, Martin Björnsson wrote: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB does not respect the prio parameter
Martin Björnsson pisze: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 \ /bin/tc class add dev eth0 parent 1:0 classid 1:1 htb rate 55000kbit ceil 55000kbit quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1000kbit ceil 55000kbit prio 0 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1000kbit ceil 55000kbit prio 1 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1000kbit ceil 55000kbit prio 2 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:40 htb rate 1000kbit ceil 55000kbit prio 3 quantum 6 \ /bin/tc filter add dev eth0 parent 1:0 prio 99 handle 2: protocol ip u32 divisor 256 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u8 0x10 0xff at nexthdr+13 \ flowid 1:10 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2711 0x at nexthdr+2 \ flowid 1:20 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2710 0x at nexthdr+2 \ flowid 1:30 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 99 u32 ht 800:: offset at 0 mask 0x0f00 shift 6 plus 0 match u8 0x40 0xf0 at 0 link 2: \ /bin/tc qdisc add dev eth0 parent 1:10 handle 20: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:20 handle 30: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:30 handle 40: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:40 handle 50: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ Regards, Martin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc As far as I know lower prio numbers (as 0) means higher priority and higher prio numbers (as 7) means lower priority. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Bartek -- Mobilne wiadomo¶ci w Twojej komórce http://link.interia.pl/f1b71 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB does not respect the prio parameter
Yes, exactly. So my 1:20 class (prio 1) should get to send more than the 1:30 class. But it doesn't, they both get about the same throughput. Nobody else having problems with the prio parameter? Martin bartekR wrote: Martin Björnsson pisze: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 \ /bin/tc class add dev eth0 parent 1:0 classid 1:1 htb rate 55000kbit ceil 55000kbit quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1000kbit ceil 55000kbit prio 0 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1000kbit ceil 55000kbit prio 1 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1000kbit ceil 55000kbit prio 2 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:40 htb rate 1000kbit ceil 55000kbit prio 3 quantum 6 \ /bin/tc filter add dev eth0 parent 1:0 prio 99 handle 2: protocol ip u32 divisor 256 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u8 0x10 0xff at nexthdr+13 \ flowid 1:10 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2711 0x at nexthdr+2 \ flowid 1:20 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2710 0x at nexthdr+2 \ flowid 1:30 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 99 u32 ht 800:: offset at 0 mask 0x0f00 shift 6 plus 0 match u8 0x40 0xf0 at 0 link 2: \ /bin/tc qdisc add dev eth0 parent 1:10 handle 20: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:20 handle 30: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:30 handle 40: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:40 handle 50: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ Regards, Martin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc As far as I know lower prio numbers (as 0) means higher priority and higher prio numbers (as 7) means lower priority. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Bartek -- Mobilne wiadomo¶ci w Twojej komórce http://link.interia.pl/f1b71 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB does not respect the prio parameter
Hello Martin, I used to have this kind of problem before. Not sure if I resolved it with the help of folks on this mailing list, but I never tested. What you can try is to remove the prio parameter from the classes and leave the prio only for the filters. Let us know if that helps. Cheers, -Nikolay Martin Björnsson wrote: Yes, exactly. So my 1:20 class (prio 1) should get to send more than the 1:30 class. But it doesn't, they both get about the same throughput. Nobody else having problems with the prio parameter? Martin bartekR wrote: Martin Björnsson pisze: Hi all, I'm experimenting with HTB and the prio parameter and it does not give me results I expect. I've created 4 HTB classes: 1:10 TCP ACKs (prio 0) 1:20 TCP traffic on dst port 10001 (prio 1) 1:30 TCP traffic on dst port 1 (prio 2) 1:40 Default(prio 3) ceil and rate parameters are the same for all 4 classes (rate is 1000kbit and ceil is 55000kbit). Then I start 2 TCP flows on src/dst ports 1 and 10001. The packets seem to be correctly classified by the filter (I get hits on classes 10, 20 and 30). The problem is that I get the same throughput on both TCP flows. Shouldn't I get about 1000kbit through class 30 and much more through class 20 since it has higher priority? Here's my setup script: #!/bin/sh /bin/tc qdisc add dev eth0 root handle 1: htb default 40 \ /bin/tc class add dev eth0 parent 1:0 classid 1:1 htb rate 55000kbit ceil 55000kbit quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1000kbit ceil 55000kbit prio 0 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1000kbit ceil 55000kbit prio 1 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1000kbit ceil 55000kbit prio 2 quantum 6 \ /bin/tc class add dev eth0 parent 1:1 classid 1:40 htb rate 1000kbit ceil 55000kbit prio 3 quantum 6 \ /bin/tc filter add dev eth0 parent 1:0 prio 99 handle 2: protocol ip u32 divisor 256 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u8 0x10 0xff at nexthdr+13 \ flowid 1:10 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2711 0x at nexthdr+2 \ flowid 1:20 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ ht 2:0: \ match u8 0x06 0xff at 9 \ match u16 0x2710 0x at nexthdr+2 \ flowid 1:30 \ /bin/tc filter add dev eth0 parent 1:0 protocol ip prio 99 u32 ht 800:: offset at 0 mask 0x0f00 shift 6 plus 0 match u8 0x40 0xf0 at 0 link 2: \ /bin/tc qdisc add dev eth0 parent 1:10 handle 20: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:20 handle 30: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:30 handle 40: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ /bin/tc qdisc add dev eth0 parent 1:40 handle 50: red limit 1000KB min 10KB max 300KB avpkt 1000 burst 100 probability 0.02 \ Regards, Martin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc As far as I know lower prio numbers (as 0) means higher priority and higher prio numbers (as 7) means lower priority. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Bartek -- Mobilne wiadomo¶ci w Twojej komórce http://link.interia.pl/f1b71 ___ 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
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: I've thought that the culprit may be cpufreq. I have cpufreq scaling activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz when the processor is idle. This is more or less the same amount that I lose in the rate. May this be the problem? How to fix without deactivating cpufreq? Could be - I don't know. Forgetting cpufreq htb can be limited by Hz if the burst size is too small. I've tested with a burst size of 1500 (my MTU) and with precomputed values (which are 1614b for burst, 1633b for cburst) and the result is the same. I'm using HZ=1000 in my kernel, so my resolution is 1ms. According to HTB docs, the burst that will cause the rate to be burst-bound is 272000bit * 1m = 272bit. I'm using htb+sqf, and I can post here my tc setup if needed (is quite short), including the filters. It should be OK, since it has been working for almost two years. Right now I cannot disable cpufreq because temperature problems, and I cannot shut down the machine either, so I cannot test if cpufreq is the culprit, that's why I'm asking. I haven't found anything while googling, either. If you have perturb too low on sfq the packet reordering it causes could make the sender back off too much. I have a perturb of 10, as I've always used. Finally I could turn the machine off and clean the CPU fan, so I've make a test using the performance governor and the ondemand governor of cpufreq and yes, the problem is the cpufreq thing : I'll start a new thread here for this and will report to LKML too. Thanks for your answer :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
DervishD wrote: I'll start a new thread here for this and will report to LKML too. OK you should probably report to [EMAIL PROTECTED] rather than LKML. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
Hi Andy :) * Andy Furniss [EMAIL PROTECTED] dixit: DervishD wrote: I'll start a new thread here for this and will report to LKML too. OK you should probably report to [EMAIL PROTECTED] rather than LKML. I was considering it, but then I thought that maybe this problem was known and affecting other parts of the kernel. Given the lack of response, probably reporting to netdev is better. I'll bounce the message there. Thanks :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB doesn't give me the promised rate: cpufreq?
DervishD wrote: Hi all :) I've been using a tc setup for almost two years, but at some point (probably when I switched to kernel 2.6.x, but I'm not sure) it has started making something very weird. For a certain class, the rate is 125000bit and the ceil is 27bit, but the fastest rate I get is about 75-8bit, instead of the promised 125000, *with no other traffic in the device*. If I disable tc entirely, the upload rate is more than 30bit (a little below the line capacity, which is 32bit), but as soon as tc is enabled again, the upload speed drops again to 75-80kbit. There is no other traffic on the device, really, it's just like if the htb couldn't queue packets fast enough :??? I've thought that the culprit may be cpufreq. I have cpufreq scaling activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz when the processor is idle. This is more or less the same amount that I lose in the rate. May this be the problem? How to fix without deactivating cpufreq? Could be - I don't know. Forgetting cpufreq htb can be limited by Hz if the burst size is too small. tc -s -d class ls dev ... should show the size being used. I'm using htb+sqf, and I can post here my tc setup if needed (is quite short), including the filters. It should be OK, since it has been working for almost two years. Right now I cannot disable cpufreq because temperature problems, and I cannot shut down the machine either, so I cannot test if cpufreq is the culprit, that's why I'm asking. I haven't found anything while googling, either. If you have perturb too low on sfq the packet reordering it causes could make the sender back off too much. Andy. If anybody has any idea about this problem, please tell. Thanks a lot in advance :)) Raúl Núñez de Arenas Coronado ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB tree is too deep
Marco C. Coelho wrote: I've got a linux (2.6.18-8.1.6.el5.centos.plus) router doing pppoe termination and HTB rate limiting. the number of connections has grown quite a bit in the last few months, and I'm now getting a: HTB tree is too deep message on the monitor. where is the setting for max depth? There is a define in both the kernel and iproute2's copy of the headers - I don't know if you need to do both and recompile both kernel and tc. include/linux/pkt_sched.h:#define TC_HTB_MAXDEPTH8 Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and ATM patch
Edouard Thuleau wrote: Hi all, I patch my kernel (2.6.17) and my tc (iproute2-2.6.18-061002) utilitie for an accurate packet scheduling on an ATM link. I configure my HTB hierarchy on the upload of the link and try with differents flows. It works correctly but in some of case I lose about 50% of my bandwith. That's what dsl/atm is like for some packet sizes, eg. an empty windows ack = 40 byte IP packet, but 2 ATM cells = 106 bytes on the wire. I use the overhead (42) configuration for my link (PPPoE, VC/LLC) indicate in the documentation. My question is, how this hoverhead value is calculate ? http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ I try to separate the streams with the lentgh of the packet in differents classes and put a specific overhead for each one, but I don't know how calculate it. Do you think it's a good solution ? You don't need a different overhead just 42 for all classes (assuming you are shaping on the ppp device - you can take 14 from the 42 if the ppp terminates elsewhere any you are shaping on eth) Is it necessary to put the atm, nohyst options and configure the overhead for the mother class ? I would put overhead 42 atm nohyst after every rate - so yes. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB deadlock
Ranko Zivojnovic wrote: Greetings, I've been experiencing problems with HTB where the whole machine locks up. This usually happens when the whole qdisc is being removed and occasionally when a leaf is being removed. Common is that it always happens when some sort of removal is in progress. Console output I have captured is at the end of this message. The same behavior exists from vanilla 2.6.19.7 and above. It is possible that the problem also exist in the earlier versions however I did not go further back. I also believe I have found where the actual problem is: qdisc_destroy() function is always called with dev-queue_lock locked. htb_destroy() function up the stack is using del_timer_sync() call to deactivate HTB qdisc timers. From the comments in the source where del_timer_sync() is defined: ---copy/paste--- /** * del_timer_sync - deactivate a timer and wait for the handler to finish. * @timer: the timer to be deactivated * * This function only differs from del_timer() on SMP: besides deactivating * the timer it also makes sure the handler has finished executing on other * CPUs. * * Synchronization rules: Callers must prevent restarting of the timer, * otherwise this function is meaningless. It must not be called from * interrupt contexts. The caller must not hold locks which would prevent * completion of the timer's handler. The timer's handler must not call * add_timer_on(). Upon exit the timer is not queued and the handler is * not running on any CPU. * * The function returns whether it has deactivated a pending timer or not. */ ---copy/paste--- Now, htb_rate_timer() does exactly what appears to be the source of the problem - it tries obtain dev-queue_lock - and given the right moment (timer fired handler while qdisc_destroy was holding the lock) - system locks up - del_timer_sync is waiting for handler to finish while the handler is waiting for the dev-queue_lock. Of course I could also be completely wrong here and missing something not so obvious. I could also attempt to fix this but I haven't dealt with this code in the past so I was hoping someone with better insight might just have an elegant solution up his sleeve. Best regards, Ranko PS: If this list is not the right place for this report - please let me know. You should send bug reports to [EMAIL PROTECTED] ---CONSOLE (2.6.19.7)--- BUG: soft lockup detected on CPU#3! [c013c890] softlockup_tick+0x93/0xc2 [c0127585] update_process_times+0x26/0x5c [c0111cd5] smp_apic_timer_interrupt+0x97/0xb2 [c0104373] apic_timer_interrupt+0x1f/0x24 [c02e007b] klist_next+0x4/0x8a [c02e2570] _spin_unlock_irqrestore+0xa/0xc [c012729b] try_to_del_timer_sync+0x47/0x4f [c01272b1] del_timer_sync+0xe/0x14 [f8b8a85b] htb_destroy+0x20/0x7b [sch_htb] [c028f196] qdisc_destroy+0x44/0x8d [f8b89645] htb_destroy_class+0xd0/0x12d [sch_htb] [f8b895c7] htb_destroy_class+0x52/0x12d [sch_htb] [f8b8a87a] htb_destroy+0x3f/0x7b [sch_htb] [c028f196] qdisc_destroy+0x44/0x8d [f8b89645] htb_destroy_class+0xd0/0x12d [sch_htb] [f8b895c7] htb_destroy_class+0x52/0x12d [sch_htb] [f8b8a87a] htb_destroy+0x3f/0x7b [sch_htb] [c028f196] qdisc_destroy+0x44/0x8d [c0290ba9] tc_get_qdisc+0x1a3/0x1ef [c0290a06] tc_get_qdisc+0x0/0x1ef [c028a366] rtnetlink_rcv_msg+0x158/0x215 [c028a20e] rtnetlink_rcv_msg+0x0/0x215 [c0294598] netlink_run_queue+0x88/0x11d [c028a1c0] rtnetlink_rcv+0x26/0x42 [c0294b0c] netlink_data_ready+0x12/0x54 [c0293843] netlink_sendskb+0x1c/0x33 [c0294a11] netlink_sendmsg+0x1ee/0x2d7 [c0278ff7] sock_sendmsg+0xe5/0x100 [c01306b9] autoremove_wake_function+0x0/0x37 [c01306b9] autoremove_wake_function+0x0/0x37 [c0278ff7] sock_sendmsg+0xe5/0x100 [c01cd8be] copy_from_user+0x33/0x69 [c027913f] sys_sendmsg+0x12d/0x243 [c02e2564] _read_unlock_irq+0x5/0x7 [c013fb2b] find_get_page+0x37/0x42 [c01423dd] filemap_nopage+0x30c/0x3a3 [c014bb99] __handle_mm_fault+0x21c/0x943 [c02e24c5] _spin_unlock_bh+0x5/0xd [c027b475] sock_setsockopt+0x63/0x59d [c0151801] anon_vma_prepare+0x1b/0xcb [c027a2ea] sys_socketcall+0x24f/0x271 [c02e3ad0] do_page_fault+0x0/0x600 [c01038f1] sysenter_past_esp+0x56/0x79 === BUG: soft lockup detected on CPU#1! [c013c890] softlockup_tick+0x93/0xc2 [c0127585] update_process_times+0x26/0x5c [c0111cd5] smp_apic_timer_interrupt+0x97/0xb2 [c0104373] apic_timer_interrupt+0x1f/0x24 [c01c007b] blk_do_ordered+0x70/0x27e [c01ce788] _raw_spin_lock+0xaa/0x13e [f8b8b422] htb_rate_timer+0x18/0xc4 [sch_htb] [c0127539] run_timer_softirq+0x163/0x189 [f8b8b40a] htb_rate_timer+0x0/0xc4 [sch_htb] [c0123315] __do_softirq+0x70/0xdb [c01233bb] do_softirq+0x3b/0x42 [c0111cda] smp_apic_timer_interrupt+0x9c/0xb2 [c0104373] apic_timer_interrupt+0x1f/0x24 [c0101cc3] mwait_idle_with_hints+0x3b/0x3f [c0101cd3] mwait_idle+0xc/0x1b [c010271c] cpu_idle+0x63/0x79 === BUG: soft lockup detected on CPU#2! [c013c890] softlockup_tick+0x93/0xc2 [c0127585]
Re: [LARTC] HTB
Marco Aurelio ha scritto: What exactly happens if the sum of the children classes rate is bigger than the parent's? HTB will assign to the leaf the rate regardeless of the value of the parent's rate. The parent's rate is used only to compute how much bandwith must be allocated to the leaf's ceil. What if the majority of these classes are using less than the minimum rate established (eg. 0kbps)? -- ** Marco Innocenti Gruppo Infrastruttura e Sicurezza CINECA phone:+39 0516171553 / fax:+39 0516132198 Via Magnanelli 6/3 e-mail: [EMAIL PROTECTED] 40033 Casalecchio di RenoBologna (Italia) ** ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and bursts
Pablo Fernandes Yahoo wrote: I would like to have the customer using 150kbit stable in a download. But at the begining of the conection, i would like to have a 200kbit burst. Depends what you mean - burst is an amount of data not a bitrate. If you want them (using your setup) to have 25k of data unlimited rate then burst 25k cburst 25k should do it. I think that if your class has a different ceil to rate then giving a burst but not cburst will give them burst bytes capped at ceil rate. I haven't tested the exact behavior or read all recent posts yet. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and burst...
Michael Fincham wrote: Hey everyone, For some reason my htb configuration isn't allowing any class to burst up to its ceiling ever, even when the link is only being utilised by one class that class only ever gets its assigned rate and exactly that assigned rate... The hierarchy I have is 1: at the root with no default, then 1:2 and 1:3 under that, both with assigned rates, then 2: and 3: under those respectively with defaults configured. Iptables marks the packets based on incoming interface which then get filtered to either 1:2 or 1:3 and filtered again, shaped accordingly etc... All classes and qdiscs are HTB Any ideas anyone? It could be to do with clock Hz - your burst needs to be large enough to reach rate/ceil per tick. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] HTB and burst...
It looks as though I may have had the hierarchy wrong... I had a class with a qdisc as a child then all my classes as children of the qdisc... now borrowing allowed as they're all root qdiscs. -Michael On Thu, 2007-05-03 at 08:53 -0700, Flechsenhaar, Jon J wrote: I would need to see your actual script to say for sure. Jon Flechsenhaar Boeing WNW Team Network Services (714)-762-1231 202-E7 -Original Message- From: Michael Fincham [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 02, 2007 6:23 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB and burst... Hey everyone, For some reason my htb configuration isn't allowing any class to burst up to its ceiling ever, even when the link is only being utilised by one class that class only ever gets its assigned rate and exactly that assigned rate... The hierarchy I have is 1: at the root with no default, then 1:2 and 1:3 under that, both with assigned rates, then 2: and 3: under those respectively with defaults configured. Iptables marks the packets based on incoming interface which then get filtered to either 1:2 or 1:3 and filtered again, shaped accordingly etc... All classes and qdiscs are HTB Any ideas anyone? -- Michael Fincham [EMAIL PROTECTED] ___ 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
Re: [LARTC] HTB+SFQ
On Thursday 26 April 2007 19:34, terraja-based wrote: Hi folks, Hi! Hola! I`ve a problem to use HTB and SFQ. The first script, below, to show a simple configuration, does work fine...!!! But, in the second example, does not work, becouse i put more code to clasify the traffic by protocol, http and ftp in this case. Somebody can tell me the errors? Thx, in advance.- NOTICE: IMQ device is to asociate with ETH1 my external iface. SCRIPT que funciona: #!/bin/sh ifconfig imq0 up tc qdisc add dev imq0 handle 1: root htb default 1 tc class add dev imq0 parent 1: classid 1:1 htb rate 500kbit ceil 2000kbit tc qdisc add dev imq0 parent 1:1 handle 2 sfq iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0 tc filter add dev imq0 parent 1: prio 0 protocol ip handle 2 fw flowid 1:1 ...could you tell me why do you filter by mark 2? Are you trying to match the unmatched packets for iptables? ...¿me prodría decir por qué está tratando de filtrar por la marca 2? ¿Acaso está tratando de redirigir los paquetes que iptables no haya sido capaz de clasificar? SCRIPT que NO funciona: #!/bin/sh ifconfig imq0 up tc qdisc add dev imq0 handle 1: root htb default 1 tc class add dev imq0 parent 1: classid 1:1 htb rate 500kbit ceil 2000kbit tc class add dev imq0 parent 1:1 classid 1:10 htb rate 100kbit ceil 2000kbit tc class add dev imq0 parent 1:1 classid 1:20 htb rate 100kbit ceil 2000kbit tc qdisc add dev imq0 parent 1:10 handle 2 sfq tc qdisc add dev imq0 parent 1:20 handle 3 sfq iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0 tc filter add dev imq0 parent 1:1 prio 0 protocol ip handle 2 fw flowid 1:10 tc filter add dev imq0 parent 1:1 prio 1 protocol ip handle 3 fw flowid 1:20 Hmm, do you really want these filters as children of 1:1 (root child) instead of 1: (root)? If you put these filters as children of 1:1 the traffic will not go through the tc tree: you need to redirect the packets falling into the root to any child. Hmm, ¿de veras que quiere que estos filtros sean hijos de 1:1 (hijo de la raíz) en vez de hijos de 1: (la raíz)? Si estos filtros se quedan como hijos de 1:1 el tráfico de paquetes no fluirá por el árbol de tc: necesita redirigir los paquetes que caen en la raíz para alguno de los nodos hijos. Ya luego, con el segundo script deberia agregar al final las MARKs de IPTABLES, pero no lo hice porque ni siquera cuando hago un SHOW de las qdisc (tc qdisc show) me muestra el trafico clasificado, es decir...luego yo iba a mandar el trafico de la class 1:10 para el protocolo HTTP y la 1:20 para FTP, y eso se hace justamente con IPTABLES, pero repito no lo hice porque no veo el trafico desglozado previamente cuando trafico, usando los 2 potocolos, en la qdisc. Esa es la cuestion, no logro clasificar el trafico para luego marcarlo. Ahi esta el Kì del asunto como decian las viejas... Any ideas? For any reason, when you redirect packets by 'default' to any child, those redirected packets seem to go directly to the attached qdisc, so, filters with the default class as parent will not work. I recomend you something like the rules bellow: Por alguna razón, cuando los paquetes son redirigidos 'por defecto', aparentemente pasan directamente al qdisc asociado a la clase en cuestión, por tanto, los filtros asociados que tienen a dicha clase como padre no funcionarán. Yo recomendaría una configuración como la que sigue: -8---8-- tc qdisc add dev imq0 handle 1: root htb default 30 tc class add dev imq0 parent 1: classid 1:1 htb rate 500kbit ceil 2000kbit tc class add dev imq0 parent 1:1 classid 1:10 htb rate 100kbit ceil 2000kbit tc class add dev imq0 parent 1:1 classid 1:20 htb rate 100kbit ceil 2000kbit tc class add dev imq0 parent 1:1 classid 1:30 htb rate 300kbit ceil 2000kbit tc qdisc add dev imq0 parent 1:10 handle 2 sfq tc qdisc add dev imq0 parent 1:20 handle 3 sfq iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0 tc filter add dev imq0 parent 1: prio 0 protocol ip handle 2 fw flowid 1:10 tc filter add dev imq0 parent 1: prio 1 protocol ip handle 3 fw flowid 1:20 -8---8-- De mas esta decir que IPTABLES, IPROUTE y el KERNEL estan correctamente parcheados y actualizados, ya que sino ni siquiera levanta los modulos o daria error.- PS: by the way, I guess you need to change your 1:1 htb class parameters to match your real bandwith limitations of the device (eth1 in this case). Nota: me parece que sería más adecuado asignarle a 1:1 las verdaderas restricciones de ancho de banda del dispositivo (eth1 en este caso). -- Alejandro Ramos Encinosa [EMAIL PROTECTED] Fac. Matemática Computación
Re: [LARTC] HTB policing affects shaping performance? Please, help.
On Wed, 14 Feb 2007 23:01:02 +0200, Radu Oprisan wrote Bc.Slavomir Danas wrote: I'm trying to access shared folders (samba) on ip 10.4.10.10 from my laptop with ip 172.16.0.2. Everything works as expected when downloading or uploading (correctly shaped and policed at 1Mbit). But when I try to download and upload at the same time, my speed drops down rapidly on both download and upload (approx. 350kbit and 550kbit). I tried to replace tc filter with iptables CLASSIFY but with the same result. What is the correct approach when configuring separate queues with guaranteed rate without affecting each other? cut Try using some other protocol to run your tests. I was using for this purpose a Linux utility but i can't remember how it was called. You are probably talking about ttcp tool. -- Grzegorz Chwesewicz ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB policing affects shaping performance? Please, help.
Bc.Slavomir Danas wrote: I'm trying to access shared folders (samba) on ip 10.4.10.10 from my laptop with ip 172.16.0.2. Everything works as expected when downloading or uploading (correctly shaped and policed at 1Mbit). But when I try to download and upload at the same time, my speed drops down rapidly on both download and upload (approx. 350kbit and 550kbit). I tried to replace tc filter with iptables CLASSIFY but with the same result. What is the correct approach when configuring separate queues with guaranteed rate without affecting each other? Your setup is ok. The only problem you are facing is that samba is a very chatty program, it tends to communicate a lot outside of simply downloading something. What i am trying to say is that, you will have some upload when in reality you are downloading something. This being true, when you begin uploading something, your upload line becomes full and, the upload chat for the download slows down, this in turn slowing down your download. I'm sorry if what I'm saying is hard to read. Try using some other protocol to run your tests. I was using for this purpose a Linux utility but i can't remember how it was called. -- Radu Oprisan ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] HTB? (NEWBIE)
How the guide say I expect to see on router (with command tc -s qdisc ls dev eth0) that unclassified traffic, like ssh, get rounded to 20: but it doesn't happen. - Traffic just doesn't get rounded to a class. If you want traffic going to a class you need to specify a filter. Did you by chance man the default class 1:30. Any traffic not classified should end up there. - Packet shaping is only done on the Egress/root side of an interface. That is why you will only see stats for that. You won't see stats for the ingress side. Does this answer any of your questions? Jon Flechsenhaar Boeing WNW Team Network Services (714)-762-1231 202-E7 -Original Message- From: Simone84bo [mailto:[EMAIL PROTECTED] Sent: Friday, January 19, 2007 3:05 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] HTB? (NEWBIE) Hi to all I am studying HTB on LARTC how to. I realize a simple configuration on router: tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 3mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1mbit burst 15k tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0x flowid 1:10 After this configuration I make a ssh connection between client and server. How the guide say I expect to see on router (with command tc -s qdisc ls dev eth0) that unclassified traffic, like ssh, get rounded to 20: but it doesn't happen. The count of ssh traffic packet result only on root qdisc. Why? A second question if i want to limited rate of all my router which configuration can i realize? Thanks -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Problemi di Liquidità? Con Logos Finanziaria 30.000 € in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi, clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2911d=20070120 ___ 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
Re: [LARTC] HTB? (NEWBIE)
On Jan 20, 2007, at 12:05 AM, Simone84bo wrote: Hi to all I am studying HTB on LARTC how to. I realize a simple configuration on router: tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 3mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1mbit burst 15k tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0x flowid 1:10 After this configuration I make a ssh connection between client and server. How the guide say I expect to see on router (with command tc -s qdisc ls dev eth0) that unclassified traffic, like ssh, get rounded to 20: but it doesn't happen. The count of ssh traffic packet result only on root qdisc. Why? A second question if i want to limited rate of all my router which configuration can i realize? You'd see that if you used filter on port 22 instead of 80. 'Cause 22 is the port of ssh. And your default class is wrong. It should be 1,10 or 20. 10 or 20 preferably. regards -- Bartek Krawczyk JID: [EMAIL PROTECTED] GG: 2094683 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB? (NEWBIE)
You should propably try: tc qdisc add dev eth0 root handle 1: htb default 20 and not 30 cause your default class is 20 no? On 1/20/07, Simone84bo [EMAIL PROTECTED] wrote: Hi to all I am studying HTB on LARTC how to. I realize a simple configuration on router: tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 3mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit burst 15k tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1mbit burst 15k tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0x flowid 1:10 After this configuration I make a ssh connection between client and server. How the guide say I expect to see on router (with command tc -s qdisc ls dev eth0) that unclassified traffic, like ssh, get rounded to 20: but it doesn't happen. The count of ssh traffic packet result only on root qdisc. Why? A second question if i want to limited rate of all my router which configuration can i realize? Thanks -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Problemi di Liquidità? Con Logos Finanziaria 30.000 € in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi, clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2911d=20070120 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Jordi Segués Daina --- Andorra GSM: (+376) 35 35 68 France GSM: (+33) (0)6 81 88 35 55 [EMAIL PROTECTED] / MSN: [EMAIL PROTECTED] AIM: superjordix Skype: callto://superjordix --- http://www.JordiX.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] HTB GUI
Hi Alan, can anyone teach me what software to use to build a own web based GUI HTB software in Fedoracore ( Linux based) ? Thanks That really is a very open question to be asking. There are so many different programming languages that can work with a web server 2 that spring to mind are PHP and Perl. What may be of more benefit for you would be to visit each of the respective websites www.php.net http://www.php.net/ (PHP) or www.perl.com http://www.perl.com/ (Perl) and perhaps look at some of the examples on those sites. Depending on what you plan to do PHP may be a better choice over Perl (I'm not going to argue with anyone here) or vice versa it really comes down to your requirements and or future requirements. That said, I would probably suggest Perl as it has an extensive library of user contributed classes and code that is available from CPAN (www.cpan.org http://www.cpan.org/ ) and it is most likely that you will find something there that will allow you to finish your project sooner. You will also need to look at installing the apache web server module mod_perl in order to get your perl scripts working with apache. (Again, not arguing with anyone over this) As for teaching you how to build a web based GUI, I'm afraid I just don't have the time but there are plenty of resources available on the internet that you can learn from including IRC channels and websites to name just a few. I hope this helps Rangi _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of alan tan Sent: Thursday, 23 November 2006 10:18 p.m. To: lartc@mailman.ds9a.nl; lartc@mailman.ds9a.nl Subject: [LARTC] HTB GUI Hi, I have many example of HTB GUI . All is already well developed, which discussed in this link http://mailman.ds9a.nl/pipermail/lartc/2005q1/014735.html . However, can anyone teach me what software to use to build a own web based GUI HTB software in Fedoracore ( Linux based) ? Thanks Regards Alan http://mailman.ds9a.nl/pipermail/lartc/2005q1/014735.html ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] HTB GUI
You might want to look into MasterShaper. It's a full tc/ip bandwidth shaper. The author of it is Unki. He's done the GUI in php, and uses some perl scripts to run the actual scripts on the system. He's currently working on a newer version, and I think it's supposed to support multiple wans. Regards, Mark From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] On Behalf Of alan tan Sent: Thursday, 23 November 2006 10:18 p.m. To: lartc@mailman.ds9a.nl; lartc@mailman.ds9a.nl Subject: [LARTC] HTB GUI Hi, I have many example of HTB GUI . All is already well developed, which discussed in this link. However, can anyone teach me what software to use to build a own web based GUI HTB software in Fedoracore ( Linux based) ? Thanks Regards Alan ___ 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
Re: [LARTC] htb/iptables for ISP
plugthebox.net /dev/null wrote: Hello, hi This process kills my machine for 3-4 minutes until dumping all htb/sqf/iptables into files and running these files (remember that i almost have 1200 IPs, and each IP has 6 HTB+SFQ line with 2 iptables) both iptables and tc have a batch mode, and both support changing instead of deleting/creating. Yours sincerely, Peter -- http://www.shurdix.org - Linux distribution for routers and firewalls ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB has 2 bucket?
thank you for your reply i'm doubt about before i known , there have two bucket. my assumption is ... first bucket for keep token sending with rate guarantee and this bucket size are same as burst size and in every minute ... number of token will create at least rate token but max with burst size but after true is ... HTB have 2 bucket My assumption are true for htb technique to handle "burst traffic"??? first bucket size for keep token is burst size for handle when burst traffic coming. every minute, number of token will create at least rate token for guarantee bandwidth but max with burst sizeand support burst (i'm not sure if max token are burst size, at first time to handle burst traffic. htb will use all token in bucket but when next second??? Bucket are empty? so max bucket size may be bigger than burst size??) when class use banwidth exceed rate, class will borrow banwidth from parent class so class will use ctoken that keep in another bucket(bucket for keeping ctoken and ctoken are come from only parent' token) i don't understand when burst traffic coming how htb choose between2 bucket are use? i see picture from http://linux-ip.net/traffic-control/htb-class.png don't understand. why must checking in ctoken before token Is it true? because burst traffic will use token more than token in first Bucket. so it will skip to check ctoken. Is it max enough, it will use all token in first+bucket and ctoken in secoond Bucket because for theory htb to handle burst traffic, htb allow to sending with burst rate until average rate equal to burst threadhold, htb will change rate to rate guarantee, if use only token in first bucket to handle burst traffic i think this mechanismwill use token and among sending with burst rate if number of available token are qual or more than little bit num of rate token for guarantee bandwidth, it will change to sending with rate guarantee? (i'm not sure for my assumtion, If my assumption are wrong. can you tell me the trueth?) advise me please, thank you - Original Message From: Martin A. Brown [EMAIL PROTECTED]To: Thossapron Apinyapanha [EMAIL PROTECTED]Cc: lartc lartc lartc@mailman.ds9a.nlSent: Friday, October 13, 2006 7:56:02 PMSubject: Re: [LARTC] HTB has 2 bucket? -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Greetinsg Thossapron,: in HTB use 2 bucket for manage 2 rate??? first bucket - keep : token for sending with rate second bucket - keep ctoken for : sending with ceil rate Is it true?? may be i'm misunderstand : about token/bucket thoeryYes, there are two different buckets used.One bucket is for tokens, another bucket is for ctokens.Brief picture of association of parameters:rate:burst, tokensceil:cburst, ctokensSee the upper right corner of this diagram [0].In particular, I should warn you that the SFQ qdisc in this diagram is the one which is granted the dequeue opportunity, so although packets mostly flow from left to right in this diagram, the SFQ is displayed to the left of the HTB rate/ceil buckets, even though logically this is reversed.Good luck,- -Martin[0] http://linux-ip.net/traffic-control/htb-class.png- -- Martin A. Brownhttp://linux-ip.net/-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (GNU/Linux)Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)iD8DBQFFL4zmHEoZD1iZ+YcRAm1mAJ42tQy4cRL88JnuwR2/YR3zrRoTOACfbLtuccrh3V/7eBzDlpRvWTgOtZs==RqAV-END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB has 2 bucket?
thank you for your reply i'm doubt about before i known , there have two bucket. my assumption is ... first bucket for keep token sending with rate guarantee and this bucket size are same as burst size and in every minute ... number of token will create at least rate token but max with burst size but after true is ... HTB have 2 bucket My assumption are true for htb technique to handle "burst traffic"??? first bucket size for keep token is burst size for handle when burst traffic coming. every minute, number of token will create at least rate token for guarantee bandwidth but max with burst sizeand support burst (i'm not sure if max token are burst size, at first time to handle burst traffic. htb will use all token in bucket but when next second??? Bucket are empty? so max bucket size may be bigger than burst size??) when class use banwidth exceed rate, class will borrow banwidth from parent class so class will use ctoken that keep in another bucket(bucket for keeping ctoken and ctoken are come from only parent' token) i don't understand when burst traffic coming how htb choose between2 bucket are use? i see picture from http://linux-ip.net/traffic-control/htb-class.png don't understand. why must checking in ctoken before token Is it true? because burst traffic will use token more than token in first Bucket. so it will skip to check ctoken. Is it max enough, it will use all token in first+bucket and ctoken in secoond Bucket because for theory htb to handle burst traffic, htb allow to sending with burst rate until average rate equal to burst threadhold, htb will change rate to rate guarantee, if use only token in first bucket to handle burst traffic i think this mechanismwill use token and among sending with burst rate if number of available token are qual or more than little bit num of rate token for guarantee bandwidth, it will change to sending with rate guarantee? (i'm not sure for my assumtion, If my assumption are wrong. can you tell me the trueth?) advise me please, thank you - Original Message From: Martin A. Brown [EMAIL PROTECTED]To: Thossapron Apinyapanha [EMAIL PROTECTED]Cc: lartc lartc lartc@mailman.ds9a.nlSent: Friday, October 13, 2006 7:56:02 PMSubject: Re: [LARTC] HTB has 2 bucket? -BEGIN PGP SIGNED MESSAGE-Hash: SHA1Greetinsg Thossapron,: in HTB use 2 bucket for manage 2 rate??? first bucket - keep : token for sending with rate second bucket - keep ctoken for : sending with ceil rate Is it true?? may be i'm misunderstand : about token/bucket thoeryYes, there are two different buckets used.One bucket is for tokens, another bucket is for ctokens.Brief picture of association of parameters:rate:burst, tokensceil:cburst, ctokensSee the upper right corner of this diagram [0].In particular, I should warn you that the SFQ qdisc in this diagram is the one which is granted the dequeue opportunity, so although packets mostly flow from left to right in this diagram, the SFQ is displayed to the left of the HTB rate/ceil buckets, even though logically this is reversed.Good luck,- -Martin[0] http://linux-ip.net/traffic-control/htb-class.png- -- Martin A. Brownhttp://linux-ip.net/-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2 (GNU/Linux)Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)iD8DBQFFL4zmHEoZD1iZ+YcRAm1mAJ42tQy4cRL88JnuwR2/YR3zrRoTOACfbLtuccrh3V/7eBzDlpRvWTgOtZs==RqAV-END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB has 2 bucket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetinsg Thossapron, : in HTB use 2 bucket for manage 2 rate??? first bucket - keep : token for sending with rate second bucket - keep ctoken for : sending with ceil rate Is it true?? may be i'm misunderstand : about token/bucket thoery Yes, there are two different buckets used. One bucket is for tokens, another bucket is for ctokens. Brief picture of association of parameters: rate: burst, tokens ceil: cburst, ctokens See the upper right corner of this diagram [0]. In particular, I should warn you that the SFQ qdisc in this diagram is the one which is granted the dequeue opportunity, so although packets mostly flow from left to right in this diagram, the SFQ is displayed to the left of the HTB rate/ceil buckets, even though logically this is reversed. Good luck, - -Martin [0] http://linux-ip.net/traffic-control/htb-class.png - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFFL4zmHEoZD1iZ+YcRAm1mAJ42tQy4cRL88JnuwR2/YR3zrRoTOACfbLtu ccrh3V/7eBzDlpRvWTgOtZs= =RqAV -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB root rate allowing to much of a burst
Flechsenhaar, Jon J wrote: I don't know if you answer basic HTB questions but I'l try anyway. I'm implementing AF and EF with a root rate of 500 kbps (kilo bits per second). I am using DSMARK to classify packets. I'm implementing this on two different hardware sets PPC and x86 with the same kernel options configured. Problem: My root rate is going about 75 kbps over its 500kbps limit (ceil 500). How are you measuring - htb and rate estimators see packets on eth an iplen + 14. I believe this is because of burst and cburst settings. I am using default calculations now, on all classes. Is there a formula to use in tweaking these values? I would like my rates to follow the assigned rate more closely. Hz and a compile time header change - HYSTERESIS 0 in net/sched/sched_htb.c also affect accuracy. I am generating traffic with a hardware traffic generator. Starting at 300 kbps stepping by 100 kbps up to 1mbps. Each step lasts for 60 sec. Could give different results to normal tcp I suppose. My config script is attached. Thanks. tbf latency 0.01 on 256kbit is too short for a buffer IIRC it gets rounded up so at least mtu packets get through. I get an error on your script with iproute2-ss060323 and 2.6.17.11/7 ++ /usr/sbin/tc qdisc change dev eth0 parent 2:20 gred DP 3 limit 60kb min 10kb max 20kb avpkt 1500 burst 9 bandwidth 500kbit probability 0.06 prio 4 RTNETLINK answers: Invalid argument after each DP 3 on each gred. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and HFSC,declaration tc command question
*~ r a K u ~ * wrote: I have a lot question about tc-command because now i'm doing research to compare performance between HTB and HFSC so i'm doubt a lot thing and your reply are so very helpful to me ... My question is *In HTB tc command question* 1. I'm use opensource (Mastershaper) for help to config traffic control but when i'm try to config HTB, I'm doubt about in each chain must identify fallback service level and If i'm don't specify it,it will unable to contain pipe. Every traffic and if traffic not matched in chain's pipe can only use the fallback service level (ps. Mastershaper represent interior class as pipe and leaf class as chain) Is it only true definition in HTB tc command?? or it's only a creative function from developer?? Don't know what you mean really - mastershaper is OK but if you want to test HTB and HFSC you should do it by hand so you can play with different HTB settings. quantum/burst/cburst can affect things at low rates there is also a compile time define that makes HTB more accurate - HYSTERESIS 0 is more accurate than the default 1. HTB accuracy is limited by Hz setting aswell. Testing on low bandwidth links shows HTB to be sensitive to how you set things up. Trying to have a class for each user, with prio for interactive within that doesn't work well - your interactive needs to be top level prio 0. I haven't tested doing per user within that. At low rates I find hfsc is alot better, but then my tests may have been flawed. You won't see any results from ping output when simulating a low rate on eth unless you make an artificial link with another queue. This can be tricky - hfsc seems Ok - but it doesn't add bitrate latency quite like a real link would. If you use hfsc to simulate a link then to be fair to htb you need to choose packet sizes carefully, because htb uses rate tables that are only right if (on eth) ip_len+14/8 is an integer. In effect (on eth) this means setting mtu to 1498 and ping -s 54 rather than default 56. You could instead, just tcpdump on a remote box and look at time deltas/packet lengths and deduce how much a real link would be backlogged. *In HFSC tc command question * after i read HFSC paper , i'm doubt in Service curve declaration like this | SC := [ [ m1 BPS ] [ d SEC ] m2 BPS | | m1 : slope of first segment - umax | d : x-coordinate of intersection - dmax | m2 : slope of second segment - rate You can specify curves two ways and you don't need m1/umax or d/dmax for a linear curve. Whether you say m1 as a bitrate or umax bytes for packet length hfsc will convert to bitrate. You need to think of the link you shape for as a linear curve and make sure all your rates do not exceed that. 2. In all leaf class must specify rt (realtime service curve) ??? and Is it important to specify sc (Service curve) in all leaf class ?? and in all leaf class must specify link-sharing (ls) too?? I think you can have any type on leaf - inners can't be rt, though you can use sc rather than ls I suppose they are just ls. On a leaf sc is rt + ls, ie. it can borrow and is capped by the first ul above/on it, rt alone will not get a share above its rate. because i think after read HFSC theory about by default All leaf class(Service class) will use Link-sharing critirion for allocation bandwidth from Service curve (My assumtion think this calculation bandwidth is m1 or umax -total bandwidth that can send at ceil rate??) and when total delay are exceed to demax or d - it mean The way I see it may be wrong - There is no ceil rate for rt as such , that's for ls - it is up to you to work out m1 and delay for every leaf (not sure if ls leaf matters but I still did in my test, just to make the curves add up) so that you don't go over the link curve. On a slow link if you assume big packets that makes for long delays. In practice it will be jitter - Patrick wrote he may make hfsc even more non work conserving one day (IIRC). Until then I don't think it's possible to get optimal behaviour for prio between rt classes. The original hfsc algorithym assumes some device driver controls the queue - in practice that won't happen without alot of buffering to mess things up, the current hfsc rate limiting is good but doesn't quite simulate the perfect (non existant) driver that asks for a packet at a time. it's time for HFSC to manage QoS to guarantee bandwidth and delay in each leaf class by use Real-time Criterion so bandwidth rate will change to m2 or bandwidth rate that guarantee QoS in eache leaf class Is it true??? i fear may be misunderstand in HFSC theory, example in my test lab ,i have leaf class 3 type such real-time ,data ,default Can i specify - real-time leaf class - rt (for guatantee delay and bw) ,ls (by default when not exceed max delay) It will get (max) delay according d upto m2 bandwidth if it needs to borrow more from ls those packets get no delay guarantee. - data lead class - ls
Re: [LARTC] HTB and per-connection bandwidth allocation
Namitha Rao wrote: Hi http://mailman.ds9a.nl/pipermail/lartc/2002q3/004977.html I have the same problem to discuss as in the above link. I want to allocate say X MBit per individual connection regardless of the number of connection . KIndly could anyonen suggest me how to proceed. I have tried with SFq but is doesnot yeild my requirement.. Thanks, Namitha. If you can't think of a way to turn a connection into a class then search the archive for perflow - someone once started a qdisc to do this. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB shaping problem
f00ty wrote: Hi all ! I'm building a network appliance whose goals are to enhance Voip quality on 512/128k DSL links. But, i have a voice quality problem, and i think i'm doing something wrong, but i can't find what. Please excuse my terrible english, i'm french. From what i've read, tc is the tool i need. I read the documentations, readmes and lartc.org howto, and came to the following setup: NA = Linux-based network appliance (in fact a standard PC) A--[Switch]--[eth1 NA eth0]--[DSL modem] A = 1 pc and 1 ip phone on a 192.168.0.0/24 network on the other side, the DSL modem is a bridge-type, thus i have my internet ip on the NA eth0 interface. The DSL modem is actually a 15Mbit/1024Kbit ATM, but i want to limit the upload to 128Kbit/s, to test the Voip thing. You can patch for accurate atm rates - it may be in kernel/for hfsc aswell one day. http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ You can also make htb more accurate if you change a define in net/sched/sched_htb.c - HYSTERESIS 0. If you don't patch you will need to set the sum of rates/ceils to well below 1024 (if that's showtime rate). My plan: HTB qdisc with overall rate at 128kbit, and 2 classes, one with prio 1 (for VoIP) and one with prio 2 (For other data), each of them rated a 1kbit/s and ceiled at 128kbit/s. And, on top of this, SFQ qdiscs for fairness. So : $TC qdisc add dev eth0 root handle 1: htb default 3 It's best not to use default on eth when shaping for some other bottleneck, that way arp and other eth frames get let through unshaped by htb. You should use tc/iptables to send unmatched/classified IP to your own default class. $TC class add dev eth0 parent 1: classid 1:1 htb rate 128kbit burst 6k $TC class add dev eth0 parent 1:1 classid 1:2 htb quantum 1600 rate 1kbit ceil 128kbit prio 1 It will be better to give rate 127kbit to the rt traffic. $TC qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10 I would use bfifo for rt and think about queue length, though an rt class usually shouldn't be backlogged. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and per-connection bandwidth allocation
El Thursday 14 September 2006 05:55, Namitha Rao escribió: Hi http://mailman.ds9a.nl/pipermail/lartc/2002q3/004977.html I have the same problem to discuss as in the above link. I want to allocate say X MBit per individual connection regardless of the number of connection . KIndly could anyonen suggest me how to proceed. I have tried with SFq but is doesnot yeild my requirement.. With CONTRACK/CONNMARK you can get an individual mark per connection, then you will need to allocate dinamic qdisc/class/filter to match that mark. Problems that i see: -do not know if there is an easy way to know wath mark was assigned, but you can allways 'use the source' -do not have experience adding and deleting qdisc/class/filter in milisecond basis. Not shure at all, but i think that is possible. -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB and tc filter
d3xcrIpt wrote: Help me ... I try use the tc filter, but seems he doesn't work, I already reconfigured my kernel ( 2.4.32 ) with all options related a QOS enabled ( like modules ) and nothing happens. I get the tc tool from HTB source package, well this is my set : eth0 is my internal NIC. tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src my_ip flowid 1:10 tc qdisc add dev eth0 parent handle 20: pfifo limit 5 tc qdisc add dev eth0 parent handle 30: pfifo limit 5 tc qdisc add dev eth0 parent handle 40: sfq perturb 10 OK. but ... when I look the qdiscs tc -s -d qdisc qdisc htb 1: r2q 10 default 12 direct_packets_stat 411 ver 3.17 Sent 181174 bytes 1324 pkts (dropped 0, overlimits 0) qdisc pfifo 20: parent 1:10 limit 5p Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc pfifo 30: parent 1:11 limit 5p Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 40: parent 1:12 quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 130091 bytes 866 pkts (dropped 0, overlimits 0) All traffic is going to default class ( 1:12 ), I try many filters with tc tool but nothing happens. I look the modules with lsmod and cls_u32.o and sch_htb.o is all loaded. Thanks everyone. u32 match ip src my_ip Are you sure your IP isn't getting NATted somewhere? You can't match something that is changed! Include a prio (non zero) in your filter line. Direct packets are A Bad Thing too. Read Devik's HTB documentation. -- gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb traffic shaping problem
Good afternoon,your configuration seems correct to me. Could you send us the output of tc -s -d class show dev eth0 during your probes?What kernel and tc versions are you using?Regards,Eric Janz Departamento de SistemasGrupo Barceló ViajesC\ 16 de Julio, 7507009 Polígono Son CastellóPalma de Mallorca - BalearesTel.: +34 971 448030Fax.: +34 971 436986Bugzilla-Redirect [EMAIL PROTECTED]Enviado por: [EMAIL PROTECTED]08/09/2006 10:02Paralartc@mailman.ds9a.nlccAsunto[LARTC] htb traffic shaping problemHello.I have a linux server connected to a gigabit lan, and though that lan to a 768kbps/768kbps DSL modem.I'm trying to shape my webserver running on port 80/443 down to 512kbps, while leaving all other ports alone. The current configuration script that I'm using is as follows:tc qdisc del dev eth0 roottc qdisc add dev eth0 root handle 1: htb default 99tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbittc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbittc qdisc add dev eth0 parent 1:10 handle 10: sfqtc class add dev eth0 parent 1:1 classid 1:99 htb rate 900mbit ceil 1000mbittc qdisc add dev eth0 parent 1:99 handle 99: sfqtc filter add dev eth0 protocol ip parent 1: u32 match ip sport 80 0x flowid 1:10tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 443 0x flowid 1:101:10 seems to be getting the correct traffic from port 80 and 443 while everything else is run to 1:99. The problem is that, while 1:10 is slowing the connection down to a degree, it's nowhere near the set limit. For example: the connection will start out around 50kBps, and then suddenly bounce to over 1MBps, far exceeding it's 64kBps setting.Setting the parent down to 512kbits seems to work correctly, but it cripples the local network.Can anyone point out what I've done incorrectly, or is this a bug?Thank you.-Ryan Power ___LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] htb traffic shaping problem
Hi, I have a similar setup here, and what I did was instead of shaping the traffic with tc, I used mod_cband on apache2 to limit concurrent connections and bandwidth. There is a very helpful reference on getting it up and running here: http://www.howtoforge.com/mod_cband_apache2_bandwidth_quota_throttling Hope that helps a bit Charlie Meyer University of Illinois at Urbana-Champaign Department of Computer Science - Undergraduate [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 08, 2006 7:40 AM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] htb traffic shaping problem Good afternoon, your configuration seems correct to me. Could you send us the output of tc -s -d class show dev eth0 during your probes? What kernel and tc versions are you using? Regards, Eric Janz Departamento de Sistemas Grupo Barceló Viajes C\ 16 de Julio, 75 07009 Polígono Son Castelló Palma de Mallorca - Baleares Tel.: +34 971 448030 Fax.: +34 971 436986 Bugzilla-Redirect [EMAIL PROTECTED] Enviado por: [EMAIL PROTECTED] 08/09/2006 10:02 Para lartc@mailman.ds9a.nl cc Asunto [LARTC] htb traffic shaping problem Hello. I have a linux server connected to a gigabit lan, and though that lan to a 768kbps/768kbps DSL modem. I'm trying to shape my webserver running on port 80/443 down to 512kbps, while leaving all other ports alone. The current configuration script that I'm using is as follows: tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 99 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit tc qdisc add dev eth0 parent 1:10 handle 10: sfq tc class add dev eth0 parent 1:1 classid 1:99 htb rate 900mbit ceil 1000mbit tc qdisc add dev eth0 parent 1:99 handle 99: sfq tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 80 0x flowid 1:10 tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 443 0x flowid 1:10 1:10 seems to be getting the correct traffic from port 80 and 443 while everything else is run to 1:99. The problem is that, while 1:10 is slowing the connection down to a degree, it's nowhere near the set limit. For example: the connection will start out around 50kBps, and then suddenly bounce to over 1MBps, far exceeding it's 64kBps setting. Setting the parent down to 512kbits seems to work correctly, but it cripples the local network. Can anyone point out what I've done incorrectly, or is this a bug? Thank you. -Ryan Power ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb prioritise trafic
On Tuesday 22 August 2006 02:27, Adorean Alexandru Raul wrote: I have a router with about 300 clients connecting to it. It has htb with a class per client. I wnat to create a script to prioritise www trafic and ssh trafic over p2p trafic this is a sample of what i have now: /sbin/tc class add dev eth0 parent 1:5 classid 1:8012 htb rate 35Kbit ceil 281Kbit prio 6 /sbin/tc qdisc add dev eth0 parent 1:8012 handle 8012 sfq perturb 8 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src 81.181.180.21 classid 1:8012 /sbin/tc class add dev eth1 parent 1:5 classid 1:8012 htb rate 35Kbit ceil 281Kbit prio 6 /sbin/tc qdisc add dev eth1 parent 1:8012 handle 8012 sfq perturb 8 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst 81.181.180.21 classid 1:8012 this is one client. I found something on wiki.lug.ro but i could not adapt it to my neads. Thank you for your time. htb-gen[1] does exactly that, in a per-client basis and you can customize what is prio and what is not. And of course all gets automated. [1]http://freshmeat.net/projects/htb-gen/ PS: There is a new version comming(with lot of improbs)... but in a few weeks. -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB shaping borrowing info
On Sat, May 27, 2006 at 11:28:12PM +0200, Stefano Mainardi wrote: The goal is to divide the traffic for classes of workstations, at example in three classes, let say A, B and C. Sounds simple enough... If B don't make traffic, 7/8 of 20Mb/s must be assigned to A and all the rest at B Why would you assign traffic at B if it doesn't make traffic? We have used CBQ and HTB, with poor succes. Anybody can help me please? Post your HTB script and I (and probably others) will have a look at it. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On Mon, 15 May 2006, Larry Brigman wrote: On 5/14/06, Jesper Dangaard Brouer [EMAIL PROTECTED] wrote: On Fri, 12 May 2006, Muthukumar S wrote: cut Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. cut The kernel timer resolution does have an impact on the precision of HTB (the delay jitter). I have done some detailed studies in my master thesis. Which is located at: http://www.adsl-optimizer.dk/thesis/. looks like the site is down, at least for me. It is up again... I have just restarted apache, don't know why apache was dead... Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
Muthukumar S wrote: Iperf has a demonstrated behavior that when running more than one copy at the same time on the same box (client side); that the timing of each will start to effect the other copies. This is a function of how Iperf does it's timing (spin loops). What traffic generators would you recommend? What do other members use? Has anyone used TG (http://www.postel.org/tg/)? Whatever you use if it's tcp and you run multi instances I wouldn't take much note about the numbers it gives. In your case - at high speed polling counters would be a better way to see things. I've done more in the way of wan speed testing and tbf/htb are not very good at simulating a slow link. HFSC is better. If you care about tcp then you need to use netem aswell to add some delay. If you don't then because the first packets don't get delayed the tcp sender knows you are on a lan and will/did (maybe bic) behave differently, like retransmitting a chunk of packets while the first bulk onees are sitting in your buffer waiting. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On 5/14/06, Jesper Dangaard Brouer [EMAIL PROTECTED] wrote: On Fri, 12 May 2006, Muthukumar S wrote: cut Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. cut The kernel timer resolution does have an impact on the precision of HTB (the delay jitter). I have done some detailed studies in my master thesis. Which is located at: http://www.adsl-optimizer.dk/thesis/. looks like the site is down, at least for me. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On Fri, 12 May 2006, Muthukumar S wrote: cut Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. cut The kernel timer resolution does have an impact on the precision of HTB (the delay jitter). I have done some detailed studies in my master thesis. Which is located at: http://www.adsl-optimizer.dk/thesis/. You should look at chapter 7. Read section 7.3.2 Timer Granularity (page 71) and section 7.3.3 Improving Granularity (page 73) Figure 7.8 (page 75), shows how the delay jitter bound is improved when changing the timer from HZ=100 to HZ=1500. For the discusion about, why the you need to reduce the bandwidth to less that the actual bandwidth, you should look at Chapter 6 Achieving Queue Control. Especially if you have an ADSL link. Greeting, Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
I'll try using 450 K and setting a higher ceil to see how it works. Also I was wondering what limits (if any) the kernel timer resolution imposes on HTB. Thanks! Muthu On 5/11/06, Jody Shumaker [EMAIL PROTECTED] wrote: On 5/10/06, Muthukumar S [EMAIL PROTECTED] wrote: First up, thanks for the response Jody. I appreciate your taking the time to answer. So in essence what this means is that I will not be able to use the maximum that the link allows if I'm shaping traffic? Please correct me if I got this wrong - let's say my ISP claims 512 Kbit/s upload and real throughput varies between 450 Kbit/s and 500 Kbit/s. So if I shaped traffic using 450 Kbit/s as the root qdisc, I would lose out on the occasions when the line does allow more than 450 Kbit/s? Unfortunately yes, if you want the shaping to work well you need to set it appropiately. No real way to have it vary dynamically. Basically what happens when you're not the bottleneck is that ping times will go up as data will queue at the other bottleneck, and your bandwidth allotments will no longer accurately represent the connection. They'll have less of an effect as TCP throttling starts having to kick in. I imagine if you designed the rules you could have the ratio between your classes still honored, and only have the increased lag or possibility for packet loss. To do this if you knew it was always atleast 450k but sometimes 500k, set the rates for all the child classes to add up to 450k, but use 500k as the highest ceiling and for the base class. Then in this case it should still continue to split the 450k evenly between the classes as you described, but still using up to the 500k when its available. Not sure how well this would work though as I've usually been more concerned with keeping the latency down, and set the ceil such that the majority of the time its slightly below the real bandwidth. - Jody P.S. Thanks for forwarding the email to the list, I alway forget to hit reply to all. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
Iperf has a demonstrated behavior that when running more than one copy at the same time on the same box (client side); that the timing of each will start to effect the other copies. This is a function of how Iperf does it's timing (spin loops). What traffic generators would you recommend? What do other members use? Has anyone used TG (http://www.postel.org/tg/)? Thanks! - Muthu ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On 5/12/06, Muthukumar S [EMAIL PROTECTED] wrote: Iperf has a demonstrated behavior that when running more than one copy at the same time on the same box (client side); that the timing of each will start to effect the other copies. This is a function of how Iperf does it's timing (spin loops). What traffic generators would you recommend? What do other members use? Has anyone used TG (http://www.postel.org/tg/)? I have looked at TG but would recommend D-ITG (http://www.grid.unina.it/software/ITG/) at this point as it seems to have more work recently. That said I have downloaded TG but have not ran it too much. Back to Iperf. The reason I mention the timing issue is, really only an issue when you are running multiple copies and you really want very stable inter-packet timing. If you want to use Iperf for bandwidth testing and want to run multiple copies. Get the source and find the client send routines where it is using the delay function and replace that with usleep. This change allows (in my testing) upwards of 15 copies of Iperf running at the same time without major interactions. For a single stream Iperf is the most flexible program of the bunch Just for info, here is a site that has both monitoring (mostly) tools and traffic generation tools. http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On Friday 12 May 2006 12:35, Muthukumar S wrote: Iperf has a demonstrated behavior that when running more than one copy at the same time on the same box (client side); that the timing of each will start to effect the other copies. This is a function of how Iperf does it's timing (spin loops). What traffic generators would you recommend? What do other members use? Has anyone used TG (http://www.postel.org/tg/)? Activate chargen as tcp or udp stream at any port using inetd or xinetd. Then for tcp tests*: curl http://$host:$port/ /dev/null or cd /dev/ lftpget http://$host:$port/null both show traffic rate, but curl show more stats. For chargen udp test... don't know really, maybe netcat can help. * all this is a jjo-tip[tm] -- Luciano -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
Forwarding this to the list just so its in the archives. -- Forwarded message -- From: Larry Brigman [EMAIL PROTECTED] Date: May 11, 2006 10:16 AM Subject: Re: [LARTC] HTB at 100+ Mbits/sec To: Muthukumar S [EMAIL PROTECTED] On 5/10/06, Muthukumar S [EMAIL PROTECTED] wrote: Hello all, I've been trying to test HTB performance for different link bandwidths to find potential limits and this is what I have so far: http://home.comcast.net/~msethuraman/htbtest/ Can members please go over the setup, test procedure and the results and answer a few questions? 1. Is the testing methodology okay and can the results be considered accurate? If so, is this a decent representation of behavior outside the lab? Iperf has a demonstrated behavior that when running more than one copy at the same time on the same box (client side); that the timing of each will start to effect the other copies. This is a function of how Iperf does it's timing (spin loops). If you are just wanting to test HTB, the router/bw limiter will be in the way of making accurate measurements of what HTB is doing to the traffic. Also with the router in the middle and using TCP; TCP will try to level itself to the path bw between the end points. UDP might be a better method here as you have no round trip. 2. Does anyone know of any limits (theoretical or observed) beyond which HTB will not work or will be inaccurate? None that I know of. Most likely the limits will be that of the driver/hardware not allowing you to reach wire saturation (ie YMMV). 3. I've never quite understood the recommendation for setting the root HTB to 85-90% of the link. All these tests used 100%. Can someone please explain or point me to some explanations for the 90% recommendation and why it is considered necessary? The basic reasoning for limiting to 100% of link rate is to make sure none of the choke points on the path have any reason to discard your packets. The burst and cburst parameters allow HTB to overstep the limited rate for some period of time when coming from an under-utilized link. This burst rate may be enough for your cable/DSL modem which does not have a large buffer to discard packets. Most of what I have seen here seem to indicated that a 95-98% of link rate when using rate-shaping disciplines typically works well provided you don't have too large of burst parameters. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB at 100+ Mbits/sec
On 5/10/06, Muthukumar S [EMAIL PROTECTED] wrote: First up, thanks for the response Jody. I appreciate your taking the time to answer. So in essence what this means is that I will not be able to use the maximum that the link allows if I'm shaping traffic? Please correct me if I got this wrong - let's say my ISP claims 512 Kbit/s upload and real throughput varies between 450 Kbit/s and 500 Kbit/s. So if I shaped traffic using 450 Kbit/s as the root qdisc, I would lose out on the occasions when the line does allow more than 450 Kbit/s? Unfortunately yes, if you want the shaping to work well you need to set it appropiately. No real way to have it vary dynamically. Basically what happens when you're not the bottleneck is that ping times will go up as data will queue at the other bottleneck, and your bandwidth allotments will no longer accurately represent the connection. They'll have less of an effect as TCP throttling starts having to kick in. I imagine if you designed the rules you could have the ratio between your classes still honored, and only have the increased lag or possibility for packet loss. To do this if you knew it was always atleast 450k but sometimes 500k, set the rates for all the child classes to add up to 450k, but use 500k as the highest ceiling and for the base class. Then in this case it should still continue to split the 450k evenly between the classes as you described, but still using up to the 500k when its available. Not sure how well this would work though as I've usually been more concerned with keeping the latency down, and set the ceil such that the majority of the time its slightly below the real bandwidth. - Jody P.S. Thanks for forwarding the email to the list, I alway forget to hit reply to all. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB How To ??
On Monday April 17 2006 18:56, Cahyo Purnomo wrote: Dear All, I wanna to implement of bandwith shapingin my office using HTB, any body suggest about the case ? Below the acl ip range i want to limit : 1. staf (10.0.0.1 - 3) -- limit to 10kbyte/s 2. lab (10.0.0.4 - 6) -- limit to 5kbyte/s 3. bos (10.0.0.7 - 9) -- limit to 20kbyte/s 4. admin (10.0.0.10 - 12) -- no limit thanks all 4 ur advise Please read first the manual at lartc.org Regards, Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - Rate errors
El Wednesday 26 April 2006 13:00, Luke McConnell escribió: Hi, I'm trying to get HTB working correctly on Centos4 (RHEL-based) with kernel 2.6.9-34.EL. I have two gigabit network interfaces bridged together and I have created the following: tc qdisc add dev eth2 root handle 1: htb default 1 r2q 8000 tc class add dev eth2 parent 1: classid 1:1 htb rate 100Mbit burst 24k cburst 24k (I have been trying different parameters). The network is passing ~80MBits of traffic but HTB is not seeing the rate correctly (which obviously causes problems when I try to shape a sub-set of the traffic). These are approx 1 second apart: [root@ ~]# tc -s -d class sh dev eth2 class htb 1:1 root prio 0 quantum 1562 rate 100Mbit ceil 100Mbit burst 24Kb/8 mpu 0b overhead 0b cburst 24Kb/8 mpu 0b overhead 0b level 0 Sent 654872932 bytes 830973 pkts (dropped 0, overlimits 0 requeues 0) rate 7827086bit 9941pps lended: 830973 borrowed: 0 giants: 0 tokens: 1479 ctokens: 1479 [root@ ~]# tc -s -d class sh dev eth2 class htb 1:1 root prio 0 quantum 1562 rate 100Mbit ceil 100Mbit burst 24Kb/8 mpu 0b overhead 0b cburst 24Kb/8 mpu 0b overhead 0b level 0 Sent 663902498 bytes 842747 pkts (dropped 0, overlimits 0 requeues 0) rate 7827086bit 9941pps lended: 842747 borrowed: 0 giants: 0 tokens: 1527 ctokens: 1527 That's a transfer of around 9MBytes, yet HTB is only reporting just under 8Mbits/sec. Has anyone got any suggestions for me to try? CentOS's tc version(iproute2-ss040831) is known to have buggy rates(at least for htb). You have to multiply by 8 the rate value. You can use htb-stats[1] script made bye jjo ciarlante, it is bery usefull to see real-time htb class rates, this script has a (soft)fix for the bug in CentOS and display htb rates correctly. [1] http://freshmeat.net/projects/htb-stats/ -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: One more thing I just thought - sfq sets its quantum from the dev mtu. Riiight. I should have tried without the sfq earlier. Without it this works as expected without explicit mtu setting for the htb class. And no giants. # tc qdisc add dev eth0 root handle 1: htb # tc class add dev eth0 parent 1: classid 1:2 htb rate 2Mbit # tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 50 fw flowid 1:2 I wouldn't have expected that to make any difference to the giants. Looking again at your stats - Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0) rate 3484Kbit 45pps backlog 0b 0p requeues 0 lended: 20627 borrowed: 0 giants: 30926 tokens: -9768 ctokens: -9768 The giants count is higher than the packet count so now I am really confused. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Andy Furniss wrote: Looking again at your stats - Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0) rate 3484Kbit 45pps backlog 0b 0p requeues 0 lended: 20627 borrowed: 0 giants: 30926 tokens: -9768 ctokens: -9768 The giants count is higher than the packet count so now I am really confused. Doh - I suppose thats just the way HTB counts so you add them together. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Andy Furniss wrote: Andy Furniss wrote: Looking again at your stats - Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0) rate 3484Kbit 45pps backlog 0b 0p requeues 0 lended: 20627 borrowed: 0 giants: 30926 tokens: -9768 ctokens: -9768 The giants count is higher than the packet count so now I am really confused. Doh - I suppose thats just the way HTB counts so you add them together. LOL - Third try, testing on lo which is confusing and maybe misleading but it looks like the giants count gets doubled up but the packet count doesn't. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: On Sun, 2006-04-16 at 19:40 +0100, Andy Furniss wrote: Yanko Kaneti wrote: On Sun, 2006-04-16 at 03:03 +0100, Andy Furniss wrote: Yanko Kaneti wrote: Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Hmm I didn't expect that - maybe there is some problem with the nic drivers not obeying kernel - is there any tso offload etc. at work here ? Yes and its on by default. The interface mtu still says 1500. I've tried deleting and attaching the qdisc+class (without explicit large mtu) with both tso on (ethtool -K eth0 tso on) and tso off , it doesnt seem to matter - giants appear in both cases. With large mtu for the class no giants with both tso on and off. I think you need to ask fedora or intel driver maintainer about this. AIUI tso is not in vanilla kernels and the patches are quite invasive. Well, as much as google tells me TSO has been in the kernel and enabled since 2.5.33 and e1000 was the first driver to support it. The FC4 2.6.16 kernel doesn't have any tso related patches as can be seen here http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-4/ Since my immediate problem was solved with the mtu param I plan on forgetting about htb and traffic control in general for the time being :) Thanks again. One more thing I just thought - sfq sets its quantum from the dev mtu. While I always thought that the must be =mtu comment in the source was a bit OTT, it still should be = mtu for the drr to be 0(1) for cpu work. You can set it explicitly by adding quantum=X on the sfq line. For ethernet X is mtu + 14. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
On Mon, 2006-04-17 at 21:32 +0200, Patrick McHardy wrote: Andy Furniss wrote: Well, as much as google tells me TSO has been in the kernel and enabled since 2.5.33 and e1000 was the first driver to support it. The FC4 2.6.16 kernel doesn't have any tso related patches as can be seen here http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-4/ Since my immediate problem was solved with the mtu param I plan on forgetting about htb and traffic control in general for the time being :) Thanks again. One more thing I just thought - sfq sets its quantum from the dev mtu. Riiight. I should have tried without the sfq earlier. Without it this works as expected without explicit mtu setting for the htb class. And no giants. # tc qdisc add dev eth0 root handle 1: htb # tc class add dev eth0 parent 1: classid 1:2 htb rate 2Mbit # tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 50 fw flowid 1:2 One more possibility: current kernels support UDP fragmentation offload (UFO), which has similar effects as TSO. The in-tree e1000 driver doesn't support it, but maybe the fedora one does. No mention of ufo or e1000 in any of the patches that can be found in the url above. Changes in the fragmentation behaviour of conntrack in 2.6.16 could also be responsible (if you're using it). Can you please post your NAT and marking rules, routing rules etc? Here are the interesting rules where the packets in question pass. Have no rules other than the ones in the mangle table mangle OUTPUT -m owner --uid-owner shaped -j userchain userchain -m length --length 512:65535 -j MARK --set-mark 0x32 - the fw filter ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: On Sun, 2006-04-16 at 03:03 +0100, Andy Furniss wrote: Yanko Kaneti wrote: Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Hmm I didn't expect that - maybe there is some problem with the nic drivers not obeying kernel - is there any tso offload etc. at work here ? Yes and its on by default. The interface mtu still says 1500. I've tried deleting and attaching the qdisc+class (without explicit large mtu) with both tso on (ethtool -K eth0 tso on) and tso off , it doesnt seem to matter - giants appear in both cases. With large mtu for the class no giants with both tso on and off. Yanko I think you need to ask fedora or intel driver maintainer about this. AIUI tso is not in vanilla kernels and the patches are quite invasive. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
On Sun, 2006-04-16 at 19:40 +0100, Andy Furniss wrote: Yanko Kaneti wrote: On Sun, 2006-04-16 at 03:03 +0100, Andy Furniss wrote: Yanko Kaneti wrote: Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Hmm I didn't expect that - maybe there is some problem with the nic drivers not obeying kernel - is there any tso offload etc. at work here ? Yes and its on by default. The interface mtu still says 1500. I've tried deleting and attaching the qdisc+class (without explicit large mtu) with both tso on (ethtool -K eth0 tso on) and tso off , it doesnt seem to matter - giants appear in both cases. With large mtu for the class no giants with both tso on and off. I think you need to ask fedora or intel driver maintainer about this. AIUI tso is not in vanilla kernels and the patches are quite invasive. Well, as much as google tells me TSO has been in the kernel and enabled since 2.5.33 and e1000 was the first driver to support it. The FC4 2.6.16 kernel doesn't have any tso related patches as can be seen here http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-4/ Since my immediate problem was solved with the mtu param I plan on forgetting about htb and traffic control in general for the time being :) Thanks again. Cheers Yanko ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: I think you need to ask fedora or intel driver maintainer about this. AIUI tso is not in vanilla kernels and the patches are quite invasive. Well, as much as google tells me TSO has been in the kernel and enabled since 2.5.33 and e1000 was the first driver to support it. The FC4 2.6.16 kernel doesn't have any tso related patches as can be seen here http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-4/ Ahh OK I must have been thinking of another card. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: Hi Here is something that worked with with 2.6.10-1.771_FC2smp and stopped working when I upgraded to 2.6.16-1.2069_FC4smp. These are fedora kernels and the network controller is an Intel Gbit (e1000) running a 100 Mbps Full Duplex. Don't know how or if this matters but the 2.6.10 kernel has CONFIG_X86_HZ=1000 and the 2.6.16 has CONFIG_HZ=250 The idea is to just shape to , say 2Mbit, a certain kind of traffic everything else should goes unshaped. # tc qdisc add dev eth0 root handle 1: htb default 20 Why default 20 - if you don't have 1:20 it would be better to use default 0 which is unshaped and is the default - so ommitting default is the same - unclassifed traffic goes through unshaped. # tc class add dev eth0 parent 1: classid 1:2 htb rate 2Mbit # tc qdisc add dev eth0 parent 1:2 sfq perturb 10 # tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 50 fw flowid 1:2 This was working as expected with 2.6.10 I've tried creating a proper 1:1 100Mbit parent to be the default but it didn't help. And it was working fine without it on 2.6.10 With the 2.6.16 kernel I get results like # tc -s -d class show dev eth0 class htb 1:2 root leaf 800b: prio 0 quantum 25000 rate 2000Kbit ceil 2000Kbit burst 2600b/8 mpu 0b overhead 0b cburst 2600b/8 mpu 0b overhead 0b level 0 Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0) rate 3484Kbit 45pps backlog 0b 0p requeues 0 lended: 20627 borrowed: 0 giants: 30926 The giants are the problem - if you specify mtu X on 1:2 class it should work. Or you could consider setting mtu on nic to 1500 if that is practical for you ie. this traffic is headed somewhere that is going to frag it down to 1500 anyway. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
On Sun, 2006-04-16 at 00:13 +0100, Andy Furniss wrote: Yanko Kaneti wrote: Hi Here is something that worked with with 2.6.10-1.771_FC2smp and stopped working when I upgraded to 2.6.16-1.2069_FC4smp. These are fedora kernels and the network controller is an Intel Gbit (e1000) running a 100 Mbps Full Duplex. Don't know how or if this matters but the 2.6.10 kernel has CONFIG_X86_HZ=1000 and the 2.6.16 has CONFIG_HZ=250 The idea is to just shape to , say 2Mbit, a certain kind of traffic everything else should goes unshaped. # tc qdisc add dev eth0 root handle 1: htb default 20 Why default 20 - if you don't have 1:20 it would be better to use default 0 which is unshaped and is the default - so ommitting default is the same - unclassifed traffic goes through unshaped. No reason. I obviously missed the explanation for the 0 class. Will omit default in the future. # tc class add dev eth0 parent 1: classid 1:2 htb rate 2Mbit # tc qdisc add dev eth0 parent 1:2 sfq perturb 10 # tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 50 fw flowid 1:2 This was working as expected with 2.6.10 I've tried creating a proper 1:1 100Mbit parent to be the default but it didn't help. And it was working fine without it on 2.6.10 With the 2.6.16 kernel I get results like # tc -s -d class show dev eth0 class htb 1:2 root leaf 800b: prio 0 quantum 25000 rate 2000Kbit ceil 2000Kbit burst 2600b/8 mpu 0b overhead 0b cburst 2600b/8 mpu 0b overhead 0b level 0 Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0) rate 3484Kbit 45pps backlog 0b 0p requeues 0 lended: 20627 borrowed: 0 giants: 30926 The giants are the problem - if you specify mtu X on 1:2 class it should work. Or you could consider setting mtu on nic to 1500 if that is practical for you ie. this traffic is headed somewhere that is going to frag it down to 1500 anyway. Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Thanks Yanko ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
Yanko Kaneti wrote: Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Hmm I didn't expect that - maybe there is some problem with the nic drivers not obeying kernel - is there any tso offload etc. at work here ? Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb overrate with 2.6.16
On Sun, 2006-04-16 at 03:03 +0100, Andy Furniss wrote: Yanko Kaneti wrote: Setting mtu 16500 for the class fixed it. But I wonder where did these giants come from in the first place? The mtu of the interface is and was 1500. Or so ifconfig and ip link tell me. Or this is some other mtu we are talking about... Hmm I didn't expect that - maybe there is some problem with the nic drivers not obeying kernel - is there any tso offload etc. at work here ? Yes and its on by default. The interface mtu still says 1500. I've tried deleting and attaching the qdisc+class (without explicit large mtu) with both tso on (ethtool -K eth0 tso on) and tso off , it doesnt seem to matter - giants appear in both cases. With large mtu for the class no giants with both tso on and off. Yanko ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB statistics granularity
b) Is there a way to get a precise rate and pps for the last 10 seconds? (issue of rate taking 3-4 mins to get to zero as opposed to instantly) Run the command, record the number of bytes and packets sent. (tc -s class show dev ppp0) Wait exactly 10 seconds (sleep 10) Run the command again, record the new values (tc -s class show dev ppp0) Compare the difference between the bytes and packets sent, divide by 10. As to the rest of your questions, I have no idea. I've only ever used the rate from the commend to get a rough idea of the current rate. Otherwise I use the bytes sent measurement to generate some rrdgraph's in which case doing measurements of bytes sent every 60 seconds is perfectly accurate for those 60 seconds as long as roll-over hasn't occured. - Jody ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb and priorizing class
On Fri, Mar 24, 2006 at 04:56:44PM +0100, Fabio wrote: Is this a configuration problem? Also, when I set tc rules I get: quantum of class is big. Consider r2q change Well, that message can be avoided by configuring quantum properly (not always possible if difference between rates is too huge) or by setting r2q for each class manually. For more about quantum r2q, see for example: http://www.docum.org/docum.org/faq/cache/31.html This may fix your problem or not, if it doesn't, can you post the tc commands you're using? Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Diego Andrés Asenjo Gonzalez wrote: Hi again! $IPT -A FORWARD -t mangle -p udp -s 172.16.0.185/32 -i eth1 --sport 1:10100 -d 172.16.1.0/24 -j MARK --set-mark 0x44 This should be -o eth1 or you should be shaping it on eth0 or if it's for the shaping box you need to do some sort of ingress shaping/policing. Sorry, a typo :p. You pointed clearly the -o eth1 in the previous message. Really, is the first time that I use -i or -o in the rule. One point is that the box is a bridge between a LAN and a router, eth0 is in the LAN and eth1 in the router. So, I thought I can ommit the interface. Anyway, I think that this is an strange situation: there are marked (maybe not well marked) packages, but there is no traffic. I am trying with the -o option. It could be the bridging - I've never tried maybe you could look into ebtables or just use tc/u32 to do the matching. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Diego Andrés Asenjo Gonzalez ha scritto: Sorry, a typo :p. You pointed clearly the -o eth1 in the previous message. Really, is the first time that I use -i or -o in the rule. One point is that the box is a bridge between a LAN and a router, eth0 is in the LAN and eth1 in the router. So, I thought I can ommit the interface. You have to use physdev on a bridge (-m physdev --physdev-out eth1). -- ** Marco Innocenti Gruppo Infrastruttura e Sicurezza CINECA phone:+39 0516171553 / fax:+39 0516132198 Via Magnanelli 6/3 e-mail: [EMAIL PROTECTED] 40033 Casalecchio di RenoBologna (Italia) ** ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
El Thursday 02 March 2006 12:59, Andy Furniss escribió: Diego Andrés Asenjo Gonzalez wrote: Hi again! $IPT -A FORWARD -t mangle -p udp -s 172.16.0.185/32 -i eth1 --sport 1:10100 -d 172.16.1.0/24 -j MARK --set-mark 0x44 This should be -o eth1 or you should be shaping it on eth0 or if it's for the shaping box you need to do some sort of ingress shaping/policing. Sorry, a typo :p. You pointed clearly the -o eth1 in the previous message. Really, is the first time that I use -i or -o in the rule. One point is that the box is a bridge between a LAN and a router, eth0 is in the LAN and eth1 in the router. So, I thought I can ommit the interface. Anyway, I think that this is an strange situation: there are marked (maybe not well marked) packages, but there is no traffic. I am trying with the -o option. It could be the bridging - I've never tried maybe you could look into ebtables or just use tc/u32 to do the matching. Setting the apropiates routes and proxy_arp in 1, is a way to do a bridge but at ip layer. This allows to use iptables and other ip layer tools whitouth any problem, and it's completly transparent as the bridge. Use iptables for a bridge is certanly not a good idea. That's why ebtables was created. -- Luciano -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Hello! Thanks to all for your responses. [EMAIL PROTECTED] wrote: You have to use physdev on a bridge (-m physdev --physdev-out eth1). Yes, you are right. Taken from ebtables FAQ: * Can I use ebtables with iptables? Yes, it's possible to use ebtables together with iptables, there are no incompatibility issues. * I'm using a 2.6 or higher kernel and my iptables rules won't match on the bridge port devices, what's wrong? Instead there is now an iptables match module, called |physdev|, that can be used to filter on the bridge ports. I hope physdev is going to be the solution. Bye and thanks again. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Diego Andrés Asenjo Gonzalez wrote: Hi everybody! I'm using an edge bridge box with two ethernet cards to shape traffic in a WAN link. I'm running Debian 3.1 stable with kernel 2.6.8 and iproute from packages. I recompiled the kernel with the following built-in options: [*] 802.1d Ethernet Bridging [*] QoS and/or fair queueing * HTB packet scheduler * SFQ queue [*] QoS support * Firewall based classifier * U32 classifier As I select everything I don't know if this is enough - also I think you need to select classify in netfilter the section. I can mark packages with iptables, but I _can't_ make the packages get queued in an specific class. Please, take a look on this sample script that guarantees 64kbit (rate), 72kbit (ceil) It's nicer with htb to give interactive more bandwidth and higher prio than bulk. Also remember when setting rates that htb will see ip packets as ip length + 14 when used on ethX to the packets coming from the host 172.16.0.185 to the 172.16.1.0/24 network with 1-10100 destination ports: # Flush tc qdiscs: /sbin/tc qdisc del dev eth0 root /dev/null 21 /sbin/tc qdisc del dev eth1 root /dev/null 21 # Create root qdiscs: /sbin/tc qdisc add dev eth0 root handle 1: htb default 1000 /sbin/tc qdisc add dev eth1 root handle 2: htb default 1000 # Create root class (1:1 2:1) : /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 3456kbit ceil 3456kbit burst 0 prio 1 /sbin/tc class add dev eth1 parent 2: classid 2:1 htb rate 3584kbit ceil 3584kbit burst 0 prio 1 # Create default class (1:1000 2:1000) : /sbin/tc class add dev eth0 parent 1:1 classid 1:1000 htb rate 3350kbit ceil 3500kbit burst 0 prio 5 /sbin/tc class add dev eth1 parent 2:1 classid 2:1000 htb rate 3350kbit ceil 3500kbit burst 0 prio 5 # Create classes (1:44 2:44) : /sbin/tc class add dev eth0 parent 1:1 classid 1:44 htb rate 64kbit ceil 72kbit burst 8kbit prio 1 quantum 1536 /sbin/tc class add dev eth1 parent 2:1 classid 2:44 htb rate 64kbit ceil 72kbit burst 8kbit prio 1 quantum 1536 # Flushing iptables rules: /sbin/iptables -F -t mangle # iptables classify /sbin/iptables -A POSTROUTING -t mangle -p udp -s 172.16.0.185/32 --sport 1:10100 -d 172.16.1.0/24 -j CLASSIFY --set-class 2:44 Now the statistics: bridge:~# iptables -L -t mangle -v 34302 2415K CLASSIFY udp -- anyany 172.16.0.185 172.16.1.0/24 udp spts:1:10100 CLASSIFY set 2:44 bridge:~# tc -s cl sh dev eth1 class htb 2:44 parent 2:1 prio 1 rate 64000bit ceil 72000bit burst 1023b cburst 1608b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 131070 ctokens: 183067 class htb 2:1 root rate 3584Kbit ceil 3584Kbit burst 2Kb cburst 2Kb Sent 4686617538 bytes 6922322 pkts (dropped 0, overlimits 0) rate 1936bit 2pps lended: 3691 borrowed: 0 giants: 0 tokens: 4461 ctokens: 4461 class htb 2:1000 parent 2:1 prio 5 rate 3350Kbit ceil 3500Kbit burst 2017b cburst 2Kb Sent 4686617538 bytes 6922322 pkts (dropped 0, overlimits 0) rate 1936bit 2pps lended: 6918631 borrowed: 3691 giants: 0 tokens: 4700 ctokens: 4543 As you can see, the packets are mraked by iptables but get queued through the default class. You need an -o eth1 in the iptables rule for a proper count. I'm getting frustated and I will appreciate all suggestions and comments. I'm using now -j CLASSIFY but I have used -j MARK and u32 tc filters with the same results. I am not sure what else is wrong I don't use classify, maybe check that there isn't any decimal/hex mismatch ie. try 0x44. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Hi and thanks for replying! As I select everything I don't know if this is enough - also I think you need to select classify in netfilter the section. I also select almost everything in the netfilter section, including MARK and CLASSIFY. I simplified the script mantaining the most important part (the outgoing traffic). I am now using the iptables MARK way, and still did not get any shape: #!/bin/bash TC=/sbin/tc IPT=/sbin/iptables # Flush tc qdiscs: $TC qdisc del dev eth1 root /dev/null 21 # Create root qdiscs: $TC qdisc add dev eth1 root handle 2: htb default 1000 # Create root class (1:1 2:1) : $TC class add dev eth1 parent 2: classid 2:1 htb rate 3584kbit ceil 3584kbit burst 0 prio 1 # Create default class (1:1000 2:1000) : $TC class add dev eth1 parent 2:1 classid 2:1000 htb rate 3300kbit ceil 3350kbit burst 0 prio 5 # Create classes (1/2:2 tel_pereira) : $TC class add dev eth1 parent 2:1 classid 2:2 htb rate 64kbit ceil 72kbit burst 8kbit prio 1 quantum 1536 # Create filters (100/200 + 2) $TC filter add dev eth1 protocol ip parent 2:0 prio 1 handle 0x44 fw flowid 2:2 # Flushing iptables rules: $IPT -F -t mangle $IPT -A FORWARD -t mangle -p udp -s 172.16.0.185/32 -i eth1 --sport 1:10100 -d 172.16.1.0/24 -j MARK --set-mark 0x44 The statistics remains the same: bridge:~# iptables -L -t mangle -v Chain FORWARD (policy ACCEPT 76M packets, 34G bytes) pkts bytes target prot opt in out source destination 1123 67380 MARK udp -- anyany 172.16.0.185 172.16.1.0/24 udp spts:1:10100 MARK set 0x44 There are iptables marks ... bridge:~# tc -s cl sh dev eth1 class htb 2:2 parent 2:1 prio 1 rate 64Kbit ceil 72Kbit burst 1023b cburst 1691b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 128000 ctokens: 187999 But nothing is queued through the specified class :s, there is no shaping at all. I'm going insane, ¿Could it be a bug? ¿A package error? Thanks for your help! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
On Wed, Mar 01, 2006 at 02:48:18PM +, Andy Furniss wrote: than bulk. Also remember when setting rates that htb will see ip packets as ip length + 14 when used on ethX Could you elaborate on this a bit? I suppose you also meant this in an earlier message when you mentioned that the overhead was not included in the bw calculations. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Diego Andrés Asenjo Gonzalez wrote: Hi and thanks for replying! As I select everything I don't know if this is enough - also I think you need to select classify in netfilter the section. I also select almost everything in the netfilter section, including MARK and CLASSIFY. I simplified the script mantaining the most important part (the outgoing traffic). I am now using the iptables MARK way, and still did not get any shape: Ahh OK $IPT -A FORWARD -t mangle -p udp -s 172.16.0.185/32 -i eth1 --sport 1:10100 -d 172.16.1.0/24 -j MARK --set-mark 0x44 This should be -o eth1 or you should be shaping it on eth0 or if it's for the shaping box you need to do some sort of ingress shaping/policing. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Andreas Hasenack wrote: On Wed, Mar 01, 2006 at 02:48:18PM +, Andy Furniss wrote: than bulk. Also remember when setting rates that htb will see ip packets as ip length + 14 when used on ethX Could you elaborate on this a bit? I suppose you also meant this in an earlier message when you mentioned that the overhead was not included in the bw calculations. Maybe maybe not - There are even more overheads than 14 on eth and I may also have meant dsl overheads which you need to allow for using patches because everything gets padded out to a whole number of ATM cells. As for the IP length + 14, it's because htb uses skb-len and on eth thats ip+14 on ppp it's just ip length - I don't know about other interfaces, you can use HTBs counters to test it. For eth I often see people use 10 or 100mbit as ceils without adding overheads to HTB - which you can (38-14=24 I suppose), but even then in practice you need to ceil at slightly less than 10/100mbit. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
Hi again! $IPT -A FORWARD -t mangle -p udp -s 172.16.0.185/32 -i eth1 --sport 1:10100 -d 172.16.1.0/24 -j MARK --set-mark 0x44 This should be -o eth1 or you should be shaping it on eth0 or if it's for the shaping box you need to do some sort of ingress shaping/policing. Sorry, a typo :p. You pointed clearly the -o eth1 in the previous message. Really, is the first time that I use -i or -o in the rule. One point is that the box is a bridge between a LAN and a router, eth0 is in the LAN and eth1 in the router. So, I thought I can ommit the interface. Anyway, I think that this is an strange situation: there are marked (maybe not well marked) packages, but there is no traffic. I am trying with the -o option. Andy. Thanks and bye. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change [Solved]
El Friday 24 February 2006 06:36, Andreas Klauer escribió: On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote: with vde_switch daemon listening in a tuntap device. I suppose that htb is device independet, i hope it does not matter. I don't have any experience with vde_switch and tuntap's (I don't even know what those are, so much for ignorance). The only device-dependent factor I came across with HTB so far is the overhead problem - not all devices have the same overhead (PPP over Ethernet or whatever). So HTB calculating the rate incorrectly is a possibility. It can be tuned using overhead/mpu parameters, however in order to do that, you'd need to know correct values first, and they can be a little hard to come by. I also doubt it's the cause of your problem in this case. you're rigth, and will not be the only time in this mail :-) class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7 The problem with this tree is that you took out the client class (the one with rate and ceil 23bit). When I said that child classes without siblings don't make sense, I didn't mean to actually take out the child class, but rather take out the parent of this child class; in your example that would mean making the 23bit class the root class. In your setup now, by just looking at the class tree, not the statistics, my guess would be that while each leaf class has a ceil of 23bit, they won't share the same 23kbit, but rather utilize the full 256kbit of their parent. That does not seem to be what you want. It still does not explain the rates in this setup, too. yes, once again you're rigth, but i consider it irrelevant for the test that i was doing. Anyway, as you say, it still does not explain the situation... Especially the rate of the parent class seems low - if this is a testing environment where you are filling out the classes to their maximum, it's really odd that the parent class does not use it's full bandwidth. On the other hand, I don't know how accurate the rate statistics of HTB are. I don't have access to a properly working shaping setup right now to verify wether it's the same on my setup. If it isn't, I'd probably check first how much rate HTB can actually use, because it's a very bad situation for HTB when it thinks it can use more bandwidth than the link actually can guarantee. For the third time you are so rigth, i boot a second virtual machine, and test the same htb setup betwen the two virtual machins and using my gentoo as firewall. Obviously the bandwhidth between them can be considered infinite, and the setup works properly. So i made severals test to the link whit i was testing before and at any moment i get real 256kbit/s. This expains all the situation. Shame on me!!! I've added a FAQ about this to my project after this. When i have a first public release(wich will be son), i will post here(if does not bother) for one time only the project url, and some words of what it does. For now i leave a stable snaphost of my git tree at git-clone http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/.git or simply point a browser to http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/ Many tanks for your help! -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb root don't reach ceil rate?
Markus Schulz wrote: Am Freitag, 10. Februar 2006 14:45 schrieb Markus Schulz: tc -s -d class show dev ppp0 class htb 1:1 root rate 576000bit ceil 576000bit burst 30Kb/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b overhead 14b level 7 Sent 1485575598 bytes 3140554 pkts (dropped 0, overlimits 0) rate 480008bit 115pps lended: 1904616 borrowed: 0 giants: 0 tokens: 385702 ctokens: -26458 ok, i've understand now. Differenz comes from gross versus net data rates due to overhead of ATM-SAR and pppoe-overhead. All statistic values are netto values. Yes - you can get patches to do egress overheads for dsl - if you know your exact type and are prepared to rebuild kernel or the modules and tc. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb root don't reach ceil rate?
ok, i've understand now. Differenz comes from gross versus net data rates due to overhead of ATM-SAR and pppoe-overhead. All statistic values are netto values. Yes - you can get patches to do egress overheads for dsl - if you know your exact type and are prepared to rebuild kernel or the modules and tc. Oops didn't see you were already patched - htb counters still see things at ip level. FWIW You still can't really use 576000 - one of my modems would do it's aaal5/0 qos in whole cells so being slightly less, also if you start/restart the shaper on a live link the queue formed may never empty. Running 286kbit on a 288kbit ATM rate line has never gone over for me and slowly drains if the modem buffer is full when started. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote: That's becouse the _real_ scenario will look like this: root-parent_all_hosts-client_host_1-prio -dfl [...] -client_host_N-prio -dfl Oh, okay, so you simplified it that way. All right. As you see, after 3 minutes the lower rate class has sent 3000 packets vs 1000 packets from the high rate one. Don't know what to think... There may be a misunderstanding between us, the way you modified your class tree now, it seems to have errors. I'll explain below. My test bed at this moment is a gentoo Right. No complaints here. ;-) with vde_switch daemon listening in a tuntap device. I suppose that htb is device independet, i hope it does not matter. I don't have any experience with vde_switch and tuntap's (I don't even know what those are, so much for ignorance). The only device-dependent factor I came across with HTB so far is the overhead problem - not all devices have the same overhead (PPP over Ethernet or whatever). So HTB calculating the rate incorrectly is a possibility. It can be tuned using overhead/mpu parameters, however in order to do that, you'd need to know correct values first, and they can be a little hard to come by. I also doubt it's the cause of your problem in this case. class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7 The problem with this tree is that you took out the client class (the one with rate and ceil 23bit). When I said that child classes without siblings don't make sense, I didn't mean to actually take out the child class, but rather take out the parent of this child class; in your example that would mean making the 23bit class the root class. In your setup now, by just looking at the class tree, not the statistics, my guess would be that while each leaf class has a ceil of 23bit, they won't share the same 23kbit, but rather utilize the full 256kbit of their parent. That does not seem to be what you want. It still does not explain the rates in this setup, too. Especially the rate of the parent class seems low - if this is a testing environment where you are filling out the classes to their maximum, it's really odd that the parent class does not use it's full bandwidth. On the other hand, I don't know how accurate the rate statistics of HTB are. I don't have access to a properly working shaping setup right now to verify wether it's the same on my setup. If it isn't, I'd probably check first how much rate HTB can actually use, because it's a very bad situation for HTB when it thinks it can use more bandwidth than the link actually can guarantee. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
On Thu, Feb 23, 2006 at 07:08:27PM -0300, Luciano Ruete wrote: root-parent_all_host(256,256)-client_host_1(X,X)-host_1_prio(X*0.9,X) -host_1_dfl(X*0.1,X) What's the purpose of the 256kbit class? In the setup you posted, the 200/230kbit child class does not seem to have any siblings. Except for the root class, classes without siblings don't make sense. At least, I haven't seen any useful purpose for them so far. I've attached simplified ad-hoc scripts that reproduce the scenarios: tc_at_200 (full tc/iptables commands to recreate the X200 scenario) tc_at_230 (full tc/iptables commands to recreate the X200 scenario) I haven't tested them, but they seem to be all right (except for the question above). I don't know if it will help at all, but could you post tc statistics for both 200 and 230 cases? You can get the statistics using 'tc -s -d qdisc/class show dev $iface' or similar command. Also, did you check wether HTB is complaining about anything in dmesg when setting up the 230 class tree? Which kernel version and iproute/tc version are you running? Just in case you're still suffering from old HTB bugs... Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
El Thursday 23 February 2006 19:38, Andreas Klauer escribió: On Thu, Feb 23, 2006 at 07:08:27PM -0300, Luciano Ruete wrote: root-parent_all_host(256,256)-client_host_1(X,X)-host_1_prio(X*0.9,X) -host_1_dfl(X*0.1,X) What's the purpose of the 256kbit class? In the setup you posted, the 200/230kbit child class does not seem to have any siblings. Except for the root class, classes without siblings don't make sense. At least, I haven't seen any useful purpose for them so far. That's becouse the _real_ scenario will look like this: root-parent_all_hosts-client_host_1-prio -dfl -client_host_2-prio -dfl -client_host_3-prio -dfl -client_host_N-prio -dfl I'will use this parent_all_host class to set the total_real iface rate. I've posted the reduced example for simplicity and to isolate the real problem. Anyway i've tested a new version of the example attaching the client direct to the root class witouth any luck. Script that i use for testing attached. Also full tc stadistics, taked from begining and after aprox 3~4 minutes. Here some highlights This is 'dfl' class class htb 1:7005 parent 1:7000[...]rate 23000bit ceil 23bit Sent 4521301 bytes 3095 pkt (dropped 0, overlimits 0 requeues 0) lended: 467 borrowed: 2628 giants: 0 tokens: -2193687 ctokens: 8085 This is 'prio' class class htb 1:7004 parent 1:7000[...]rate 207000bit ceil 23bit Sent 1741028 bytes 1168 pkt (dropped 0, overlimits 0 requeues 0) lended: 1168 borrowed: 0 giants: 0 tokens: 397670 ctokens: 8085 As you see, after 3 minutes the lower rate class has sent 3000 packets vs 1000 packets from the high rate one. Don't know what to think... I've attached simplified ad-hoc scripts that reproduce the scenarios: tc_at_200 (full tc/iptables commands to recreate the X200 scenario) tc_at_230 (full tc/iptables commands to recreate the X200 scenario) I haven't tested them, but they seem to be all right (except for the question above). I don't know if it will help at all, but could you post tc statistics for both 200 and 230 cases? You can get the statistics using 'tc -s -d qdisc/class show dev $iface' or similar command. Also, did you check wether HTB is complaining about anything in dmesg when setting up the 230 class tree? no complaints Which kernel version and iproute/tc version are you running? Just in case you're still suffering from old HTB bugs... My test bed at this moment is a gentoo-kernel-2.6.14 in a x86 gentoo, in the server side(iproute2-2.6.11.20050310-r1), and a user-mode-linux-skas3-2.6.14. in the client side, with vde_switch daemon listening in a tuntap device. I suppose that htb is device independet, i hope it does not matter. I have production enviroments waiting for my results (a couple of small local ISPs, an a similar WISP), but the problem is that im coding this far from home, and beside the servers, i have no access to any of the clients to force the rates. If you think this enviroment is somewath buggy plz tell. Txs for your response! -- Luciano tc_at_230_no_onlychild Description: application/shellscript class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 4376664 ctokens: 61083 class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 486295 ctokens: 61083 class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 393216 ctokens: 55296 class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 4521301 bytes 3095 pkt (dropped 0, overlimits 0 requeues 0) rate 173552bit 14pps backlog 0b 0p requeues 0 lended: 467 borrowed: 2628 giants: 0 tokens: -2193687 ctokens: 8085 class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0 Sent 1741028 bytes 1168 pkt (dropped 0, overlimits 0 requeues 0) rate 48040bit 4pps backlog 0b 0p requeues 0 lended: 1168 borrowed: 0 giants: 0 tokens:
Re: [LARTC] HTB, strange capacity distribution
On Tue, Feb 21, 2006 at 02:21:36PM +0100, Boris Gereg wrote: thanks Andreas, I reconfigured HTB to get your suggested hierarhy: One thing I forgot in my graph: Make sure that the rates always add up, i.e. the sum of the child class rates should equal the parent class rate. It's unlikely to be the cause of your problem, but it's important to get this right nevertheless. Any other things to test, please? Just to see wether we are going into the right direction at all, could you run the following experiment: - Lower the rate and ceil of class 1:2 to 8096kbit. - Lower the rate and ceil of class 1:2000 to 7072kbit. - Lower the rate and ceil of class 1:3000 to 1024kbit. - For class 1:3010, set rate to 64kbit, ceil to 256kbit. - For class 1:3020, set rate to 128kbit, ceil to 768kbit. - For class 1:3040, set rate to 704kbit, ceil to 1024kbit. - For class 1:5040, set rate to 128kbit, ceil to 1024kbit. (You can adjust the rates for these classes as you like, just make sure that the sum is 1024kbit) If in this setup the shaping works as expected - WWW should get 704kbit at all times, P2P only slightly more than 128kbit while WWW downloads are active - then the limiting and distribution of HTB most likely works, and it's just too high rates or r2q/quantum that make it go bad. In this case, you'd have to measure realistic throughput rates of your network (even a 100mbit LAN may not be able to guarantee 10kbit at all times) and of your internet connection (may not be able to serve 2048kbit at all times). For downstream shaping to work, you have to be the bottleneck. If you get the same problem in this setup (P2P taking all the bandwidth away from WWW), then the problem is most likely something different, and we have to look at it from a different angle. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Thu, Feb 23, 2006 at 05:00:12AM +0100, Boris Gereg wrote: I did what you suggested and the results are as expected! You can see this picture to verify: http://elusion.sk/visual_inet_7.png At 4:25 I started HTTP download. P2P class immediately droped down to it's RATE, WWW class got it's RATE. At 4:33 I stopped HTTP download, P2P class got rest of capacity. Alright. I suggest you do some measuring, to find out your real rates, and set HTB rates to be slightly lower so that you are the bottleneck. Most likely you'll have to experiment a little until you find the best setting for your setup. Please, are there some hints for setting r2q or quantum parameters? Actually, I specify the quantum directly, with 'quantum $MTU' for every class. I don't know wether that's a good thing or a bad thing, but it worked very well for me, and seems to work well for others... at least nobody reported a problem to me so far that could be traced to be caused by this quantum setting. It should not be smaller than your MTU, and not too big. With a huge difference in rates (100Mbit vs 64kbit) there is no r2q that will fit all classes. So there is no other way as to set quantum directly at least for some classes (and I set it for all...). Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
Hello, thanks Andreas, I reconfigured HTB to get your suggested hierarhy: AK 1: HTB Qdisc AK | AK \--- 1:2 HTB root class (10Kbit:10kbit) AK | AK \--- 1:2000 HTB leaf class (5Kbit:10Kbit) #local AK | AK \--- 1:3000 HTB parent class (2048Kbit:2048Kbit) AK | AK \--- 1:3010 HTB leaf class (64000bit:256000bit) #ctrl AK \--- 1:3020 HTB leaf class (128000bit:768000bit) #other AK \--- 1:3030 HTB leaf class (512000bit:2048Kbit) #www AK \--- 1:5040 HTB leaf class (386000bit:386000bit) #p2p tc -d class show dev eth0 class htb 1:2 root rate 10Kbit ceil 10Kbit burst 51587b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 7 # local: class htb 1:2000 parent 1:2 leaf 2000: prio 0 quantum 20 rate 5Kbit ceil 10Kbit burst 26593b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 0 # root for internet trafic class htb 1:3000 parent 1:2 rate 2048Kbit ceil 2048Kbit burst 2623b/8 mpu 0b overhead 0b cburst 2623b/8 mpu 0b overhead 0b level 6 # ctrl class class htb 1:3010 parent 1:3000 leaf 3010: prio 1 quantum 1000 rate 64000bit ceil 256000bit burst 1631b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b level 0 # other class class htb 1:3020 parent 1:3000 leaf 3020: prio 2 quantum 1600 rate 128000bit ceil 768000bit burst 1663b/8 mpu 0b overhead 0b cburst 1983b/8 mpu 0b overhead 0b level 0 # www class class htb 1:3030 parent 1:3000 leaf 3030: prio 3 quantum 12800 rate 1024Kbit ceil 2048Kbit burst 2111b/8 mpu 0b overhead 0b cburst 2623b/8 mpu 0b overhead 0b level 0 # p2p class class htb 1:5040 parent 1:3000 leaf 5040: prio 4 quantum 1600 rate 128000bit ceil 256000bit burst 1663b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b level 0 Sorry to say, results are not as expected. I made new measurements, please see following picture (based on HTB config above): http://elusion.sk/visual_inet_6.png Point A - until now, p2 clas had CEIL 386 kbit. Now, I reset p2p class CEIL to 2048 kbit. As you can see, p2p rised as expected Point B - www class RATE-CEIL is 512-2048 kbit, p2p class RATE-CEIL is 128-2048 kbit. PROBLEM: why did not www get more capacity? Point C - www class RATE-CEIL is 1536-2048 kbit, p2p class RATE-CEIL is 128-2048 kbit. PROBLEM: RATE of www is 1536, but class did not get this capacity; p2p should fall to it's RATE 256 kbit Point D - www class RATE-CEIL is 1024-2048 kbit, p2p class RATE-CEIL is 128-2048 kbit - no change Point E - www class RATE-CEIL is 1024-2048 kbit, p2p class RATE-CEIL is 128-256 kbit - as expected: p2p is bounded to 256 kbit limit, so the rest of the capacity was used by www class I have expected that in points B, C and D, p2p class falls down to it's specified rate and www gets most of the capacity. But this is not happening - p2p will not fall down Any other things to test, please? Best regards, B. Gereg mailto:[EMAIL PROTECTED] -Originalna sprava- Od: Andreas Klauer [mailto:[EMAIL PROTECTED] Poslane: Tuesday, February 21, 2006, 8:52:49 AM Komu: [EMAIL PROTECTED] Predmet: [LARTC] HTB, strange capacity distribution AK On Tue, Feb 21, 2006 at 12:49:59AM +0100, Boris Gereg wrote: (first of all, please, how to reply to some article in LARTC via mail to post it into right thread?) AK Using 'reply all', or 'reply list' if your mail software offers it. AK If all else fails, just hit 'reply' and add the mailing list to CC. So, I am definitely shaping outgoing traffic (upstream) AK Yes, outgoing traffic from router to your network, which actually AK contains the downstream traffic from the internet. Right? tc -d class show dev eth0 class htb 1:2 root rate 10Kbit ceil 10Kbit burst 51587b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 7 class htb 1:2000 parent 1:2 leaf 2000: prio 0 quantum 20 rate 5Kbit ceil 10Kbit burst 26593b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 0 class htb 1:3010 parent 1:2 leaf 3010: prio 1 quantum 1000 rate 64000bit ceil 256000bit burst 1631b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b level 0 class htb 1:3020 parent 1:2 leaf 3020: prio 2 quantum 1600 rate 128000bit ceil 768000bit burst 1663b/8 mpu 0b overhead 0b cburst 1983b/8 mpu 0b overhead 0b level 0 class htb 1:3030 parent 1:2 leaf 3030: prio 3 quantum 6400 rate 512000bit ceil 2048Kbit burst 1855b/8 mpu 0b overhead 0b cburst 2623b/8 mpu 0b overhead 0b level 0 class htb 1:5040 parent 1:2 leaf 5040: prio 4 quantum 4825 rate 386000bit ceil 386000bit burst 1792b/8 mpu 0b overhead 0b cburst 1792b/8 mpu 0b overhead 0b level 0 AK It's as I suspected, your current HTB tree looks like this: AK 1: HTB Qdisc AK | AK \--- 1:2 HTB root class (10Kbit:10kbit) AK | AK \--- 1:2000 HTB leaf class (5Kbit:10Kbit) AK \--- 1:3010 HTB leaf class (64000bit:256000bit) AK \--- 1:3020 HTB leaf class (128000bit:768000bit) AK \---
Re: [LARTC] HTB, strange capacity distribution
On Mon, Feb 20, 2006 at 10:59:33PM +0100, Boris Gereg wrote: I made a screen to help explain my problem. Please, see this picture: http://elusion.sk/visual_inet_hory.png Nice graph. I assume this is on downstream, and you rely on HTB to drop packets for you. You may have read this in the archives already - it's much harder to shape downstream than upstream, because you can't really influence what the other side is sending you. So no matter what you do it's probably hard to get near-optimal results. This is my HTB config (using latest htb-init script): I must admit I'm not familiar with htb-init. What are the parent-child relationships here? I'm missing the internet parent class that groups all the other traffics (except local) together. Does htb-init generate that on it's own somehow? If not, chances are your HTB tree is just exceeding your line capacity in general, as all classes are allowed to borrow without limit, rendering the prio setting uneffective, leading to random results. Could you post the output of 'tc -d qdisc/class show dev $DEVICE'? Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Tue, Feb 21, 2006 at 12:49:59AM +0100, Boris Gereg wrote: (first of all, please, how to reply to some article in LARTC via mail to post it into right thread?) Using 'reply all', or 'reply list' if your mail software offers it. If all else fails, just hit 'reply' and add the mailing list to CC. So, I am definitely shaping outgoing traffic (upstream) Yes, outgoing traffic from router to your network, which actually contains the downstream traffic from the internet. Right? tc -d class show dev eth0 class htb 1:2 root rate 10Kbit ceil 10Kbit burst 51587b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 7 class htb 1:2000 parent 1:2 leaf 2000: prio 0 quantum 20 rate 5Kbit ceil 10Kbit burst 26593b/8 mpu 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 0 class htb 1:3010 parent 1:2 leaf 3010: prio 1 quantum 1000 rate 64000bit ceil 256000bit burst 1631b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b level 0 class htb 1:3020 parent 1:2 leaf 3020: prio 2 quantum 1600 rate 128000bit ceil 768000bit burst 1663b/8 mpu 0b overhead 0b cburst 1983b/8 mpu 0b overhead 0b level 0 class htb 1:3030 parent 1:2 leaf 3030: prio 3 quantum 6400 rate 512000bit ceil 2048Kbit burst 1855b/8 mpu 0b overhead 0b cburst 2623b/8 mpu 0b overhead 0b level 0 class htb 1:5040 parent 1:2 leaf 5040: prio 4 quantum 4825 rate 386000bit ceil 386000bit burst 1792b/8 mpu 0b overhead 0b cburst 1792b/8 mpu 0b overhead 0b level 0 It's as I suspected, your current HTB tree looks like this: 1: HTB Qdisc | \--- 1:2 HTB root class (10Kbit:10kbit) | \--- 1:2000 HTB leaf class (5Kbit:10Kbit) \--- 1:3010 HTB leaf class (64000bit:256000bit) \--- 1:3020 HTB leaf class (128000bit:768000bit) \--- 1:3030 HTB leaf class (512000bit:2048Kbit) \--- 1:5040 HTB leaf class (386000bit:386000bit) HTB classes borrow from their parent; in this setup, the parent class offers a whopping 10Kbit for that purpose. Unless the 1:2000 class has got a very high priority and is maxing out the line all the time, there is no limit to borrowing at all, because the other classes will never reach the 10Kbit from their parent. So the classes above are actually not limited by their rate, but by their ceil; the only class that will respect its rate in this setup is 1:5040, because it's got the same rate and ceil. Assuming that 1:5040 was your P2P class, if you set the ceil of this class to 2048Kbit, it will (try to) use 2048Kbit at all times, because the parent (thinks it) is able to offer it. You need a class that knows of your total internet bandwidth somewhere. Assuming that it is 2048Kbit, your tree should maybe look more like this: 1: HTB Qdisc | \--- 1:2 HTB root class (10Kbit:10kbit) | \--- 1:2000 HTB leaf class (5Kbit:10Kbit) | \--- 1:3000 HTB parent class (2048Kbit:2048Kbit) | \--- 1:3010 HTB leaf class (64000bit:256000bit) \--- 1:3020 HTB leaf class (128000bit:768000bit) \--- 1:3030 HTB leaf class (512000bit:2048Kbit) \--- 1:5040 HTB leaf class (386000bit:386000bit) In this setup, the 2048Kbit class is the limiting factor for the leaf classes, except for the 1:2000 class, which should be used for local LAN traffic only. HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb root don't reach ceil rate?
Am Freitag, 10. Februar 2006 14:45 schrieb Markus Schulz: tc -s -d class show dev ppp0 class htb 1:1 root rate 576000bit ceil 576000bit burst 30Kb/8 mpu 0b overhead 0b cburst 1739b/8 mpu 0b overhead 14b level 7 Sent 1485575598 bytes 3140554 pkts (dropped 0, overlimits 0) rate 480008bit 115pps lended: 1904616 borrowed: 0 giants: 0 tokens: 385702 ctokens: -26458 ok, i've understand now. Differenz comes from gross versus net data rates due to overhead of ATM-SAR and pppoe-overhead. All statistic values are netto values. -- Markus Schulz ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb prio ...
They would do different things, the prio only has to do with all other classes that share the same parent. The prio isn't preserved as it goes up/down the tree. Depending on what you want to accomplish, you really should probably be doing it on all levels, not one or the other. - JodyOn 2/5/06, Vaidas [EMAIL PROTECTED] wrote: Hey, I have such a script: tc qdisc add dev $DEV root handle 1:0 htb default 21 r2q 2 tc class add dev $DEV parent 1:0 classid 1:11 htb rate 100mbit tc class add dev $DEV parent 1:11 classid 1:21 htb rate 512kbit ceil 512kbit tc class add dev $DEV parent 1:11 classid 1:23 htb rate 1024kbit ceil 1024kbit tc class add dev $DEV parent 1:11 classid 1:25 htb rate 3072kbit ceil 3072kbit tc class add dev $DEV parent 1:21 classid 1:102 htb rate 64kbit ceil 128kbit prio 2 tc qdisc add dev $DEV parent 1:102 handle 102:0 sfq perturb 10 quantum 1600 tc filter add dev $DEV parent 1:0 prio 2 protocol ip handle 102 fw flowid 1:102 iptables -t mangle -A USERS_DL -m set ! --set local src -d 102.168.0.2 -j MARK --set-mark 102 tc class add dev $DEV parent 1:23 classid 1:103 htb rate 128kbit ceil 256kbit prio 1 tc qdisc add dev $DEV parent 1:103 handle 103:0 sfq perturb 10 quantum 1600 tc filter add dev $DEV parent 1:0 prio 1 protocol ip handle 103 fw flowid 1:103 iptables -t mangle -A USERS_DL -m set ! --set local src -d 102.168.0.3 -j MARK --set-mark 103 and so on.. The question is, can I put prio on tc class add dev $DEV parent 1:11 classid 1:21 htb rate 512kbit ceil 512kbit prio 2 ? tc class add dev $DEV parent 1:11 classid 1:23 htb rate 1024kbit ceil 1024kbit prio 1 ? tc class add dev $DEV parent 1:11 classid 1:25 htb rate 3072kbit ceil 3072kbit prio 0 ? instead of tc class add dev $DEV parent 1:21 classid 1:102 htb rate 64kbit ceil 128kbit prio 2 tc class add dev $DEV parent 1:23 classid 1:103 htb rate 128kbit ceil 256kbit prio 1 __ Vaidas VDXnet sistemų administratorius ___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
Re: [LARTC] HTB prio question
On Mon, Jan 30, 2006 at 02:35:36PM +0200, Anton Glinkov wrote: Is the prio specification in the htb class global or is it on a per class basis? A simple example: class 1:10 parent 1: class 1:130 parent 1:10 prio 3 class 1:170 parent 1:10 prio 7 class 1:171 parent 1:170 prio 1 class 1:172 parent 1:170 prio 2 Which class will get excessive bandwidth first? 130 or 171/172? I haven't tested it, but from my understanding, it should be 1:130. Children classes should not be able to borrow from the outside by themselves - they can only tell their parent to borrow for them, so it's 1:130 (prio 3) vs 1:170 (prio 7) here. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - not borrowing, not exceeding rate
Dnia wtorek, 10 stycznia 2006 00:57, Andy Furniss napisał(a): # main rate limitation for whole connection (802.11a radio link) tc class add dev eth2.24 parent 1: classid 1:1 htb rate 15000kbit ceil 15000kbit burst 10kbit Burst too small - it's realated to HZ and also should be at least as big as child bursts. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#burst That was the problem. Now I don't specify burst, so tc calculates it by itself and now all is working as I wanted. Thank you. -- | 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] HTB traffic shaping odd effects
Oliver Hookins wrote: burst 19k will limit you unless your HZ=1000 Our HZ is 512. I don't know if it makes any difference, but I would have chosen 500 so that it was 2ms. The default now is 250 and with 19k burst that fits the speed you get really well - with 512 it would be around 70meg. I would get rid of the 2 burst settings you use. Not sure can you show output of tc -s -d class ls dev eth0 while it's running at 2x speed. class htb 1:1 root rate 100Mbit ceil 100Mbit burst 24Kb/8 mpu 0b cburst 132644b/8 mpu 0b level 7 Sent 741267447736 bytes 735629628 pkts (dropped 0, overlimits 0) rate 4316188bps 22688pps lended: 489885589 borrowed: 0 giants: 0 tokens: -78 ctokens: 6677 class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 20 rate 50Mbit ceil 80Mbit burst 19Kb/8 mpu 0b cburst 106440b/8 mpu 0b level 0 Sent 740240463634 bytes 734522966 pkts (dropped 429910165, overlimits 0) rate 4233957bps 22358pps lended: 244988819 borrowed: 489885528 giants: 0 tokens: -293 ctokens: 6636 class htb 1:20 parent 1:1 leaf 20: prio 0 quantum 13107 rate 1Mbit ceil 1Mbit burst 2Kb/8 mpu 0b cburst 2Kb/8 mpu 0b level 0 Sent 755354078 bytes 755048 pkts (dropped 0, overlimits 0) rate 84198bps 321pps backlog 4p lended: 755220 borrowed: 61 giants: 0 tokens: -21517 ctokens: -21517 84198 bps - tc means bytes/sec by this, so it's 1mbit. Htb uses really long (100 sec) average for its rate so it probably is giving 1mbit. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - not borrowing, not exceeding rate
Kajetan Staszkiewicz wrote: Here is current setup: tc qdisc del root dev eth2.24 2/dev/null tc qdisc add root dev eth2.24 handle 1: htb default 1 # main rate limitation for whole connection (802.11a radio link) tc class add dev eth2.24 parent 1: classid 1:1 htb rate 15000kbit ceil 15000kbit burst 10kbit Burst too small - it's realated to HZ and also should be at least as big as child bursts. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#burst # class for internet connections - this one can use nearly whole link tc class add dev eth2.24 parent 1:1 classid 1:6667 htb rate 12000kbit ceil 13500kbit burst 100kbit # class for in-network p2p connections - this one has lower guaranteed rate tc class add dev eth2.24 parent 1:1 classid 1: htb rate 3000kbit ceil 14000kbit burst 10kbit tc qdisc add dev eth2.24 parent 1: handle : sfq perturb 5 quantum 1500b I would condider using htb prio here and sfq peturb causes packet reordering so 5 is a bit low. SFQ is really best for bulk traffic. # now in-network p2p traffic. if it comes from other LANs then direct it to # 1: tc filter add dev eth2.24 protocol ip parent 1:0 u32 match ip src 192.168.5.0/24 flowid 1: tc filter add dev eth2.24 protocol ip parent 1:0 u32 match ip src 192.168.4.0/24 flowid 1: I think these should be before the other filters. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB traffic shaping odd effects
Denis Ovsienko wrote: tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit burst 24k Does the following help? tc qdisc add dev eth0 root handle 1: htb default 1 tc class add dev eth0 parent 1: classid 1:1 htb rate 81mbit burst 24k That seems a bit backward, limiting the total available bandwidth to enforce child class limits. Or is that how htb works, that the sum of the child classes must add up to no less than the parent class? In any case we have 100mbit available so I don't want to set it any lower than that, if possible. -- Regards, Oliver Hookins ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB traffic shaping odd effects
Oliver Hookins wrote: Hi, I'm trying to perform some (what I consider) basic traffic shaping on our network utilising HTB. I have mostly reused the example on the lartc.org site: tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit burst 24k tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50mbit ceil 80mbit burst 19k burst 19k will limit you unless your HZ=1000 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1mbit ceil 1mbit tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src X.X.X.X flowid 1:20 So we have a total of 100mbit to be used, the default class 1:10 gets 50mbit and a ceiling of 80mbit whereas my test host X.X.X.X gets only 1mbit in any situation. Some rate limiting is definitely happening, but I am finding the outbound traffic is limited to 2mbit instead of 1mbit. If I change the rate (to say 10mbit) the outbound traffic gets up to again twice the rate (in this case 20mbit). Not sure can you show output of tc -s -d class ls dev eth0 while it's running at 2x speed. Any thoughts? I have had a look at the tc statistics but it doesn't appear as I would expect it to. Class 1:10 shows a lot of dropped packets but it is only averaging around 30mbit constantly. On the other hand class 1:20 doesn't show any dropped packets. Similarly there are no packets marked as overlimit for any class. Apart from the 30mbit that would be normal. Andy. I occasionally see the tokens for 1:20 go negative... everything is quite strange. Any help would be appreciated. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
