Best regards, Igor V. Filakhtov GMail: filakhtov@xxxxxxxxx | Cell: (050) 65-66-280 | Skype: ihor.filakhtov On Tue, Sep 3, 2013 at 12:27 PM, Andy Furniss <adf.lists@xxxxxxxxx> wrote: > 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 > My connection is PPPoE. I have a MTU fix for it. MTU for ethernet card connected to my DSL modem is set to 1492. Also, according to chapter 15 of cookbook, i have this DSL fix: iptables -t filter -A FORWARD -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu > >> 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! > There is no problem, I'm changing rules, so there is no default anymore, instead all auto-DHCP devices will be market to 29! > >> 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. > Yes, I know. But it's rare case when all of the users are online. Common situation is three users online. For the experiment I lower values to 80kbit (x5) + 64 (x1) = 464 and will do new measurements > >> >> 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. > Thanks for pointing me out! I increase my perturb to 100 right now :) > >> >> 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. > My total bandwidth (line stream) is up to 7 mbps. I already lower it to 6mbps, so there is also no problem. > >> 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. > There I'm lowering values too: 920 (x5) + 512 (x1) = 5112 -- 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
