Jump to content

How broad is "maximum upload rate" ?


Recommended Posts

Hi there.

First off, please, don't misunderstand my post: it's not (supposed to be) a newbee question.

Here it goes:

I'm not a network guru, but I'm aware that when you are downloading something, you must upload back some "control packets" to keep the information flowing. I suppose that that's why is a bad idea to set maximum upload rate at 0 (zero).

However, I wish to know if these "control packets" are limited by the maximum upload rate too. In other words, when I tell utorrent that my max upload rate is, let's say, 30, I would like to know if utorrent won't, in any circunstance, upload more than 30kb/s in any given moment. For example, these "control packets", DHT information, peer exchange etc. and the upload stream itself would all be covered by the 30kb/s limit.

The reason for this is: I've tested my connection by seeding something and slowly raising my max up rate. For each step, I checked the speed graph for 5 minutes to see if the upload line was constant. I got a top of 35 kb/s, when the line started to go up and down.

Considering that, I would like to know if it would be safe to set my max upload rate at, for example, 34kb/s without hurting my max download speed (I have a cable 2mbit down/ 300 kbit up). If the answer to my question over there is "yes", I presume that it wouldn't hurt it, otherwise I would like some tips on how much should I set my max upload speed. In this scenario, consider utorrent as the only application using the internet in my machine.

The whole idea of this post is to understand how utorrent deals with uploads, so I can share as much as I can.

Thanks in advance! I just love utorrent!

Link to comment
Share on other sites

I do believe µTorrent limits all traffic, including overhead from ACK packets (among other overheads). It doesn't get choked when you upload at the limit since there is still some leeway for ACK packets. It should be fine setting your limit to 34KiB/s, I guess, but you might want to lower it a bit more (so to give some room for other applications)... running the Speed Guide should help you set everything. It sounds to me like your connection speed is somewhere around xx/256k, since xx/384k wouldn't choke at 35KiB/s. Just to be sure, run the Speed Guide like I said -- and be sure to read the instructions.

Link to comment
Share on other sites

So, utorrent would control everything but the ACK packets? Is there a way to calculate how much ACK data I would send for X data received?

@Ultima: I know I could use the speedguide, however, since I'm in S. America, I'm affraid that the results will not be very accurate, because of latency issues and considering that the server used to test it is abroad.

Link to comment
Share on other sites

I do believe µTorrent limits all traffic, including overhead from ACK packets (among other overheads)

I'm afraid you are wrong here. I've tested this matter not once and not two and the conclusion is uTorrent does not limit TCP overhead, it only limits the "clean" transfers between peers.

This mean, unfortunately, that while you're downloading more you're uploading more and this can lead to chocking your (usually asymetric) connection.

Therefore, Jh00, you should test how your upload behaves while your download is saturated to the max and choose the last one "stable" value. But you can still set this 34kB/s as alternate upload value while not downloading.

Link to comment
Share on other sites

The number of ack packets (upload speed required) is determined by the window size for the tcp connection. There are four ways of setting your window size, listed and described here:


If utorrent controls the window size(option #4) then it actually can limit the total upload speed of the connection (because it can calculate how many ack packets are being sent on average).

The rest of TCP overhead is easy to calculate.

ACK packets and TCP overhead is incredibly small compared to data transfer, take this example for instance:

Lets say you have a recieve window of 10KB (10 KiloBytes). This means that for every 10KB of data segments (not including tcp overhead) recieved, you send one ack packet. An ack packet is usually 1 tcp/ip packet with no data: 8 (32bit)words (32 bytes).

The largest tcp packet is 2^16 = 65,536 bytes or roughly 65 KB. There is alot of other things I could say here, but most of it isn't particularly useful. The important thing is that packet sizes are limited by the MTU (maximum transmision unit) which in most cases is usually around 1500 for high bandwidth (cable modem, ethernet, dsl) connections. This means your average tcp/ip packet is going to be 1500 bytes in length (even if the program spits more data at it, it is going to break the the data up into packets of this size to be transmitted over the wire(less) connection).

Lets suppose you are trying to saturate your connection (you want as little overhead as possible) you are going to maximize the size of your packet, so you always transmit 1500 byte packets. With 8 bytes of overhead, you are transmitting 1492 bytes of actual data per packet. So 10KB / 1492 B = about 6.8 Lets say for the sake of ease that for every 7 recieved packets you transmit 1 acknowledge packet.

Ok then; so you have a 2Mb download connection. How long does it take for you to recieve 7 packets (or 10KB data). At 2Mib, you get roughly 2Mb / 8 = 512 KB down per second. Thus, you can download roughly 512/10 = 50 sets of data. Thus, you would send 50 ack packets. (I ignored packet overhead because it is less than 0.005% of the packet).

50 ack packets is 50*32bytes = 1600 B. So your ack packets take about 1.5 KB/s

Thus, if your recieve window is set to 10 KB you should expect to use roughly 1.5 KB/s of your upload in TCP overhead if you are maxing out your download.

Link to comment
Share on other sites

However, there are also the connected but not uploading/downloading ips.

These each receive a keep-alive packet from time to time. (At least once every 15 seconds was the case for the Gnutella network connections, so I doubt this is too much different.)

They also receive information concerning which pieces of the torrent you have as well as requests from your client for them to upload to you. The flags column in µTorrent shows just one way your client communicates with theirs.

Both of those types of messages (keep-alive packets and flags/piece requests) ironically HAVE to have ACK packets of their own. Compound interest, if you will, on something that may never return a KB to you. And if your end never uploads to them, they become FAR less likely to ever send anything to you.

Tit-for-tat, at its worst, becomes nothing for nothing...and everybody loses.

Something to consider if you allow 100's of connections at once.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...