I noticed that while I have KTorrent limited to 20KB/sec down and 10KB/sec up, according to bandwidth monitoring tools, it actually uses 20-30KB/sec down and 10-20KB/sec up, while the KT status bar shows it remaining within limits. I'm wondering if KT doesn't include DHT or scraping or other protocol traffic (basically, non-data traffic) in its limits. Is this correct? If so, could KT be changed to include them in its limits?

It's most likely protocol overhead. Each TCP/IP packet has a rather large amount of overhead. If you take a look at the nature of networks, particularly ethernet, you see you have at least 3 layers of protocols before you hit the Application layer (HTTP/BT).

For a common ethernet example, you have the Ethernet packet header and CRC (~38 bytes), then comes the IP header (20 bytes), and then the TCP header (20 bytes). So give or take a few bytes, you're talking 78 or more bytes per 1500 sized ethernet "frame"/"packet" are used for only protocol useage.

So that will account for some of the extra bw. Its possible that KT doesn't take into account some things, but I doubt it. Bandwidth limiting also isn't the easiest thing to handle properly.

Though I don't often see KT use more than I've allowed it. Not for a long time.

DHT and connection setups are not included, webgui is also not included.

Upstream is easily controllable, so you should have a rather steady upload rate provided the other peers and your internet connection can handle it.

Downstream is a different matter, if you have a fast seeder, it can go up and down a lot, but the average should be OK. We can't control the other peers, we only control the rate at which we read from the network connections.

Thanks for your replies. I was mainly comparing it to Azureus, which reports at least some of the protocol overhead in its statistics, but I haven't done much of a comparison. It's really not a big deal anyway. Keep up the good work.

I've found that the upload limit ( I've never approached the download limit on mine ) seems to break after a while and uses the full upstream of my limited BB which slows everything else down and is a bit annoying!

madtom1999 wrote:I've found that the upload limit ( I've never approached the download limit on mine ) seems to break after a while and uses the full upstream of my limited BB which slows everything else down and is a bit annoying!

Version ?

blujay wrote:Thanks for your replies. I was mainly comparing it to Azureus, which reports at least some of the protocol overhead in its statistics, but I haven't done much of a comparison. It's really not a big deal anyway. Keep up the good work.

I've looked through its code before and IIRC it just uses a constant multiplier to guess protocol overhead in enforcing its limits.

jdong wrote:

blujay wrote:Thanks for your replies. I was mainly comparing it to Azureus, which reports at least some of the protocol overhead in its statistics, but I haven't done much of a comparison. It's really not a big deal anyway. Keep up the good work.

I've looked through its code before and IIRC it just uses a constant multiplier to guess protocol overhead in enforcing its limits.

It may also be talking about overhead associated with Bittorrent protocol - handshakes, keep-alives, choke, intersted, etc and not raw protocol overhead, although it may account for this some. Trickle may be able to help you, although I don't know much about it.