Igor Filakhtov wrote:
Greetings all,
I started to fight with a QoS a long time ago, and still have no
reliable solution. So I ask you to suggest me anything what I can try
to get things done.
I have a single DSL internet connectivity with a 6 mbit/s downlink and
512 kbit/s uplink. Modem connected to Debian based PC (on iface called
"wan") which is used as a router.
ADSL uses AAL5 ATM which has a lot of fixed and variable overheads.
If you can find out exactly how you connect eg pppoa pppoe ipoa whether
vc mux or llc is being used etc. You can use stab + sync rate as
reported by modem minus a few kbit and do egress perfectly.
If $WAN is eth you can take 14 fron your fixed overheads as tc sees ip
+14 as packet length on eth.
See man tc-stab
Another iface called "lan" connected from Debian router to internal
network via wireless router. I have a NAT setup using IPTables.
There are 5 users in my LAN, every of those have at least two devices
(pc, smartphone). These devices using static DHCP addresses. All
packets from single device owner are marked.
These packets later are shaped using TC.
Desired result is to divide traffic between users in such way:
1. if there is only single user he getting 6m/512k
2. two users getting a 3m/256k each
3. three users getting 2m/170k each
4. four users getting 1.5m/128k each
5. five users getting 1m/100k each
It is difficult scheme, so I decided to give 1m/128k guarantee rate to
each user, and up to 6m/512k ceil.
All works fine, except BitTorrent. If one of users start downloading
via p2p network all available bandwidth it seems occupies all
available bandwidth.
There are rules, what I currently use:
tc qdisc add dev $WAN root handle 1:0 htb default 29
Though sfq will save the day in your case, using default on eth also
catches arp - which should not be treated as low prio!
tc class add dev $WAN parent 1:0 classid 1:1 htb rate 512kbit ceil
512kbit burst 640 cburst 640
tc class add dev $WAN parent 1:1 classid 1:21 htb rate 96kbit ceil
496kbit burst 120 cburst 620
tc class add dev $WAN parent 1:1 classid 1:22 htb rate 96kbit ceil
496kbit burst 120 cburst 620
tc class add dev $WAN parent 1:1 classid 1:23 htb rate 96kbit ceil
496kbit burst 120 cburst 620
tc class add dev $WAN parent 1:1 classid 1:24 htb rate 96kbit ceil
496kbit burst 120 cburst 620
tc class add dev $WAN parent 1:1 classid 1:25 htb rate 96kbit ceil
496kbit burst 120 cburst 620
tc class add dev $WAN parent 1:1 classid 1:29 htb rate 64kbit ceil
496kbit burst 120 cburst 620
Your rates add up to more than the parent - the parent will not cap these.
tc qdisc add dev $WAN parent 1:21 sfq perturb 10
tc qdisc add dev $WAN parent 1:22 sfq perturb 10
tc qdisc add dev $WAN parent 1:23 sfq perturb 10
tc qdisc add dev $WAN parent 1:24 sfq perturb 10
tc qdisc add dev $WAN parent 1:25 sfq perturb 10
tc qdisc add dev $WAN parent 1:29 sfq perturb 10
Historically sfqs hash was not that good, but now it uses jhash perturb
10 is not as important and (unless it changed) it causes reordering, so
I would use 100.
tc filter add dev $WAN protocol ip parent 1:0 prio 1 handle 21 fw flowid 1:21
tc filter add dev $WAN protocol ip parent 1:0 prio 1 handle 22 fw flowid 1:22
tc filter add dev $WAN protocol ip parent 1:0 prio 1 handle 23 fw flowid 1:23
tc filter add dev $WAN protocol ip parent 1:0 prio 1 handle 24 fw flowid 1:24
tc filter add dev $WAN protocol ip parent 1:0 prio 1 handle 25 fw flowid 1:25
tc filter add dev $WAN protocol ip parent 1:0 prio 2 handle 29 fw flowid 1:29
tc qdisc add dev $LAN root handle 1:0 htb default 29 r2q 1
tc class add dev $LAN parent 1:0 classid 1:10 htb rate 54mbit ceil
54mbit burst 70k cburst 70k
tc class add dev $LAN parent 1:10 classid 1:20 htb prio 0 rate 6mbit
ceil 6mbit burst 7680 cburst 7680
Shaping ingress traffic is not the same as egress - you are at the wrong
end of the bottleneck and if your rate is the same as the incoming
bandwidth nothing will happen as you will never build up a queue.
I would try 5mbit - though what works for a single tcp may still get
swamped by a hundred strong seeders on a torrent and thus need lower.
You will have to see what works for you, on slower than 6mbit
connections I used to have to do things like making sure packets were
dropped early and bulk was separate from interactive, but when I had 6 I
didn't really bother as much.
tc class add dev $LAN parent 1:20 classid 1:21 htb rate 1152kbit ceil
4960kbit burst 1440 cburst 6200
tc class add dev $LAN parent 1:20 classid 1:22 htb rate 1152kbit ceil
4960kbit burst 1440 cburst 6200
tc class add dev $LAN parent 1:20 classid 1:23 htb rate 1152kbit ceil
4960kbit burst 1440 cburst 6200
tc class add dev $LAN parent 1:20 classid 1:24 htb rate 1152kbit ceil
4960kbit burst 1440 cburst 6200
tc class add dev $LAN parent 1:20 classid 1:25 htb rate 1152kbit ceil
4960kbit burst 1440 cburst 6200
tc class add dev $LAN parent 1:20 classid 1:29 htb rate 1152kbit ceil
2048kbit burst 1440 cburst 6200
Same as before - rates on leafs are guaranteed so must add up to parent
not exceed it.
--
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
