Re: [Mldonkey-users] Protocol efficiency

[Goswin Brederlow]

"Christian H. Kuhn" <address@hidden> writes:

> Hi,
> 
> Small network: ADSL (768/128 kbit), linux router, linux client with
> mldonkey, win2k client with eMule. Port 4662 is forwarded to mldonkey,
> port 4666 to eMule. When only one client is on, the network performs
> very well. Download rates of 50-70 kB are often reached, while upload
> rates can reach 12 kB.
> 
> Problem: When both clients are on, the DSL upstream is
> overloaded. mldonkey uses a TCP protocol, if i'm right, so both upload
> and download are affected. By try and error, i stated that the
> settings should not exceed 5 kB upload and 10 kB download for any
> client. Concerning the upload, i won't complain. But if i give more
> download speed - and this is mainly seen for the mldonkey - then the
> UPstream explodes. Even 12 kB is too much, and the overload of the
> upstream destroys both upload and download rate.
> 
> I know that the donkey protocol has much overhead and is not very
> effective. Ok, this is not to change. My question: is the
> implementation in mldonkey different from other clients? Why creates
> mldonkey so much more upstream traffic? Is it possible to reduce this?

Its a problem of dsl and tcp/ip.

First your upstream is so much smaller than your downstream.

Second TCP needs to acknowledge every frame it recieves and only a
limited number of frames are send before the sender waits for ACKs.

Third ACKs fullfill two functions at once: a) error correction. Frames
that are not acknowledges get send again. b) flow control. If the
datarate exceeds the bandwith of the connections router will just drop
frames and through missings ACKs the sender guesses when to send
slower.


Put all this together and you get the following:

You donkey floods the upstream, so there is a big delay between an
incoming frame and the resulting ACK reaching the sender again. ACKs
do have to wait in line behind all your donkey traffic.

The sender sends a few frames and then has to wait for the ACKs. It
waits and waits and waits and figures that your a very slow modem user
that can only recieve 1 KB/s or so. If you had a faster connection you
would have send ACKs by now.

Of cause mldonkey having so many connections at once doesn't realy
help sending out ACKs fast, because they are send out in clusters and
with 1kB/s it takes a while before a cluster is full and can be ACKed.


So what can one do?

1.) Limit the upload to 4 KB/s for each donkey. Don't have more than
12 KB/s upload alltogether. The ACKs need some bandwith too so 4+4
does make 12 given enough downloads.

2.) Use QoS (Quality of Service) alias "Fair" Scheduling.  You can
resort waiting frames so ACKs can skip to the front of the line. You
can also limit the upload generated by mldonkey to say 8KB/s
alltogether for all clients so there is enough for irc, web, mail,
ftp. You can schedule the traffic so that mldonkey only gets bandwith
thats not used up otherwise, usw.

MfG
        Goswin

PS: Of cause you need linux for this :) And you can mark the network traffic 
depending on the user, group, pid or binary that generates it to even catch 
connects on non default ports.