Carlos Vereda-Alonso wrote:
Thank you very munch for your advises. I should admit that I am a
beginner with respect to QoS and stuffs related to network protocols, so
I don't completely understand some of your explanations, doesn't matter.
It can be tricky and in some ways there are not any right answers -
every script may be wrong in some way. My own is now flawed since I
recently got more bandwidth :-)
I have made some modifications to the previous script.
1) I have decide to remove the traffic shape in eth0 (the one connected
to my LAN), because I have seen that the download traffic is not
overhead in the ADSL router that connect the linux box to the ISP. I
have read in Internet that a correct way to shape the download traffic
is using the imq device. So I would have to study how can I use the imq
device and if I should use it. I think that the packets dropping that
you indicated for the ingress traffic would be made in this device.
No, you only need imq if you have download traffic to the same PC you
are shaping on and you are doing NAT and you want to seperate the
traffic from traffic that is to be forwarded to other lan PCs.
ifb is now in kernel and can do the other things that people used to use
imq for.
If you are just dealing with forwarded traffic then it's just as good to
to shape on the LAN facing NIC.
2) The main problem in my LAN is that two of the IP groups that I have
defined (two neighbor in the building) use almost all the upload
bandwidth. They use Bit-torrent and E-donkey with unlimited upload rate
I ask them to limit the upload without success. So I have followed your
advices related to the traffic control in eth1 (the one connected to the
ADSL router).
Limiting bittorrent on a shared connection is not ideal as you don't
know what to set the limit to, in some ways it's true even if you have
the connection all to yourself because on dsl the acks from downloads
eat alot of bandwidth.
2.1) Now the rates on egress add up to 200 which is equal to the parent
rate. I decrease the parent rate in order to avoid the queue in the ADSL
router that you think is building up in the router.
OK - if you are into building your own kernels and want to tweak there
are ways that you can get things perfect. You also need to know the
exact details of your dsl connection. One day it will be in kernel, but
for now you would need to patch.
2.2) I have removed the htb default on eth1, I suppose that the
unclassified packets will go to the parent class, is ok?. Is my arp
going to the parent class?.
Unclassified traffic will go totally unshaped arp is unclassified in
this case - if the nic is just to a router and you are sure that your
marking gets all the IP traffic then that's OK - you don't even really
need the 8/10 mbit class.
tc -s qdisc ls dev eth1
will give direct_packets_stat XXXX these are the unshaped packets.
2.3) Sorry, I don't know how assymetric the dsl line is and I don't
know how I can get this information. I am a beginner :)
I am English but I can't spell - it's asymmetric :-)
You have roughly 300kbit/s up and 3000kbit/s download which is 1:10, 1:1
would be symmetric. Roughly you can download 250 1500 byte packets/sec,
tcp sends an ack packet upstream - mostly for every other packet
received, but it may be for every packet sometimes.
Because dsl nearly always uses atm cells and some sort of ppp a tcp ack
uses 2 cells which is 106 bytes per ack. This means that just
downloading at 3meg will use between 106 and 212kbit of your upstream
bandwidth at atm level.
I have the same problem - I used to share 4/5 way on 288/576, then
288/1156 which wasn't too bad.
Now it's 448/7392 and I still haven't decided on a policy or tested how
much I can abuse tcp by dropping acks :-)
300kbit is not a dsl sync rate so I guess your ISP allows a bit for the
overheads - you should be able to get your router to tell you what your
atm bitrate really is.
2.4) I have changed the r2q value in the parent qdisc from the default
value (10) to 1, because I read in the htb manual that for low rates it
would be better.
It may be slightly better to add quantum 1514 to each line that has a
rate instead (assuming you have 1500 mtu)
2.5) Finally, I have read in http://www.etxea.net/docu/qos/qos.html
(the page is written in Spanish but the script is in English) that a 2
seconds latency is obtained decreasing the queue size of the eth
connected to the router for Outbound Shaping. You can see that I have
added it at the first line of the script that I am using now.
Written by Dan Singletary (8/7/02)
It's a fair, but old example - all scripts have issues and Dan went on
to write a userspace queue so he could allow for the atm overheads - I
used to use it.
It seems the latency problem in our LAN is solved by now, I am going to
testing it for a couple of weeks and if everything is OK I will tell you.
Good - if it works for you it doesn't need fixing. There are lots of
things you can do, but if your not an avid gamer who notices every ms
then there is no point over complicating things.
Please, forgive my lack of knowledge about all these concerns and thank
you again for your help. The new script is below...
---
Carlos Vereda
# set queue size to give latency of about 2 seconds on low-prio packets
ip link set dev eth1 qlen 30
If you didn't have sfq on leafs then this would be OK - but as you do,
you will get the default 128 packet queue length of sfq. You can make
them shorter with the limit parameter. I use 20 on mine - but then I
only send bulk traffic to sfq, so I don't care what gets dropped.
tc qdisc add dev eth1 root handle 2: htb r2q 1
tc class add dev eth1 parent 2: classid 2:1 htb rate 10mbit
tc class add dev eth1 parent 2:1 classid 2:11 htb rate 8mbit ceil 10mbit
tc class add dev eth1 parent 2:1 classid 2:12 htb rate 200kbit
tc class add dev eth1 parent 2:12 classid 2:10 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:20 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:30 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:40 htb rate 50kbit ceil
200kbit prio 2
tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 5
tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 5
tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 5
tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 5
perturb can cause packet reordering - 5 is a bit low.
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.0/26
--set-mark 1
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.64/26
--set-mark 2
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.128/26
--set-mark 3
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.192/26
--set-mark 4
tc filter add dev eth1 protocol ip parent 2:0 handle 1 fw flowid 2:10
tc filter add dev eth1 protocol ip parent 2:0 handle 2 fw flowid 2:20
tc filter add dev eth1 protocol ip parent 2:0 handle 3 fw flowid 2:30
tc filter add dev eth1 protocol ip parent 2:0 handle 4 fw flowid 2:40
In this case it will not matter, but not using prio on filters can cause
problems with order if you ever do anything more complicated.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
