uTorrent 2.2 Upload Speed Spikes

Upload Graph with utorrent 2.2:

Upload Graph with utorrent 2.0.4:

It's a BIG difference i think..

Does your ISP disrupt and/or throttle BitTorrent traffic?

@Switeck

According to this no it does not..:

Even Glasnost can be spoofed by ISPs.

Your graphs don't tell much about the torrent swarm/s you were using.

If you're only connected to <5 peers and they're on hostile ISPs, you can get bad results even if your ISP is decent.

It is weird that from 2.0.4 to 2.2 there is so much difference.

Yup you are correct if constant in 2.0.4 then it should be constant in 2.2 beta as well.

Q1. Is it using the same ports / UPNP and DMZ or router configured the same for utorrent ?

Q2. Using same lan IP during both tests ?

Q3. Can you test with another torrent program and confirm same results for same torrent ?

ISP would treat both 2.0.4 and 2.2beta with the same block / shaping so should have similar graph. Actually 2.2beta should have less blocks / shaping and should perform better.

I had issues with the 2.2's and UTP speed limit not working at all or when enabled kills both up / down when only up should be limited.

Try default settings in both 2.0.4 and 2.2beta using 5 downloads that would max out your connection then note if it happens over all 5 downloads or just 1 in both 2.0.4 and 2.2 beta.

Default = might have to delete "user / app data / utorrent folder" to get new installed settings back.

Best might be is to install virtualbox / vmware workstation and bridge internet + clean default windows and test in there, then compare results. Could just be your antivirus scanning / firewall / something stupid on current pc using resources and causing this. Windows update in background ?

Virtualbox clean default xp / vista, no firewall, no antivirus should not contaminated your lan / other pc's + give good results for testing.

Can also test from 2 pc's on lan+internet 1 with completed / stable 2.0.4 and 2.2 beta 0% completed on other pc or virtualbox.

Even Glasnost can be spoofed by ISPs.

Your graphs don't tell much about the torrent swarm/s you were using.

If you're only connected to <5 peers and they're on hostile ISPs, you can get bad results even if your ISP is decent.

I'm pretty sure that my ISP is not using any kind of QoS (except VoIP).

It is weird that from 2.0.4 to 2.2 there is so much difference.

Yup you are correct if constant in 2.0.4 then it should be constant in 2.2 beta as well.

Q1. Is it using the same ports / UPNP and DMZ or router configured the same for utorrent ?

Q2. Using same lan IP during both tests ?

Q3. Can you test with another torrent program and confirm same results for same torrent ?

ISP would treat both 2.0.4 and 2.2beta with the same block / shaping so should have similar graph. Actually 2.2beta should have less blocks / shaping and should perform better.

I had issues with the 2.2's and UTP speed limit not working at all or when enabled kills both up / down when only up should be limited.

Try default settings in both 2.0.4 and 2.2beta using 5 downloads that would max out your connection then note if it happens over all 5 downloads or just 1 in both 2.0.4 and 2.2 beta.

Default = might have to delete "user / app data / utorrent folder" to get new installed settings back.

Best might be is to install virtualbox / vmware workstation and bridge internet + clean default windows and test in there, then compare results. Could just be your antivirus scanning / firewall / something stupid on current pc using resources and causing this. Windows update in background ?

Virtualbox clean default xp / vista, no firewall, no antivirus should not contaminated your lan / other pc's + give good results for testing.

Can also test from 2 pc's on lan+internet 1 with completed / stable 2.0.4 and 2.2 beta 0% completed on other pc or virtualbox.

A1: Yes. The same.

A1: Yep. My lan (and wan) ip is static.

A3: Why? This behavior has to do with these 2utorrent versions. Even if i have spikes with another client i dont have iwth utorrent2.0.4

I've tested this both on my laptop and my desktop.

Others have said they've had speed problems with v2.2 -- so it may be a fault of v2.2

It is strange that you have a very low purple line in the top picture, while the purple line is over half the second picture. That's how much bandwidth TCP peers are using. (The red line is TCP + uTP peers.)

The problem is fixed with 2.0.4 when i change the bt.transp_disposition to 5 and net.upnp_tcp_only to true.

When i say FIXED i mean it. The graph is a straight line for the last 24 hours..

It seems that its a UDP issue..

But is was already straight with the 2.0.4 before the changes.

For sure it is MUCH MUCH better but not as straight as now:

Now its really a straight line.

Like this: ----------------------------------------------------------------

So, what's the verdict on this? Is it a bug that will be fixed in the future or is it something that we, as users, should solve changing the default configuration?

I have the same spikes mpgo using 2.2 with the default advance settings. If I make the changes mpgo proposed--forcing the program to use TCP--the problem goes away, that much it's true.

What I want to know is whether the original problem comes from:

a) a normal behavior of uTP

a problem with the implementation of uTP

c) a problem with my connection

or

