Jump to content

µTorrent 2.0 released


Firon

Recommended Posts

  • Replies 659
  • Created
  • Last Reply

Top Posters In This Topic

bt.connect_speed is the number of outgoing peer/seed connection attempts PER SECOND. Ideally, this shouldn't be over 10.

I switched back to 1.8.5 a few days ago because I was having throughput problems with RC2. My ISP complained to me 3-4 weeks ago that they thought I had a DOS virus on my system (which I didn't!), but your comment made me think about that complaint.. After your note I checked the advanced settings. I had not changed bt.connect_speed from the default of 20 (yes, 20!), so I reduced it to 10 on your advice.

My recommendation: if a bt.connect_speed value over 10 is considered hostile, then the default should definitely be 10 or less, and certainly not 20.

Link to comment
Share on other sites

rafi

Ok, I find it, did not recognize the new icon because I have acosumbred to the old icon, the green triangle pointing to the right. Thanks.

Now I have another problem, whenever I add a new torrent, add it directly without show the window to add torrents, and select category, download folder and files, etc. however in Preferences->UI Settings, I marked the followes boxes: "Activate program Window" and "Show a window that displays the files inside the torrent."

Link to comment
Share on other sites

spapok had bt.connect_speed set to 2000 outgoing peer/seed connection attempts per second.

I said ideally bt.connect_speed shouldn't be over 10, not that 20-50 were "hostile"...they are just likely less efficient and waste more bandwidth by more quickly retrying dead and firewalled peer/seed ips.

uTorrent v2.0 betas recently reduced the default value of bt.connect_speed from 20 per second to 5 because they use uTP and Teredo connections which are not limited by net.max_halfopen limits. (uTP and Teredo uses UDP packets which are never in a half open state.)

Otherwise, uTP alone (which is enabled outgoing by default in v2.0) could easily have 200-300 in-progress uTP connection attempts at the same time...potentially flooding marginal consumer routers and wireless connections.

Link to comment
Share on other sites

erm, I suppose we'll be able to customize this new... erm... artwork? :P

Regretfully it's not in a 'resources' section of exe... I've found headerless bmps in exe, yet messing with it is a process more detesting than the original cause.

Some external bmp would be fine, just like with toolbar.

Link to comment
Share on other sites

Send it again so it can have the proper atention:

Bandwidth Management (uTP) is causing me problems with the build 2.0 17668, latest of today.

Please see the screenshot:

71651127.png

I have Encryption: Force, Allow Legacy Connections: No.

From the highlighted point in the graph, I have enabled Bandwidth Management (uTP).

Link to comment
Share on other sites

you can work around it, by setting download limit twice so much as your ISP is giving you, setting your upload limit one to five kB less then you have, and set bt.tcp_rate_control to false. works for me. i have full upload and download. i have 448/128 kb, download limit set 100kB and upload limit 14kB. i am downloading at 48-52kB and upload is constantly 14kB, i do not know would it work for your connection but you should play with the settings an see what is best for you.

Link to comment
Share on other sites

BUG REPORT - SETUP GUIDE - SETTING OF PORT

I think something is bad.

Today I changed forwarded ports in router. I tried to change port in uT manually. I did it by Setup Guide:

1) Speed test unchecked, port test checked

2) New port number was set

3) Run tests

Test Failed.

4) Setup Guide was closed by X and open again

5) There is a previous port

6) I repeated 1-3

Test Failed.

7) I checked and unchecked Automatic port forward - Save & Close turned to clickable

8) I clicked on Save & Close

9) Setup Guide was open again

10) Speed test unchecked, port test checked (Port already set)

11) Run tests

Test passed OK.

12) Save & Close

______________________________________________________________

I tried to change port in uT by Automatic port forward in Setup Guide:

1) New port was set

2) Automatic port forward was checked

3) Run tests

Test Failed.

4) I clicked on Save & Close

5) Setup Guide was open again

6) Speed test unchecked, port test checked (Port already set, Automatic port forward checked)

7) Run tests

Test passed OK.

