Upload limit not working completely

[lovetour]

uTorrent 3.2.3 build 28705

Usually I have my upload limit set at 47 or 48kB/s -- and it works perfectly fine that way.

But today I noticed that upload limits below somewhere around 35 kB/s were not completely respected -- in the context of the conditions under which I have uTorrent running and configured at the moment.

During my test I had 1 download active, restricted to 100kB/s (less than 1/3 my available bandwidth). Unlike my other forum post on another issue, during this test my system was not under CPU or GPU load.

I restarted uTorrent before this test.

At the conclusion of my test illustrated in the screen captures below, I had somewhere between 300-350 torrents seeding , although I didn't note the exact number. My uTorrent configuration allows 15 active seeds at a time (many are individually limited to 2kB/s, and perhaps 90% of the torrents are on private trackers and perhaps 90% of the private torrents have 0 leechers at any given time, causing uTorrent to automatically take more and more torrents out of the queue and maintain active contact with the trackers in the event of new leechers appearing and to maintain full upload speed). I don't think it is relevant, as it clearly causes me no trouble -- but it could be an untested configuration these days and somehow effect the bandwidth limiter -- but I keep my half open connection limit set to 150 (I'm on Windows 7 and MS long ago got rid of the half-open connection limit that plagued a range of Windows versions and service packs). My router seems to handle it and it gets things going fast/keeps things going fast. Since I'm seeding many torrents, even with only a handful active, I have my total number of connections set to 250, as uTorrent has to do a lot of "talking" to maintain 300-350 seeds and a high-speed download or two, not to mention DHT tracking.

Above: 1,000 Words

Below: A Picture

30-second resolution Speed graph

In the above image, over the course of just under an hour, I demonstrate the result of setting various upload speed limits:

(1) Initially the limit is 20kB/s (uTorrent goes ahead and transfers at least* 26kB/s)

(2) The second limit set is 30kB/s (result: ~ 33kB/s*)

(3) The third limit is 40 kB/s (result: ~40kB/s* -- as expected!)

(4) The fourth limit is 26kB/s, chosen because that was the actual rate uTorrent reported in #1, above (result: ~31kB/s*. My theory that it might be happy to do 26kB/s if set for that was proved wrong.)

(5) The fifth limit is 10kB/s (result: ~35kB/s* ! )

(6) The sixth limit tested is 1kB/s -- basically the minimum. Here I would expect it to stop all upload activity as ACKs, requests, etc., and DHT will create more overhead than this (actual result: initial escalation to ~52kB/s* which includes both added download and a greater proportion of overhead. This lasted around 4 minutes, during which time many tracker updates failed with timeouts, not sure if this was a coincidence or not. Plenty of upload activity kept on flowing, although the number of torrents actively involved seemed to decrease somewhat. That 4 minutes was followed by an approximately 1-minute drop in upload rates reaching a minimum of ~24kB/s* before escalating back up and appearing to stabilize at ~40kB/s*) This setting showed the most dramatically unexpected behavior.

(7) Finally, I tested 40kB/s again (result: ~40kB/s* -- nice)

At the end of the test, I brought up the uTorrent Statistics window. Here is the bottom portion of it which shows how many connections were made during the course of the test, how many there were at the end, and in what state the connections were at that time:

Statistics - Connections (course of test: ~ 1 hour)

Some of my settings (start of test):

Advanced: 150 half-open connections

My questions:

A. What might account for this?

B. Can I resolve the issue and achieve the same ends (less this problem) in uTorrent?

C. This appears to involve one or more bugs. The exact desired behavior could be up for debate in the extreme case of an upload rate limit too low to handle DHT traffic, and/or tracker traffic, and/or maintain the desired download rate. I would suggest that the upload rate (and download rate) should both be hard limits, and let the chips fall where they may given those restrictions. uTorrent should be as sensible as possible about what sacrifices to make and it what order. My test case was fairly simple (1 download desired, 0 uploads realistically expected at the 1kB rate; all seeding should have seized, and the download rate limited if required to meet the 1kB goal, but before that, DHT should have been stopped or cut back to minimum connectivity if it were a source of overhead, etc.). Should I report it and do I have a reasonable amount of data to do so?

One part-solution for C. might be to have a hard rate limiter thread in the data pipeline that enforces those limits (at least for upload). uTorrent when then experience heavy congestion on that pipeline if it doesn't make all the changes in communication strategy appropriate to the bandwidth limit, and secondary results thereof will naturally become a reality (possible drop in download speed and connection timeouts). The smarter uTorrent is, the better it can utilize the bandwidth available, but at least the user's set limit is respected with this one step.

Thanks,

LT

* footnote: All the byte rates reported by uTorrent, when inclusive of overhead, fall short in my experience. This is not totally topical, but since I believe there is a miscalculation of overhead (an underestimation), it's possible that that miscalculation is part of the reason for the inability to manage my upload rates in the context described herein.