d) something else

Though for the time being this solution works, I'd like to be able to use uTP normally.

So, what's the verdict on this? Is it a bug that will be fixed in the future or is it something that we, as users, should solve changing the default configuration?

I have the same spikes mpgo using 2.2 with the default advance settings. If I make the changes mpgo proposed--forcing the program to use TCP--the problem goes away, that much it's true.

What I want to know is whether the original problem comes from:

a) a normal behavior of uTP

a problem with the implementation of uTP

c) a problem with my connection

or

d) something else

Though for the time being this solution works, I'd like to be able to use uTP normally.

More than likely C, Your connection. Either on your ISP's end or your networking hardware (there are many routers and modem's that just aren't built to handle this kind of traffic) If you search around you'll find a few posts with suggestions, (eg turning off flood protection) that may improve the situation. Although if you find that using TCP works well then great.

It is weird that from 2.0.4 to 2.2 there is so much difference.

Others have said they've had speed problems with v2.2 -- so it may be a fault of v2.2

So, what's the verdict on this?

...

or

d) something else

The answer to all of you is:

-- 2010-07-09: Version 2.2 alpha (build 20502)

- Change: new, improved choker

This is a major change, that was not thoroughly compare-tested (to 2.04) by the devs. I have already posted my preliminary test-results on that here:

http://forum.utorrent.com/viewtopic.php?pid=527578#p527578

I'll post here some more up-to-date details later on.

The solution is for the devs to fix-tune the new algorithm (or revert back to the old one), and the sooner the better!

Here are some more details and observations:

* I a case of uploading a well seeded/peered torrent together WITH much less seeded one:

2.04 - balanced upload of the two

2.2 - drastic decrease of upload to the less seeded one. Also in this example

* In a case of uploading w/o a speed limit , and with download at the same time:

2.04 - constant steady upload rate

2.2 - intermitant upload rate

* in a case of uploading two well seeded/peered torrents (for the same time):

2.04 - (350M UL, 41M UL overhead)

Stable upload speed, less connections attempts

2.2 - (300M UL, 48M UL overhead)

Less stable, lower average speed

Total volume is ~15% lower

Overhead is +5% hight (16% instead of 11%)

Connections' attempts rate - constant over the whole time

My previous notes - are still valid, and show in 2.2 a distribution of upload volume proportional to the peers#, when in 2.04 it was aimed to be equal per torrent

- uploading torrents with fewer # of peers in their list - get much less upload-data/traffic than those with plenty of seeds. In older releases - since the # of slots per torrent was a constant - seeding torrents tended to upload more or less the same amount of data.

- uploading when also downloading, and there is no upload limit set - seem to have many cut-offs.

References:

http://img163.imageshack.us/img163/6937/22ul22328.png

http://img221.imageshack.us/img221/8336/22ulgeneral122328.png

http://img121.imageshack.us/img121/9595/22ulgeneral222328.png

http://img843.imageshack.us/img843/2712/22ul1speed.png

http://img412.imageshack.us/img412/6362/22ul1logoutconnections.png

http://img219.imageshack.us/img219/2651/22ul1peersm.png

http://img267.imageshack.us/img267/5685/22ul1peersb.png

http://img811.imageshack.us/img811/2642/22ul1generalb.png

http://img205.imageshack.us/img205/3096/22ul1generalm.png

http://img257.imageshack.us/img257/4676/22ul2.png

http://img840.imageshack.us/img840/6074/22ul2overhead.png

http://img140.imageshack.us/img140/8113/22ul2general1.png

http://img840.imageshack.us/img840/2236/22ul2general2.png

http://img140.imageshack.us/img140/4945/22ul2transfercapoverhea.png

http://img835.imageshack.us/img835/2111/204ul.png

http://img221.imageshack.us/img221/6125/204uloverhead.png

http://img252.imageshack.us/img252/5136/204ulgeneral1.png

http://img100.imageshack.us/img100/4958/204ulgeneral2.png

http://img837.imageshack.us/img837/2055/204ultransfercapoverhea.png

I can confirm similar results, though I had few peers connected to me.

Here's my v2.0.4 long-term graph:

http://img833.imageshack.us/img833/9033/utorrentv204recorduploa.png

Now here's v2.2 long-term graph:

http://img291.imageshack.us/img291/4685/utor22longer.png

v2.2's short-term graph:

http://img843.imageshack.us/f/utor22test.png/

From watching individual torrents, peers would switch from "U" to "u" flag despite having only 3-6 total connected peers and upload speed limit set to 125 KiloBYTES/second.

In the most severe cases, the torrent with 4 peers had ALL its peers set to "u" flag and no uploading to it for a few minutes straight...which caused total upload speed to fall to about 50 KiloBYTES/second.

Even the old "use additional upload slots if upload speed <90%" worked better than this!

At least its not my imagination...

Something is -obviously- broken here..

