[LARTC] Divide bandwidth between 4 groups of ip with the same rate

[LARTC] Divide bandwidth between 4 groups of ip with the same rate

[CVEREDA]

[-- Attachment #1.1: Type: text/plain, Size: 3774 bytes --]

Hello, I have begun to use the tc scripts since 2 weeks ago, so I am beginner. I am trying to divide my bandwidth in 4 independent ones. Each of these sub-bandwidths is assigned to 4 different groups of ip. Bandwidth sharing is allowed. I put a Linux with two Ethernet card between the router and the LAN. Eth1 is the card connected to the router and eth0 is the one connected to the LAN. My ISP provides 3 mbit upload and 300 kbit download. I define 4 classes for download with a rate of 300kbit and a ceil of 2700 kbit (1:10 to 1:40, parent 1:12). In the same way, I define 4 classes for upload with a rate of 72kbit and a ceil of 200kbit (2:10 to 2:40, parent 2.12). Everything looks work fine, nevertheless when traffic through one of these classes are near to its ceil (200kbit), the http traffic through the rest of the classes becomes slow, and I do not understand whit the free 56 kbit is not used by these traffic. Whatever, htb should decrease the rate of the abusive class, should not?

Thank you in advance for your teaching.

The script that I am using is:

#Shaping in eth0 for download traffic
tc qdisc add dev eth0 root handle 1: htb default 50
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2700kbit ceil 2700kbit prio 7
tc class add dev eth0 parent 1:12 classid 1:10 htb rate 300kbit ceil 2700kbit prio 7
tc class add dev eth0 parent 1:12 classid 1:20 htb rate 300kbit ceil 2700kbit prio 7
tc class add dev eth0 parent 1:12 classid 1:30 htb rate 300kbit ceil 2700kbit prio 7
tc class add dev eth0 parent 1:12 classid 1:40 htb rate 300kbit ceil 2700kbit prio 7
tc class add dev eth0 parent 1:12 classid 1:50 htb rate 30kbit ceil 270kbit prio 7
tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.0/26 flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.64/26 flowid 1:20
tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.128/26 flowid 1:30
tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.192/26 flowid 1:40

#Shaping in eth1 for upload traffic marking packets at mangle
tc qdisc add dev eth1 root handle 2: htb default 50 
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 256kbit
tc class add dev eth1 parent 2:12 classid 2:10 htb rate 72kbit ceil 200kbit prio 7
tc class add dev eth1 parent 2:12 classid 2:20 htb rate 72kbit ceil 200kbit prio 7
tc class add dev eth1 parent 2:12 classid 2:30 htb rate 72kbit ceil 200kbit prio 7
tc class add dev eth1 parent 2:12 classid 2:40 htb rate 72kbit ceil 200kbit prio 7
tc class add dev eth1 parent 2:12 classid 2:50 htb rate 10kbit prio 7

tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 10
tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 10
tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 10
tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 10

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 prio 16 fw flowid 2:10
tc filter add dev eth1 protocol ip parent 2:0 handle 2 prio 16 fw flowid 2:20
tc filter add dev eth1 protocol ip parent 2:0 handle 3 prio 16 fw flowid 2:30
tc filter add dev eth1 protocol ip parent 2:0 handle 4 prio 16 fw flowid 2:40


		 TERRA 

-->


[-- Attachment #1.2: Type: text/html, Size: 3999 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Divide bandwidth between 4 groups of ip with the same rate

[Andy Furniss]

CVEREDA@telefonica.net wrote:

Your bandwidth is likely to have overheads so you can't go too close to 
ISP quoted numbers. There are ways to make it more accurate for dsl, but 
you'll need to patch kernel/tc.

When shaping ingress traffic you have to sacrifice bandwidth or you will 
not build up a queue quick enough to have much effect. For ingress you 
should also limit the length of the queue so you drop packets.

If you really want to shape the whole eths aswell as the wan then the 
same applies - 100mbit nic is not 100mbit at ip level (in reality qdiscs 
on eth actually count as ip len + 14, but there are still more overheads 
than that).

Using htb default on eth will send your arp to that class unless you 
make filters to send it elsewhere  - this may seriously mess things up 
if you have default as a low bandwidth class with other traffic.

If this is dsl then given how assymetric the line is, a big chunk of 
your egress bandwidth may be eaten by acks - on dsl an ack uses 106 
bytes, but will be seen only as ip len + 14.

The rates on egress add up to 298 which if all full will not be capped 
by the parent setting of 256.

I think you are probably going over rate and getting a queue building up 
  in the modem. To test you could make a high prio class and send pings 
through it, you can then see when you are getting lagged out.

Andy.


> The script that I am using is:
> 
> #Shaping in eth0 for download traffic
> tc qdisc add dev eth0 root handle 1: htb default 50
> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
> tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80mbit ceil 100mbit
> tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2700kbit ceil 2700kbit prio 7
> tc class add dev eth0 parent 1:12 classid 1:10 htb rate 300kbit ceil 2700kbit prio 7
> tc class add dev eth0 parent 1:12 classid 1:20 htb rate 300kbit ceil 2700kbit prio 7
> tc class add dev eth0 parent 1:12 classid 1:30 htb rate 300kbit ceil 2700kbit prio 7
> tc class add dev eth0 parent 1:12 classid 1:40 htb rate 300kbit ceil 2700kbit prio 7
> tc class add dev eth0 parent 1:12 classid 1:50 htb rate 30kbit ceil 270kbit prio 7
> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.0/26 flowid 1:10
> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.64/26 flowid 1:20
> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.128/26 flowid 1:30
> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.192/26 flowid 1:40
> 
> #Shaping in eth1 for upload traffic marking packets at mangle
> tc qdisc add dev eth1 root handle 2: htb default 50 
> 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 256kbit
> tc class add dev eth1 parent 2:12 classid 2:10 htb rate 72kbit ceil 200kbit prio 7
> tc class add dev eth1 parent 2:12 classid 2:20 htb rate 72kbit ceil 200kbit prio 7
> tc class add dev eth1 parent 2:12 classid 2:30 htb rate 72kbit ceil 200kbit prio 7
> tc class add dev eth1 parent 2:12 classid 2:40 htb rate 72kbit ceil 200kbit prio 7
> tc class add dev eth1 parent 2:12 classid 2:50 htb rate 10kbit prio 7
> 
> tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 10
> tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 10
> tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 10
> tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 10
> 
> 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 prio 16 fw flowid 2:10
> tc filter add dev eth1 protocol ip parent 2:0 handle 2 prio 16 fw flowid 2:20
> tc filter add dev eth1 protocol ip parent 2:0 handle 3 prio 16 fw flowid 2:30
> tc filter add dev eth1 protocol ip parent 2:0 handle 4 prio 16 fw flowid 2:40
> 
> 
> 		 TERRA 
> 
> -->
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Divide bandwidth between 4 groups of ip with the same rate

[Carlos Vereda-Alonso]

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.

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.

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).
	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.
	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?.
	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 :)
	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.
	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.

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.

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

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

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



