µTorrent 2.0 released

right, so with 0.85Mbps you can get to only about ~15Mbps. Don't they cheat if they say you can get 20 since it's theoretically impossible to get ? (I was hinting to that when I said it's ridiculous to buy for a 1:20 connection and expect it to actually work)

possibly wrong uTP overhead calculation (bt.transp_disposition = 10) :

(from IRC: <alus> _rafi_: that seems to be an overhead difference )

also - you should explain "0" value in the help file, since it's set to that by disabling "traffic management "

http://img534.imageshack.us/img534/6082/41917076.png

nt.calc_overhead is disabled by default currently, because it needs more work. Please be patient.

I am... it's just thought you'll want it for the record, before I delete this shot ...

Still, even if only data rates are correct (75K/13.7K), UDP overhead is huge... (17K ? >17% ?) . Something to think about ...

Oh O. I though final release will be fix on many thing but it's RC5 and I think 2.0 is good manage but not good bandwidth. I think I will using it on 2.5.

Thank you.

what is 2.5 ? ...

A guess v 2.01 will come soon enough too ...

version 2.5

version 2.5 doesn't exist.

Could everyone with bandwidth problems try setting bt.tcp_rate_control to false and let us know if that helps? If not, you can set it back to true.

what problems ?... no change over here ...

No problems here either. But

I think 2.0 is good manage but not good bandwidth.

but... I really do currently use only 20% connection speed (due to "bad" popular torrents with thousands of peers... which is , maybe another issue to double check)...

Ondoy graphs (like 3-4 pages ago...) show he tries to max his connection, and don't want to settle for 90% ... ;P

Mr rafi and someone ever told me before about rate control and results are no difference but now it's seem better when disable it but not compare with 1.8 yet because time zone - -. You Know? And now my torrent have a few seed I don't want to take a risk for this. ^^

One thing what a definition of "rate control" on 2.0.

Thank you.

I turned off tcp rate control and it actually seems to have fixed the speed issues for the most part. I'll continue testing, but it seems to be working well for me.

µTorrent started by firefox for adding new .torrent. Windows 7 x64. And hangs... Old bad bug...

Dump: http://www.mediafire.com/?wnzgntjzxzj

I have 21% overhead when uTP is enabled, and only 5% when it's disabled, bt.tcp_rate_control=false not help

impossible... screen-shot including NetMeter ?

right, so with 0.85Mbps you can get to only about ~15Mbps. Don't they cheat if they say you can get 20 since it's theoretically impossible to get ? (I was hinting to that when I said it's ridiculous to buy for a 1:20 connection and expect it to actually work)

No - if you read my earlier posts you'll see that I get 20Mbps sustained download, but I've only seen 15Mbps while torrenting (so far) - the 20Mbps is while downloading over a single connection. Obviously the overheads of managing the increased number of connections also cuts into usable bandwidth when torrenting (and who knows - maybe I've got a 20% uTP overhead as was posted 2 posts above, but I haven't investigated). Now, I agree with you that 10Mbps down/0.25Mbps up is pretty ridiculous (though I lived with it for 7 years ...), but 20Mbps down/0.85Mbps up works quite well most of the time.

ADSL (Asymmetric Digital Subscriber Line) is entirely based on the idea that people download a lot more than they upload. Obviously, that's not true for torrenters, but the idea underlies all broadband internet services in Australia, and for the majority of people it is still true.

I should also add that other net activities are not being affected in the slightest when torrenting, although that's possibly invalid for this discussion because I run cFosSpeed on my server (where the torrents happen) which does bandwidth management to ensure that torrents have the lowest priority (though ACKs on that machine are still high priority).

@magao: I stand corrected. by "to work" I meant to work with torrents. the ~5% overhead was measured using uTorrent, not HTTP downloads. So, that can explain what you get - ~15M...

Greg:

Could everyone with bandwidth problems try setting bt.tcp_rate_control to false and let us know if that helps? If not, you can set it back to true.

Since it seems that on Saturday my ISP decided to shape us all... here it is the results now (with & w/o it, restarting the same torrents. Looks similar, both not maxing my 320K connection in uT graph's opinion... ) :

http://img714.imageshack.us/img714/304/31059502.png

@rafi: here

TCP only:

TCP + uTP, tcp_rate_control=true:

uTorrent always start with many uTP connections, after some time peers reconnects through TCP, so overhead decreasing but never reach first picture, if tcp_rate_control=false it's only speed up peers to reconnect through TCP =)

What are your OS/connection-speeds/uT-main-settings , and why is the speed "stuck" at ~125K ? Well Step, there sure is a problem with your system... I can divide it to two parts:

1. in uTorrent, that does not yet calculate the overhead well, so you cannot actually fully trust the graph

http://forum.utorrent.com/viewtopic.php?pid=451028#p451028

2. in your system (OS and/or uT settings) ... bellow is my counter graphs... it displays about 40K oh @ 300K, and you have ~27K at 130K (and I'm not saying that 12/25% oh are not high). I guess possible reasons can be:

- too many concurrently connected peers

- improper upload limit

- bad setting in your OS/router (small MTU?), causing smaller packets to be sent

- another unknown issue ???

I suppose a good test will be like the one Ondoy did a few weeks ago - DL a whole small file and see the time it takes to complete + the transfer caps - with TCP/uTP

Edit:

...and the traffic volume test I suggested (issues are in red):

uTP (volumes & graph):

Uploaded (data): 760KB

Uploaded (amount/overhead): 8.9MB (~6% of DL)

Downloaded (data/file-size) : 137MB

Downloaded (overhead) : 24MB ~17.5% of DL

Graph display:

Upload (overhead/amount): ~6% of DL

Downloaded (overhead) : ~10% of DL (wrong on the graph)

TCP (volumes):

Uploaded (data): 950KB

Uploaded (overhead/amount): 8.9MB (~6% of DL)

Downloaded (data/file-size) : 138MB

Downloaded (overhead) : 13MB ( ~9.5% of DL)

Conclusions/bugs:

1. uTP download overhead is quite large (~17.5% !)

it also errored on the graph . It should be appropriate to reduce it to at lease the TCP 9% level if not less!

2. Caps should include the overhead, since the ISP measures it as well.

Important notes:

1- overhead was minimal when I did those tests locally on my PC (2 uT instances).

2- packet sizes were around ~1400 bytes on both TCP only tests and local tests (TCP and uTP)

3 - packet sizes varied between ~300 - ~1400 bytes in the above uTP test. This might be causing for the extra overhead !

I fixed it by using this config, speed goes directly from 0 in jumps of 100-300 to 1.85mb in 10 sec. Cable Download 16 Mb/1 Mb Upload connection, max is 1.98 .

*Whatever Written here should be ENABLED* *What Ever not written here should be DEFAULT*

Windows 7

PORT : 45222 -or whatever you want.

ENABLE UPnP port mapping

Enable NAT -PMP port mapping

Add Windows Firewall exception

Bandwidth

MaxUpload when downloading: 35

Global Maximum Connections: 550

Maximum number of connected peers per torrent: 125

Max upload slots: 30

BitTorrent

Enable Local Peer Discovery

Ask tracker for scrape information

Limit local peer bandwidth

FORCED - Allow incoming legacy connections

**DISABLE Enable bandwidth management

Advanced

bt.connect_speed : 5

bt.tcp_rate_control : True

bt.transp_disposition - Default 15 - should set 255 but might shown as 245 after restart.

net.max_halfopen : 30

*Whatever Written here should be ENABLED* *What Ever not written here should be DEFAULT*

**DISABLE Enable bandwidth management

bt.transp_disposition - Default 15 - should set 255 but might shown as 245 after restart.

'DISABLE Enable bandwidth' ==> bt.transp_disposition = 5

So, which is it ? 5/15/255/245? TCP or uTP ?

I understand it is now with bits: 1+4 (TCP) + 16 (useless new uTP header). Same as my results for TCP

So the best of 2.0 is only udp tracker, I think utp is much more to fix. Look like stable utp will be 2.5.

Thank you.

So the best of 2.0 is only udp tracker, I think utp is much more to fix. Look like stable utp will be 2.5.

Thank you.

uTP is quite stable, actually.

Are you having problems? Have you tried disabling bt.tcp_rate_control?

it's performance issues, not stability . look back pages 13/14 @ his graphs/data