option to included network overheads in limits

[acm2000]

limit utorrent to 15k/s and its more like 22 due to overheads, it would be nice to have either a check box in the network options, or an item in the advanced options, to set utorrent to calculate the correct bandwidth usages (including overheads) as seen in other clients (emule xtreme etc) , torrent and otherwise, especially on the limits, not quite so important if utorrent is running unlimited, but still would be nice to be able to choose to include overheads.

[acm2000]

no one has any opinions about this feature? :/

i personally feel its a quite important feature that should be added, for accuracy sake, enabled by default on all speeds, not just the limits, gives you the true read out of bandwidth usage.

[oliversl]

+1

Agree, if you configure ut to use only 15kb/s, it must only use 15kb/s no matter what.

Great feature

[dAbReAkA]

i can't understand what u mean

[oliversl]

What it happens is that you configure ut to use only 15kb/s, but if you use a network bandwidth monitor, you realize that ut is using 22kb/s instead of just 15kb/s

[Nefarious]

a better bandwhidt limiter i agree with, using overheads? not so much those programs u mentioned havent help me at all

[acm2000]

emule xtreme has an extra "include overhead" option, the speeds you see and the limits you set, include the protocols overheads etc, so are the true values, i feel thats quite important, at very least be nice to have it as a feature in utorrent that can be enabled, altho should be by default really.

[Firon]

The overhead is nothing more than an estimate, it's not a true value

[oliversl]

Ahh ok. Don't know how to call it then,

but it would be nice to have ut use only what it is told to.

[acm2000]

yeah, especially as torrent overhead can be quite high

[Firon]

BT protocol overhead is included.

DHT is not included in the upload cap (which is why you see it go over)

TCP overhead (and extra overhead, such as ATM or PPPoE or whatever) is not, and it's really just difficult to "include overhead" in the limits because you can't figure it out very well, it's just a guess, and sometimes a pretty bad guess.

[streetstopper]

thanks, firon, for the explanation.

and as such, based on my feature problem/request/proposal, is it possible that we have an option to include the BT protocol in the cap or not?

quite possibly, my upload speed would be stabilized if i can allow the BT protocol to be free and not included in the cap.

[twinlight]

How much overhead can there be? A few kilobyte per second?

[splintax]

TCP overhead (and extra overhead, such as ATM or PPPoE or whatever) is not, and it's really just difficult to "include overhead" in the limits because you can't figure it out very well, it's just a guess, and sometimes a pretty bad guess.

Exactly. Not only that, but assuming you want to cap to 80% including overhead, what is the point? You cap to 80% in order to account for overhead..

[oliversl]

How much overhead can there be? A few kilobyte per second?

If you live in a world @ 16kbyte/s, 2 or 3 kbyte/s is the difference to be able to browse the web while downloading, or not be able to do that.

[twinlight]

How much overhead can there be? A few kilobyte per second?

If you live in a world @ 16kbyte/s' date=' 2 or 3 kbyte/s is the difference to be able to browse the web while downloading, or not be able to do that. [/quote']

I lived in one.. it was called the 90's and my modem was a brutal 56 000 bits per second or about 7 kB/s. 15 years later and you people have "broadband" that isnt much faster than a modem, ouch.

[DonGato]

Wow, you must be rich. Until recently I lived in a world of 12KB/s ;

Of course, impossible to use BT on it... but ed2k (eMule Plus) no problem.

[Ultima]

Not impossible =P

And, it's not about being rich, it's about location. Some places offer broadband for cheap, while that's not the case in other places.

[Firon]

I had 256/128 DSL and I had no problems surfing while BTing

[Switeck]

Currently also there is a problem related to this.

If you want to limit your upload or download speed rather low while the reverse is maxing out, then the SYN ACKs from the reverse also get throttled almost to oblivion and connections can even start dropping.

[Invy]

Whenever i'm downloading like let's say at 1000kB/s, then I can safely say that there is always at least 35-45kB/s upload being added to what I capped uTorrent at. For example, I'll cap it at 32kB/s upload, but my network bandwidth monitor is showing in the 50-60 kB range.

Meh it doesn't bother me much, i'll just temporarily lower my upload a bit more. Besides, the downloads shouldn't take too long at those speeds

[al2k4]

Glad to know I'm not the only one...

I set uTorrent to upload at 24kB/sec (my connection is 50kB/sec upload) so it should be working perfectly fine; except DU Meter actually reports it using an average of 40-45kB/sec, enough to see noticeable performance hits when browsing on the 'net.

If I set it to 80% which uTorrent recommends, which is 40kB/sec, DU Meter reports upload usage of 50kB/sec ALL THE TIME, therefore killing my Internet browsing speeds for everyone in the house.

The overhead is almost as much as the upload itself which I find is a bit disappointing as I can't increase the upload any further to seed the torrents.

Here are my settings if there's anything wrong with them:

Upload Speed: 24kB/sec

Download Speed: Unlimited (it averages at 150kb/sec most of the time)

DHT: On

Encryption: Forced (Allow Legacy Connections: On)

Connections per torrent: 80

Global Connections: 300

net.max_halfopen: 8

bt.connect speed: 20

Any explanations for this massive overhead I'm experiencing?

And yes, I wish this overhead would be included in your upload limits.

[Switeck]

My overheads are nowhere nearly that bad.

Have you ran TCPOptimizer to reduce your overheads?

[wyrmchild]

Apparently TCP "overhead" (actually, TCP header) is only 20-36 bytes per packet (which is usually around 600-1500 bytes in size, including the header) depending on TCP features used. Piece message normally consists of much more than one of these, most other messages fit in single packet, and there's no telling when the O/S net sub-system (e.g. Linux's naggle algo, which can't be applied here since there's no Linux port of µTorrent ) decides to concatenate two or more messages to same peer, eliminating one or more of these extraneous header parts. This _could_ be easily tracked if the client used raw sockets (I think, I don't really know), but there's no point in doing that, just a major inconvenience for this kind of application.

[oliversl]

I think the overhead we are talking here is not about the TCP header, is just the bandwidth that utorrent uses in the bittorrent protocol.

This means that you have setup utorrent to use only like 20kbyte/s, but utorrent is really using 22kbyte/s. That is, 20kbyte/s for the torrent download and 2kbyte/s for the bittorrent protocol.

People wants that utorrent uses 20kbyte/s including the bittorrent protocol, so, the actual download speed of the .torrent should be 18kbyte/s. Just an example.