[LARTC] Why does Emule still fill my line ? What is wrong in this script

[LARTC] Why does Emule still fill my line ? What is wrong in this script

[Joachim Otahal]

The effect I have:
Friend runs emule. It filles the shared (A-DSL) line so everything
else gets slow, that annoys me quite.

I set up the rules to slow down her traffic.
Her IP 192.168.0.20, my IP 192.168.0.45), linux IP 192.168.0.10

However, after a few minutes the line is full of emule again and
everything else is slowed down again. I have to restart the script
to have a temporary (a few seconds) effect of having the traffic
shaped the way I configured.

Another question: does anyone know how I can specify the ACK
packets more precicely than just by their small size ?

And:
I don't really understand the r2q value, although I read as most as I can.
r2q = 1 is the only value which does not give me stupid syslog messages.

Here the script in short:

(Thanks in advance from here on)

#!/bin/sh

# Root
/sbin/tc-new qdisc add dev ppp0 root handle 1:0 htb r2q 1 default 12


## main class
/sbin/tc-new class add dev ppp0 parent 1:0 classid 1:1  htb rate 125kbit ceil 125kbit

## ACK Packages
/sbin/tc-new class add dev ppp0 parent 1:1 classid 1:10 htb rate  25kbit ceil 125kbit prio 0

## VPN/SSH
/sbin/tc-new class add dev ppp0 parent 1:1 classid 1:11 htb rate  100kbit ceil 125kbit prio 1

## normal
/sbin/tc-new class add dev ppp0 parent 1:11 classid 1:12 htb rate  75kbit ceil 125kbit prio 2

## Kazaa
/sbin/tc-new class add dev ppp0 parent 1:12 classid 1:13 htb rate  14kbit ceil  50kbit prio 3

## Emule BRAAAAAKE
/sbin/tc-new class add dev ppp0 parent 1:13 classid 1:14 htb rate  2kbit ceil  4kbit prio 4

# I don't want to bor you with the marking, so just the important here
# ACKs - How can this be done better ?
iptables -A POSTROUTING -t mangle -o ppp0 -p tcp -m length --length :64 -j MARK --set-mark 10

<big cut here>

# Girlfriend
iptables -A POSTROUTING -t mangle -o ppp0 -p tcp --source 192.168.0.20 -j MARK --set-mark 14
iptables -A POSTROUTING -t mangle -o ppp0 -p udp --source 192.168.0.20 -j MARK --set-mark 14
iptables -A POSTROUTING -t mangle -o ppp0 -p tcp --destination 192.168.0.20 -j MARK --set-mark 14
iptables -A POSTROUTING -t mangle -o ppp0 -p udp --destination 192.168.0.20 -j MARK --set-mark 14

<cut again>

# Sorting the marked packets into the according
/sbin/tc-new filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
/sbin/tc-new filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 11 fw flowid 1:11
# defalt class 1:12 is not specified additionally
/sbin/tc-new filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 13 fw flowid 1:13
/sbin/tc-new filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 14 fw flowid 1:14



Still here ? Thx !

Joachim Otahal


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Why does Emule still fill my line?

[Martin A. Brown]

Hey there Joachim!

 : Friend runs emule. It filles the shared (A-DSL) line so everything else
 : gets slow, that annoys me quite.

It occurs to me that there are two ways to solve this problem.

  - Put the download shaping on your internal interface (eth0?), while
    leaving the upload shaping on your ppp0 interface.
  - Drop all of your friend's traffic!  ;)

Seriously, though, the problem is your choice of interface for shaping.

 : However, after a few minutes the line is full of emule again ...

A line full of emule?  Maybe you should call animal control!  Next thing
you know you'll have zebras, monkeys, and giraffes on your ADSL line.
Won't Deutsche Telekom have something to say about that!

 : Another question: does anyone know how I can specify the ACK packets
 : more precicely than just by their small size ?

 - Use tcng. [1]  (I can't seem to post without plugging tcng.  It's the
   best way to write traffic control configs!)
 - Use the ACK hint from the LARTC cookbook. [2]  It's also in the
   wondershaper. [3]

 : I don't really understand the r2q value, although I read as most as I
 : can. r2q = 1 is the only value which does not give me stupid syslog
 : messages.

r2q is simply a divisor to help HTB calculate the optimal quantum.  If you
are working with larger rates, the default r2q of 10 should suffice, but
if you are working with smaller rates, you may need to drop r2q so that
HTB calculates a reasonable quantum for you.  (Alternatively, you can
specify quantum directly...)  I assume that the packets in this example
are about 1500 bytes in size; they are conventional IP packets on
an Ethernet.

    rate kbit (bps)       r2q     quantum (bytes)
   -----------------     -----   ----------------           ^
T1   1544 (193000)         10      19300   (12 packets)     | r2q could
     1024 (128000)         10      12800    (8 packets)     | be larger***
      512  (64000)         10       6400    (4 packets)     |
      256  (32000)         10       3200    (2 packets)   r2q OK
ISDN  128  (16000)         10       1600*   (1 packet)    r2q OK
       64   (8000)         10        800**                  |
       32   (4000)         10        400**                  | r2q should
slow   16   (2000)         10        200**                  | be smaller
                                                            V
   * Devik mentions this calculation in the HTB userguide as the example
     for calculating quantum. [4]  So, if you are shaping at rates below
     128kbit, you should consider dropping your r2q or specifying quantum.
  ** These quantum parameters as calculated by HTB are smaller than the
     MTU, therefore HTB will gripe to logging about this.
 *** r2q could be larger, but does not need to be larger.

Again, r2q is a hint to HTB for calculation of quantum, therefore it is
unnecessary to alter r2q (or quantum) unless quantum will be below the
MTU.

For maximum granularity of sharing (borrowing from parents), a smaller
quantum would be needed.  If shaping at higher rates, ease the
computational requirements by selecting a higher r2q, allowing classes to
borrow larger (quantum) numbers of tokens/ctokens per attempt.

See also Stef's definition of r2q and quantum and an example of these in a
practical situation. [5]

[ script snipped ]

Good luck, Joachim!

-Martin

 [1]  http://linux-ip.net/gl/tcng/node39.html
      see tcc/fields4.tc, use "tcp_ACK"
 [2]  http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
 [3]  http://lartc.org/wondershaper/
 [4]  http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#sharing
      (see the chapter on quantum and r2q)
 [5]  http://www.docum.org/stef.coene/qos/faq/cache/31.html

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/