Jump to content

µTorrent 2.0 beta 17539

Firon

By Firon
in Announcements

Recommended Posts

  • Replies 751
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

twipley Member

twipley

Posted
Posted

There is that bug in which, when you choose the location for a new file to be saved, in the "save as" field it is written something like "C:\torrents," but upon pressing the "..." it is shown some other location, such as "C:\hugo\stuff," which is where you in fact want to save the file.

So, you press the "save" button (just above "cancel"), but the "save as" field remains "C:\torrents." To fix that, you can either hand-type "C:\hugo\stuff," or press "..." again, navigate back one level to "C:\hugo," and back to "C:\hugo\stuff." Then, press save and that way the "save as" field indeed gets modified. In other words, it seems that under some circumstances one has to navigate inside a folder structure for the "save" button to successfully register the desired location of the saving.

Link to comment
Share on other sites
Cline Newbie

Cline

Posted
Posted

When it will be announced a stable release of the version 2.0. If you have chosen the make an 2.1 version to opgrade the 2.0 BETA this tells me that the 2.0 version is unstable. So, i'm new on this forum, if this question jas been posted before i'm sorry, but if not when can we see a stable 2.0 version?

Link to comment
Share on other sites
rafi Advanced Member

rafi

Posted
Posted

well, here is my theory - it's about ~5% of your upload rate. This is approximately the TCP Ack overhead for this connection, and uT shows it. As I remember , this is usually due to the fact that you have your adv->net.calc_overhead set to true (as I do... ). This is a good thing (at least for my poor unbalanced 1:10 connection) since it makes uT refer to the limits you set in the true sense of the total traffic, not only the data. So, the side effect is that you also see this overhead in the numbers.

You can try to reset your calc_overhead (if I'm right ) and this will seem to disappear. Actually it's still out there - and you can see it using an external speed measurement tool... :)

I would suggest to the devs to maybe add another option - to control if to VIEW the speed with or w/o the overhead.

Link to comment
Share on other sites
maz125 Newbie

maz125

Posted
Posted

hi all this version rocks :) the only fault I can find with it is with the new transfer cap. I'm assuming it's there for ppl like me on the dreaded virgin media broadband who use traffic management. while this is welcome addition it is not detailed enough as the amount we can use changes at different times of the day (i.e. I get 3.5 gig between 10 and 3 unlimited between 3 and 4 then I get 7 gig between 4 and 10 so it would be better in my opinion if it was incorporated into the scheduler. I hope this is put in the next release.

Link to comment
Share on other sites
phoenix977 Newbie

phoenix977

Posted
Posted

Just upgraded to 2.0 beta, build 17427. I was downloading 5 torrents at the time I decided to upgrade. I know, not the smartest move, but it was telling nonetheless. My download speed with these 5 torrents when using v1.8.5 was 1.75 MB/s, which is a typical DL speed for my connection. After the upgrade to 2.0 beta, my download speeds (while downloading these same torrents and (presumably connected to the same peers) has hovered around 100-200 kb/s. Both DL and UP speeds are set to unlimited. I have "Enable bandwidth management enabled" but turning it off makes no difference in the DL speed.

Any thoughts as to why my download speeds would wither away like this with 2.0 beta. I obviously want to take advantage of my nice 1.75 MB/s speed. Thanks!

UPDATE: I did a little reading on the forums and turned off the tcp_rate_control and my DL speeds sprang back up.

Link to comment
Share on other sites
phoenix977 Newbie

phoenix977

Posted
Posted

Thanks! That worked. My DL speeds are back to normal.

I've also been reading about users increasing the utp_target_delay; that the default 100 is just too restrictive. Might this be helpful as well? And if so, what would you recommend I increase it to? Or should I just leave well enough alone??

Link to comment
Share on other sites
Daetlus Newbie

Daetlus

Posted
Posted

Don't know if there is a separate thread/forum for bug reports on beta, so I'm just dumping it here.

I've tried a few 2.0 builds, the latest being 17427, and with each one, I've found that either the way that my upload/vs upload limit is being displayed differently, or my upload limit isn't working.

I typically set my upload limit for about 55kB/s, and I've been sitting here watching it truck along at about 75kB/s for 10 plus minutes. Everytime I revert to the latest release build, it goes right back to acting like it normally does, rarely going above the limit more than 1-2kB/s on occasion.

A quick screen shot while running shows that my total up speed on torrents is 71.3kB/s, screenie shows 74.3kB/s, and my limit, set at 55kB/s.

What could have changed that could have caused this problem?

Link to comment
Share on other sites
Firon Advanced Member

Firon

Posted
  • Author
Posted

It's being displayed differently, but there is another bug that makes net.calc_overhead not be taken into account properly (this shows you estimated TCP overhead for all traffic, showing you the true amount of bandwidth being consumed). We've fixed it, but it will probably reduce your download speeds, since the reason it overshoots is because the download traffic isn't being ratelimited.

Link to comment
Share on other sites
rafi Advanced Member

rafi

Posted
Posted

Good to hear that you have fixed it :)

There is no reason to worry about limiting the DL. This IS the reason for this calc_overhead - to limit your download when the TRUE (overall) traffic is really reaching your UL limit. You have those two parameters put/set there for this reason - to do just that accurately, and give your other apps. some bandwidth as well, since you have THIS connection width ... ;) And it will not limit your DL at all if you are BELOW the limit...

Now, another question is - how to display it in the graph & numbers

1) with the overhead

2) w/o the overhead

3) both ?

If you choose - 1 - people will ask about the non zero (overhead) display - like the DL when seeding

if you choose - 2 - it will not show the graph reaching close to the limit

I think one way to solve this - is to have also separate column(s) for : data only and maybe overhead only. And on the graph - a check-box (or advanced option) if to display a dotted-line for net-data as well.

Also - I would think of choosing the proper defaults (maybe set the default column as "data only" and default graph - as both lines (or just data+overhead as today)

Link to comment
Share on other sites
aloznogrog Newbie

aloznogrog

Posted
Posted

hi!

I've recently autoupdated to 2.0 beta (17427) and it behaves funny: constantly eats 6%-12% of CPU (no DL, just uploading) and DL is ALWAYS at around 50 kB/s when uploading at full speed (1.2 mB/s in my case). with previous versions, upload was no more than 7 kB/s.

also, the brousing has become noticeably slower when uTorrent is running (never a problem before). the overall responsiveness of the system seems to degrade a little, too.

the system: Core 2 Duo T5800 (2 GHz), 3 Gb RAM, Vista SP2, NOD32 4.0.468.0.

Link to comment
Share on other sites
Firon Advanced Member

Firon

Posted
  • Author
Posted

The upload was always that high. The difference is that 2.0 shows you the overhead from TCP, whereas older versions don't. It's not actually using any more upload.

Also, make sure that NOD32's firewall or any firewall-like feature (email scanning, p2p scanner, whatever) is disabled for utorrent.exe.

Link to comment
Share on other sites

Archived

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

Go to topic listing
×
×
  • Create New...