Jump to content

µTorrent 2.0 released


Firon

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)

Link to comment
Share on other sites

  • Replies 659
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
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

Link to comment
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.

Link to comment
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).

Link to comment
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

Link to comment
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 =)

Link to comment
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 !

Link to comment
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*

Link to comment
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 :)

Link to comment
Share on other sites

Archived

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

Guest
This topic is now closed to further replies.

×
×
  • Create New...