I renamed the topic to "uTorrent 2.2 Upload Speed Spikes" so people would know what uTorrent version this applies to.

I've passed the details along and a uTorrent developer is investigating this problem.

Im having same problem, with 2.0.4 no problem upload is fine, but when updated to 2010-09-15: Version 2.2 Beta (build 22007) or higher i can upload about half my normal upload per day. NO ISP problem, no firewall, no router, Win 7.

The solution is for the devs to fix-tune the new algorithm (or revert back to the old one), and the sooner the better!

Test results for v2.2 RC2:

Notes:

1. Minimum # of connections is now higher - ~5-7 for my minimal upload speeds of 8-25KB/s

2. Since the overhead is high, I may try later without uTP.

3. Test duration: 1:28-1:37 hours

4. This is a single scenario - with low UL bandwidth. Other ones should be checked by BT devs to verify proper operation.

*In a case of uploading a well seeded/peered torrent together WITH 2 much less seeded ones:

2.04 - balanced upload of the three, with less volume for the very well seeded one (as expected).

Data Volumes are: 31M/28M/18M for the 3, total: 77.5M

Total volume (inc overhead): 90M UL, 10M DL

Overhead: 13M UL (23M total, =30%)

2.2 - Same total volume, drastic decrease of upload to the less seeded one.

Data Volumes are: 63M/10M/0.5M for the 3, total: 73M

Total volume (inc overhead): 90M UL, 12M DL , overhead:

Overhead: 17M UL (30M total, =41%)

* In a case of uploading w/o a speed limit, and with download at the same time:

2.04/2.2 - constant steady upload rate for both

Screen-shots: http://img256.imageshack.us/g/ulgeneraltorrent1204vs2.png/

Edit:

testing With ONLY TCP (same as above, due to the high overhead):

Note: Test duration - 3:12 hours (twice the time)

* In a case of uploading a well seeded/peered torrent together WITH 2 much less seeded ones:

2.04 - A more balanced upload of the three, as before, with less volume for the very well seeded one (as expected).

Data Volumes are: 92M/26M/31M for the 3, total: 149M

Total volume (inc overhead): 157M UL, 14M DL

Overhead: 8M UL (22M total, =15%)

2.2 - Same total volume, same drastic decrease of upload to the less seeded one.

Data Volumes are: 145M/7M/2M for the 3, total: 154M

Total volume (inc overhead): 163M UL, 15M DL , overhead:

Overhead: 9M UL (24M total, =15%)

TCP related screen-shots:

http://img51.imageshack.us/i/ultcptransfcaps204vs22.png/

http://img258.imageshack.us/i/ultcpspeed30scale204vs2.png/

http://img218.imageshack.us/i/ultcpoh204vs22.png/

My conclusions :

- 2.2 RC2 has Much Better upload performance than in previous builds, with totals - matching 2.04!

- Two main differences are:

---> 2.2 has very unbalanced upload - giving mush less data to torrents with less peers (as designed)

---> 2.2 has a +10% increase in total overhead, that seems to be related to the way using of uTP (maybe the new PMTUD effect? the EACK fix ?) . I observed also a +10% increase in PPS .

---> And finally: to my surprise - both latest 2.04 and 2.2 suffer from having DOUBLE the overhead when using mixed uTP+TCP connections (30-40%) than when using TCP alone (~15%)

Slots are over-allocated. I have 10-12 connections @ 25K (1 torrent) Sometimes it temporarily jump to 25

http://img207.imageshack.us/img207/7721/ul10peersat25k.png

http://img145.imageshack.us/img145/4148/ul25peersat25k.png

Following the above and this thread" http://forum.utorrent.com/viewtopic.php?pid=534458#p534458

And a personal record, 14 upload slots now on the latest 2.2 version . What the hell is this version doing?

rafi wrote:

I have 10-12 connections @ 25K (1 torrent)

This is 11: ...

This is 9: ...

The number of upload slots can be a bit higher (up to 2x normal) if upload to some peers in unstable. Stable upload speed or fewer upload slots: pick one.

Either 10 ( =11-9/2 ) or - 14 ... doesn't look like a wrong 'reading'. For a 25K connection the recommendation is 4-5 slots. That, plus the above overhead just need testing/attention.

And I didn't notice any dev paying attention/responding to this thread or any other for that matter on the above issues, or the PMTUD issue. I might have missed it, tho...

My speed guide recommends only 3 upload slots per torrent and only 2 torrents active max at once (for 6 total upload slots) for ~25 KiloBYTES/second total upload speed. 9 upload slots at 25 KB/sec total is bad, 14 upload slots is nuts.

One more test is there:

http://forum.utorrent.com/viewtopic.php?pid=535052#p535052

I guess I should have put it here

I hope they tune it a bit for low speeds and DO release it after all ! I like general concept. did anyone tested at high speeds ? at 30K it seems fine...