Andy Furniss wrote:
> CVEREDA@telefonica.net wrote:
> 
> Your bandwidth is likely to have overheads so you can't go too close to 
> ISP quoted numbers. There are ways to make it more accurate for dsl, but 
> you'll need to patch kernel/tc.
> 
> When shaping ingress traffic you have to sacrifice bandwidth or you will 
> not build up a queue quick enough to have much effect. For ingress you 
> should also limit the length of the queue so you drop packets.
> 
> If you really want to shape the whole eths aswell as the wan then the 
> same applies - 100mbit nic is not 100mbit at ip level (in reality qdiscs 
> on eth actually count as ip len + 14, but there are still more overheads 
> than that).
> 
> Using htb default on eth will send your arp to that class unless you 
> make filters to send it elsewhere  - this may seriously mess things up 
> if you have default as a low bandwidth class with other traffic.
> 
> If this is dsl then given how assymetric the line is, a big chunk of 
> your egress bandwidth may be eaten by acks - on dsl an ack uses 106 
> bytes, but will be seen only as ip len + 14.
> 
> The rates on egress add up to 298 which if all full will not be capped 
> by the parent setting of 256.
> 
> I think you are probably going over rate and getting a queue building up 
>  in the modem. To test you could make a high prio class and send pings 
> through it, you can then see when you are getting lagged out.
> 
> Andy.
> 
> 
>> The script that I am using is:
>>
>> #Shaping in eth0 for download traffic
>> tc qdisc add dev eth0 root handle 1: htb default 50
>> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
>> tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80mbit ceil 
>> 100mbit
>> tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2700kbit ceil 
>> 2700kbit prio 7
>> tc class add dev eth0 parent 1:12 classid 1:10 htb rate 300kbit ceil 
>> 2700kbit prio 7
>> tc class add dev eth0 parent 1:12 classid 1:20 htb rate 300kbit ceil 
>> 2700kbit prio 7
>> tc class add dev eth0 parent 1:12 classid 1:30 htb rate 300kbit ceil 
>> 2700kbit prio 7
>> tc class add dev eth0 parent 1:12 classid 1:40 htb rate 300kbit ceil 
>> 2700kbit prio 7
>> tc class add dev eth0 parent 1:12 classid 1:50 htb rate 30kbit ceil 
>> 270kbit prio 7
>> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 
>> 192.168.0.0/26 flowid 1:10
>> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 
>> 192.168.0.64/26 flowid 1:20
>> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 
>> 192.168.0.128/26 flowid 1:30
>> tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 
>> 192.168.0.192/26 flowid 1:40
>>
>> #Shaping in eth1 for upload traffic marking packets at mangle
>> tc qdisc add dev eth1 root handle 2: htb default 50 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 256kbit
>> tc class add dev eth1 parent 2:12 classid 2:10 htb rate 72kbit ceil 
>> 200kbit prio 7
>> tc class add dev eth1 parent 2:12 classid 2:20 htb rate 72kbit ceil 
>> 200kbit prio 7
>> tc class add dev eth1 parent 2:12 classid 2:30 htb rate 72kbit ceil 
>> 200kbit prio 7
>> tc class add dev eth1 parent 2:12 classid 2:40 htb rate 72kbit ceil 
>> 200kbit prio 7
>> tc class add dev eth1 parent 2:12 classid 2:50 htb rate 10kbit prio 7
>>
>> tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 10
>> tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 10
>> tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 10
>> tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 10
>>
>> 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 prio 16 fw 
>> flowid 2:10
>> tc filter add dev eth1 protocol ip parent 2:0 handle 2 prio 16 fw 
>> flowid 2:20
>> tc filter add dev eth1 protocol ip parent 2:0 handle 3 prio 16 fw 
>> flowid 2:30
>> tc filter add dev eth1 protocol ip parent 2:0 handle 4 prio 16 fw 
>> flowid 2:40
>>
>>
>>          TERRA
>> -->
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> LARTC mailing list
>> LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 
> 


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Divide bandwidth between 4 groups of ip with the same rate

[Andy Furniss]

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