______________________________________________________________

I think that TEST use older saved value of port instead of new unsaved value which was curretly entered to test.

______________________________________________________________

Releases only come out when they're ready, with no schedule pressures, so the few bugs that appear are quickly addressed and fixed.

Is not be better to turn 2.0 back to Beta? As I read here and as I test it, µTorrent 2.0 is not ready to be released as stable (nor more stable as RC).

______________________________________________________________

Edit:

As gui.default_del_action can be set nonsense (for example 6) which disable Remove button on toolbar without any warning. My recommendation: if is it set value (f.e. 6) it will be saved value 0.

Link to comment
Share on other sites

I'm getting very bad downloading speeds with 2.0, so I started to experiment.

I use Cfosspeed that works like traffic shaper and until now worked perfectly with utorrent, maximizing download speed the best it could be. It seems it doesn't work too well with UDP.

But the real problem is another. It seems that my download speed problem is entirely due to UDP upload taking all the bandwidth. In the graph I have the upload total (bright red) at least 150% higher than the limit I set. I guess that upload limits only apply to actual transfer and not to overhead or this wouldn't happen. Well, is UDP upload overhead meant to take all that bandwidth? I get downloading speeds in 2.0 similar to 1.8 only if I set my upload limit at less than HALF of where it was.

Beside the problem of UDP overhead being so huge I'd also like an option to set the upload limit apply to overhead as well. This would help my downloading problem, but it still wouldn't explain why the overhead is using all my bandwidth alone.

Link to comment
Share on other sites

GUI IMPROVEMENT - INACTIVE FEED STATUS ICON

modification of tstatus.bmp

If RSS feed is inactive, it has two arrows inactive icon (download / upload ?).

I think better solution is adding new status icon for inactive feed - gray icon (active feed has orange icon).

But it this change will make problem with loading all older tstatus skins. :(

Link to comment
Share on other sites

I'm getting very bad downloading speeds with 2.0, so I started to experiment.

I use Cfosspeed that works like traffic shaper and until now worked perfectly with utorrent, maximizing download speed the best it could be. It seems it doesn't work too well with UDP.

But the real problem is another. It seems that my download speed problem is entirely due to UDP upload taking all the bandwidth. In the graph I have the upload total (bright red) at least 150% higher than the limit I set. I guess that upload limits only apply to actual transfer and not to overhead or this wouldn't happen. Well, is UDP upload overhead meant to take all that bandwidth? I get downloading speeds in 2.0 similar to 1.8 only if I set my upload limit at less than HALF of where it was.

Beside the problem of UDP overhead being so huge I'd also like an option to set the upload limit apply to overhead as well. This would help my downloading problem, but it still wouldn't explain why the overhead is using all my bandwidth alone.

I also use cFosSpeed and have had great success with it although I rarely upload to huge swarms so I haven't had a real chance to test UDP but I do agree that an option to limit upload including overhead would be beneficial for advanced users.

Link to comment
Share on other sites

fadeout/KayossZero: I'm also for including the overhead inside the upload limit. Actually I even thought this was the indended design when net.calc_overhead=true. Although the current problems with the limiter - seem to be fixed in a debug-release I've tested, this specific issue - is not implemented. But it does behave much better in spite of that ... :)

You may also try disabling bt.tcp_rate_control, until they'll tune this as well...

Link to comment
Share on other sites

i have a problem...when i use utorrent 2.0, i've tried the beta and the last release(candidate 2), i can't use internet at all..it uses my entire bandwight of the internet...with the 1.8 version i could dwnl with 1.4MB/s(my network limit) and steel use the browser....i am woundering if somebody have the same problem like me, and what to do , how to config it..?

Link to comment
Share on other sites

Im sure I over looked the answer to this one so forgive me for asking.

I noticed with both RC builds, UT no longer sticks to my defined upload limit. I have it set to 21 and its behaving as if it were set to 0. Right now its uploading at rates of 53 to 58. Max for my ISP.

Is there another setting that could be causing the upload rate to be disregarded?

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...