Archived

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

Firon

µTorrent 2.0 released

Recommended Posts

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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

@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

31059502.png

Share this post


Link to post
Share on other sites

@rafi: here :P

TCP only:

2e398467ba84t.jpg

TCP + uTP, tcp_rate_control=true:

09b9c648ed80t.jpg

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 =)

Share this post


Link to post
Share on other sites

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... :P 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

20442627.th.png

20190520.th.png

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)

cap1utp.th.png

graph1utp16275305.th.png

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)

cap2tcp.th.png

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 !

Share this post


Link to post
Share on other sites

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*

Share this post


Link to post
Share on other sites
**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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.