maillinglistredcap@xxxxxx wrote:
Hi Andy,
Am Montag, 8. Juli 2013, 22:27:03 schrieb Andrew Beverley:
On Sat, 2013-07-06 at 18:23 +0200, maillinglistredcap@xxxxxx wrote:
Hi there,
I'm new to this list and new to traffic control as well. I want to do some
traffic shaping on my home network and over the past few days I've
studied the subject quite a lot. Today I decided to some first
experiments on my network using the HTB queueing discpline which seems to
suit my purposes best. Well the first results were disappointing... most
likely due to my lack of knowledge.
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. But maybe it's more useful if I
give the whole configuration.
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
arp will go here and because you don't specify a child qdisc on 110 it
could hypothetically get stuck in a very long and slow draining queue
which could cause the eth to effectively stop working.
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit cburst 1602b
Fast eth is only 100mbit if you take into account overheads - I can't
remember the number, but this won't shape.
The cburst here is ignored - burst may work but I wouldn't use it as it
may just cause pointless work at 100mbit.
In fact when I shaped for slow wan on eth I didn't bother including lan
traffic - if your lan is not maxed a lot then I would just use default 0
(or not specify default) and only classify wan traffic to htb so lan/arp
isn't shaped at all.
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
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.
As Andrew has said - being too close to 224 without allowing for
overheads will cause failiure. You can allow for the overheads and then
220kbit would be OK. What and how to allow for the overheads depends on
the precice details of your link - eg. dsl and also how you connect eg,
pppoa, pppoe and even within those there are variants that have
different overheads.
I run some
services on the machine (e.g. bittorrent) that tend to clog up my internet
connection. 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).
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
If there is bulk upload traffic in 110 then things will still be slow as
your dns/acks are being mixed in. Putting sfq on will help.
--
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
