Joachim Otahal
2003-Sep-18 21:39 UTC
Why does Emule still fill my line ? What is wrong in this script ?
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/
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/