> > You're not sending any traffic into your single leaf class. > > Yes, I'm aware of that. I posted only a part of my configurations to illustrate > the fact, that cburst settings are ignored. Ah okay, I assumed that your statement saying that it didn't work properly before applying the cburst setting meant that it didn't work at all. > My qdisc tree is as follows: > > tc qdisc del dev eth0 root 2>/dev/null > tc qdisc add dev eth0 root handle 1: htb default 110 > tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit cburst 1602b > > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 99780kbit > tc class add dev eth0 parent 1:1 classid 1:11 htb rate 220kbit > > tc class add dev eth0 parent 1:11 classid 1:110 htb rate 180kbit ceil 220kbit > tc class add dev eth0 parent 1:11 classid 1:111 htb rate 40kbit ceil 220kbit With a quick glance, all looks good. > This tree is on a machine in my network that has only one NIC. There is also a > router on my network with a 224 kbit uplink internet connection. I run some > services on the machine (e.g. bittorrent) that tend to clog up my internet > connection. I assume you're only shaping egress traffic from your machine? Are you sure that the problems are not also caused by ingress traffic? > My approach is to direct all local traffic to the class with minor > ID 10. Other traffic should be handled by class 1:11. In this class I have two > subclasses. One for services were responsiveness is crucial ( classid 1:110) > and a class (classid 1:111) that should handle other traffic (e.g. bittorrent). All makes sense. > Here is my iptables configuration: > > iptables -t mangle -N lantraffic > iptables -t mangle -A lantraffic -j CLASSIFY --set-class 1:10 > iptables -t mangle -A lantraffic -j ACCEPT > > iptables -t mangle -N wantraffic > iptables -t mangle -A wantraffic -o eth0 -p tcp -m length --length :64 -j > CLASSIFY --set-class 1:110 > iptables -t mangle -A wantraffic -o eth0 -m owner --uid-owner torrent -j > CLASSIFY --set-class 1:111 > iptables -t mangle -A wantraffic -j ACCEPT > > iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.2.0/24 -j lantraffic > iptables -t mangle -A POSTROUTING -o eth0 ! -d 192.168.2.0/24 -j wantraffic I assume that you're happy that all traffic is being classified correctly, based on your statistics below? > However, these settings don't work as I intended. Most of the time loading > websites is very slow ( I also have privoxy running on the machine, so the > above qdiscs should apply to HTTP/S traffic on my network). It might be worth reducing your overall rate below 220kbit. Whilst you state that the link is 224kbit, if for any reason you get slightly below this then the router will start to shape/buffer the traffic in a manner that you don't want. You need to make sure that *all* shaping/queueing is done within HTB. It would be worth using tc-viewer to see exactly what is happening: http://tccs.sourceforge.net/ > Here are my statistics after about 5 minutes of websurfing with the qdisc > active: [...] > As stated above, websurfing was not very responsive most of the time. I don't > know the exact implications of the burst and cburst parameters but I noticed > that the cburst in class 1:111 is quite large (8800b). The rule of thumb for > cburst seems to be to choose it as close to MTU as possible (1500 in my case). My gut feeling is that the cburst setting will not be causing your problems. I have never played with the setting - it always works at the default for me, and problems I experience are normally due to the sort of issues described above. That said, I read some stuff recently that cburst values do sometimes not work correctly with some MTU settings, but I forget the exact details. Someone else on this list may know (or it might be in the archives). Andy -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
