Hi,

I'm using ktorrent 1.1rc1 und I really like the interface and all.
But it seems ktorrent produces more upstream that it shows. My maximum upload is currently set to 8kB/s and the torrents combined don't show more upstream than that.
But when I use iptraf to check the actual outgoing rate, it goes up to 20kB/s, which is close to the maximum of my connection. I also know for a fact that other programs combined don't produce more than 0.2 kB/s, so it's definitively ktorrent.

Anyone else have this problem?

We only count actual data sent in our upload rate, all the other stuff you're seeing is part of the bittorrent protocol. (requests for chunks, have messages, choke, unchoke, interested and not interested messages)

There are probably some redundant messages being sent around, and we can probably limit the protocol overhead somewhat.

In the current svn, my actual upload is 30 kbyte/s (line maximum), ktorrent shows upload: 0.
This means bittorrent-protocol produces 30 kbyte/s overhead? I don't think so...
That's a bug, and a bad one. Considering other people aren't reporting this it might be system specific? I'm running gentoo, 2.6.14 kernel, kde 3.5, amd64 cpu.
Also, the "overhead" seems to be increasing over time, it's starting out at 10 kbyte/s (+7 kb/s actual upload) and increases slowly until it hits line maximum after a few minutes.

Upgrade to 1.1, we are not going to fix problems unless they occur in the latest stable or the current svn code.

George wrote:Upgrade to 1.1, we are not going to fix problems unless they occur in the latest stable or the current svn code.

it IS the current svn, unless you changed something upload related since I posted...
Also, this bug got a lot worse between 1.1 and this svn.

Sorry about that, I somehow thaught you had 1.1rc1.

We only send what we must send, nothing more, nothing less.

It does however seem to get pretty high.

No problem, I was using 1.1rc1 when I originally posted, but I've updated in the meantime.
Well, if what you're saying is true and all this upstream is neccessary for the bittorrent-network then, sorry to say, it's totally useless. As I said, the overhead doesn't leave any upload for actual data-upstream.
Actually, even ACKs seem to have a hard time getting through...
At how many points in the source-code do you create upstream packages? Maybe I could debug that code and see where all the upstream comes from in detail? (I do know C++, but never looked at the bittorrent-protocol)

I have also noticed quite a bit of this "overhead". In Azureus the BT protocol averages ~5 KB/s, while in KTorrent ive noticed around ~15 KB/s. Perhaps someone could find a way to report the bandwidth in use for the protocol in infowidget.

Oh, and I am also using the latest svn build.

Well, my link capacity is 16KB/s max. and I'm managing to download so I don't think there's 15KB/s overhead... But on the other hand, I've noticed that having small number of peers (with good upload speed) gives me boost in dl speed so maybe we do have a bit larger protocol overhead...

I am using the latest SVN as well with the same issue. Also something else popped up. (It may be unrelated but I don't think so).

Anyway, yesterday I put up ktorrent to download overnight. This morning I check on it and it has downloaded less than I expected, but uploaded about = so no complaints.

Then I notice that web pages are loading slowly. I make sure that it's not a dns problem (which I have had with this stupid ISP). It's not. I checked the forum after this and then noticed this thread. I checked network usage with superkaramba and noticed it seemed off. I then emerged iptraf (thanks to the thread) to check more on things, and sure enough my upload was much higher than it should be. Once shutting off ktorrent (which closed slowly btw, the program was using a lot of cpu also), things were going well and I can now actually post. Trying to register with all my upstream used was very difficult

Anyway, my system is

Gentoo Linux - kernel 2.6.14-r5
AMD64 (x86_64 chost) X2 3800+
2 G PC 3200 SDRAM

I have experimented with including protocol messages into the upload cap, but capping to much hurts download speeds (allthough this might not be much of an issue with people on slow connections).

So my plan for 1.2 is to have a 5 kb/s cap for protocol messages other then data uploads. And some messages will become more important then others (requests are more important then have messages for example)