[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] Traffic shaping
From: |
Goswin Brederlow |
Subject: |
Re: [Mldonkey-users] Traffic shaping |
Date: |
22 Jan 2003 03:26:17 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence) |
Martin Kuhlmann <address@hidden> writes:
> Hi,
>
> I'm running mldonkey 2.02-0 on my server, which is also my default
> gateway for two other systems and provides the access to the
> internet through german T-DSL.
>
> Since mldonkey is set to 10 kb upload and thus uses around 14 or 15
> with tendency to use all while i'm trying to do anything other i set
> up traffic shaping.
>
> So long it doesn't do what it should. Sure, i can set mldonkey to
> use only 3kb upload, 8kb or all of the 128 kbit if it's not needed
> anywhere else... but thats effecting not only the upload to other
> clients.
>
> OK. I shape the outgoing to 120 kbit max. I wanted to put mldonkey
> in a class with lowest priority to let him work only when I don't
> need the bandwidth. That way it would be possible to let him upload
> as much as he can, not the 10kb max most people use.
>
> But the minute I start the traffic shaping, my downloadrates goes
> down from >= 10kb to less than 1kb. What i think might be happen is
> this: Due to too much traffic packets will be dropped. We only know
> that this packets are from mldonkey. It could be mldonkey talking
> with other clients to upload or download something, mldonkey talking
> to a server or simply uploading data to others.
I use the following:
1. QoS scheduling
root --- HTB 128 KBit limit which dsl has here
|
+-- 126 - 128 KBit normal traffic
+-- 1 - 64 KBit SYN/ACK/FIN/RST mldonkey connects
+-- 1 - 64 KBit mldonkey data
I filter out mldonkey traffic by UID (i have an mldonkey user) and
tcp-flags and mark them. The mark is then used for sorting into the
traffic shaping queues.
======================================================================
#! /bin/sh
set -evx
logger "firewall: initializing for $IFNAME (local IP $IPLOCAL, DNS servers
$DNSSERVERS)"
# --- shaping ----------------------------------------------------------
tc qdisc del dev $IFNAME root || true
tc qdisc add dev $IFNAME root handle 1: htb default 10
tc class add dev $IFNAME parent 1: classid 1:1 htb rate 128kbit burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:10 htb rate 126kbit ceil 128kbit
burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:20 htb rate 1kbit ceil 64kbit
burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:30 htb rate 1kbit ceil 64kbit
burst 2k
tc qdisc add dev $IFNAME parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $IFNAME parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $IFNAME parent 1:30 handle 30: sfq perturb 10
tc filter add dev $IFNAME parent 1:0 protocol ip prio 1 handle 4 fw classid 1:20
tc filter add dev $IFNAME parent 1:0 protocol ip prio 1 handle 5 fw classid 1:30
## mark mldonkey for shaping
iptables -t mangle -A OUTPUT -m owner --uid-owner 1003 -j MARK --set-mark 4
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,ACK,FIN,RST NONE -m owner
--uid-owner 1003 -j MARK --set-mark 5
======================================================================
Further I have mldonkey usually limited to 4-6 KB/s upload, which
gives about 8 KB/s up traffic.
> So, the solution is to use some sort of pattern to let the traffic
> shaper know what type this packet is. The traffic shaper could
> classify the mldonkey-packets more exactly and drop only packets we
> can drop. Thats for example the upload (only the data, not the
> chatting) to other clients.
>
> One way to implement this is to use source and destination port.
> That i tried already, but it failed. The
> client-2-client-communication consists of:
>
> - To upload something to someone else this client contacts us first
> on our open port (tcp 4662). We send him datapackets which source
> port is our donkeyport as an answer to his port, so the
> destination port will be somewhat higher and random.
> So I thought we can catch the upload this way.
>
> - To download something from someone else we contact him on his
> open port (tcp 4662). So here it is his open port (tcp 4662) and
> we get his replys on one of our higher ports.
>
> I tried this but it failed. So, what have i missed? How do I get it
> to work?
The solution would be for mldonkey to realy only send out X Byte/s and
priotise internally. It should send less than X B/s uploads if it
already used 2 KB for searching and connects. But mldonkey should not
just stop sending when X KB has been sent but priotize on what to
send. Send chat first, block requests and searches next and only at
the very end uploads.
MfG
Goswin