Uploadspeed problem: "the net allows it, uTorrent can't keep up?"

[sk-lt]

I think it works like this:

If the piece size is like 2mb, it loads the whole requested peace into memory, sends it and loads the next one requested. Duno if this is right, but... It does reduce the HD usage (and does cause uTorrent to crash... with read_cache set to 5000 (I know this isn't 5MB, bus who cares:), only on 1MB/s uploads)).

[dAbReAkA]

now on the topic.. are there another things to be done to improve the performance? probably against bitcomet?

more aggressiveness against bitcomet?

AllWeasel's post should be considered

[1c3d0g]

To add further fuel to AllWeasel's proposal (on increasing the request queue), let's take a look at just how many requests KTorrent sends:

This was on a small swarm (PocketLinux distro: 6 seeds excluding your truly, and 3 peers which only one of them was this KTorrent peer leeching from me). Now, I'm not saying we should go overboard like that (after all, BitVomit does it similarly), but instead of the 1-2 you usually see, increasing it to 10-12 is not an unreasonable amount - IMHO. Even if it's increased to 3-4, that's still double the amount of requests than what is sent previously. I really think someone needs to take a look at this proposal seriously... :|

[Firon]

It only used that much for you? It was requesting about 3000 pieces from me, even after I choked it. Used about 2 KB/s in downstream from the BT overhead alone.

[1c3d0g]

It was steadily dropping fast (from around 700 when I first looked at it). So I wouldn't know how much it requested at first...

[Computer Guru]

How come no big and miighty programmers are posting here?

[chaosblade]

There's only one like that (ludde) and he doesnt post unless its really needed. But some of us who help around make sure he sees the important stuff.

[Computer Guru]

oh ok, thanks

Just getting to know the system here

[AllWeasel]

To add further fuel to AllWeasel's proposal (on increasing the request queue)... [snip]

AllWeasel got his wish in build 405 and AllWeasel is pretty darn happy about it. The night following my last post, I had a chance to pull 4 large torrents from a public tracker. With the newly-increased req queue behavior, I was able to completely saturate my DL bandwidth. I was *averaging* 980-1078 KiB/s download rate from a 9 Mb/s cable [according to perfmon's long-term average]. According to cFosSpeed (and confirmed by perfmon's burst readings), the DL rate would peak at 1200+ KiB/s routinely, so I'd guess that my ISP was throttling my DL to cap it at the 9 Mb/s that I paid for.

I had to significantly lower my "normal" UL cap to allow utorrent to move that kind of data. At 1 Mb/s or roughly 100 KiB/s (real life) upload, I can normally push the upload cap as high as 90 KiB/s and not adversly affect my DL rate enough to bother me. Your milage may vary because I often download research material where the swarm is tiny, and the DL rates are low. I like to offer as much UL as I can, so I tend to set my normal UL cap around 90-100 KiB/s and pay for it a bit on the other end - when necessary.

On this particular occasion, I found 4 mainstream (popular ?) torrents of 850 MiB to 5 GiB in size and I was eager to test the new req queue behavior. In order to get the 1MiB/s DL rate mentioned above, I had to drop my UL cap to about 70-75 KiB/s. The point is that the UL cap adjustment was very normal in this situation and exactly what you'd expect. Moving the UL cap up or down had a smooth linear effect - which is a vast improvement over the utorrent build 401 (or whatever) that I had been using previously.

From empirical observation, I think utorrent is a bit overzealous with the reqs when it starts a connection, but I can't say that it should be changed because it has no real downside. If you request 1,2, or even 3 pieces initially, you can easily cancel the extra req(s) on any subsequent ack message without incurring any extra packet overhead.

However, if I had to pick nits and I really don't think it's that big of a nit... I'd say that utorrent would do slightly better if it used a different algorithm to calculate an appropriate depth for the req queue *at high data rates*. I think utorrent does just fine at lower rates and when I tally the number of times that the req queue looked too low and compared it to the number of times that the req queue looked too high, I come out pretty much even (for build 405+ on low-moderate flowrates).

I think utorrent could use a less linear (or more non-linear) calculation that gets a bit more aggressive as the datarate increases. This would allow for a faster ramp-up and less recovery-lag when the rate is peaky in nature. I won't presume to tell Ludde how to write code, so I won't suggest ways that he could implement this non-linear behavior. Ludde is perfectly capable of doing this if he feels it's worth the time. If Ludde should ever want my input on anything - he'll send me an email.

In summary, prior to build 405, I had some issues with artificially low DL rates and it was on the edge of making me switch to another BT client (if only temporarily). After build 405, I have no reason to think changing to another client would offer a better DL / UL platform. If there was a reason to use another client, it would not be based on performance, it would be feature-related. I think AllWeasel's suggestions *were* taken to heart and Ludde took care of it prett well and very, very quickly. Download a post-405 build and try it yourself. If your issues were req-queue related, you'll see a huge improvement. If not, then you're chasing the wrong problem.

I think there is room for improvement in the req-queue management, but I think Ludde made a huge improvement in build 405 and it changes the req-queue issue from "serious impediment" to "could be improved" - at high datarates. Again, it seems to work perfectly for me at rates lower than 350 KiB/s. Above that, becomes increasingly less efficient at maintaining control over things, but it *never* falls on it's face like before. It's just ... how can I say this ... a bit sloppier, a bit "coarse" in it's req queue management when data starts really screaming at it. Then again, it's possible that I'm seeing my ISP cap my DL rate and that's what is causing utorrent to oscillate a bit.

I think there are now other issues that have a more significant impact on the overall effectiveness of utorrent's swarm behavior. IMO, maintaining the peer pool, and handling peer connections in general, would offer more return on investment at this point. But that's another topic altogether.

[sk-lt]

Huh... I think, builds 411 and 412 have again less eficient upload system... Not only for me. All users went back to 406.

PS> I'm using the read cache.

[dAbReAkA]

same efficiency as 406 here.. despite the upload speed was fixed i can't reach more than 1.3 mb/s against bitcomet users

if they change their client to µTorrent i can hit 5 mb/s.. we're on a 100 mbit lan (theoritically capable of 12 mb/s, but with this certain user 5.. he is too far away) uploading at 1.2 mb/s now sometimes going up to 1.4 mb/s on the previous page where i posted my results from the tests u can see the same result uploading to myself