rafi Posted November 28, 2009 Report Share Posted November 28, 2009 @DeathStalker: Didn't I say that UDP trackers are NOT supported in 1.8.x ? and moogly said that 255 is bad for backword compatibility. so why use it now and get less uTP seeds ? ... Link to comment Share on other sites More sharing options...
DeathStalker Posted November 28, 2009 Report Share Posted November 28, 2009 Ok, that's what I thought. That's why i inquired if there was any rough guesstimate when a 2x version would become official. Link to comment Share on other sites More sharing options...
Zarggg Posted November 28, 2009 Report Share Posted November 28, 2009 Honestly, the best thing would be to convince your private tracker to unban 2.0. It works just fine except for a minor HTTPS bug that exists in 1.8.x anyway.Edit: Oops, I missed that. I haven't been following that line too closely. :/ Link to comment Share on other sites More sharing options...
moogly Posted November 28, 2009 Report Share Posted November 28, 2009 HTTPS bug remaining in 1.8.5 is fixed now, look at the changelog. Link to comment Share on other sites More sharing options...
twipley Posted November 30, 2009 Report Share Posted November 30, 2009 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 More sharing options...
Cline Posted November 30, 2009 Report Share Posted November 30, 2009 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 More sharing options...
thesteveman Posted November 30, 2009 Report Share Posted November 30, 2009 I am using 2.0 Beta with the latest build 17427.One thing that seems a little odd is that on my seeds, I am seeing downloads speeds ranging from .1 kb to .8 kb in addition to the upload speeds, which look normal.Should I be seeing any download speeds at all? Link to comment Share on other sites More sharing options...
rafi Posted November 30, 2009 Report Share Posted November 30, 2009 can you give an example of a pair of upload/download speeds for a single torrent? Link to comment Share on other sites More sharing options...
thesteveman Posted November 30, 2009 Report Share Posted November 30, 2009 .9kb download, 19.0 upload. Link to comment Share on other sites More sharing options...
rafi Posted November 30, 2009 Report Share Posted November 30, 2009 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 More sharing options...
maz125 Posted November 30, 2009 Report Share Posted November 30, 2009 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 More sharing options...
phoenix977 Posted December 3, 2009 Report Share Posted December 3, 2009 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 More sharing options...
Firon Posted December 3, 2009 Author Report Share Posted December 3, 2009 Set an upload cap and everything will work much better. Turn tcp_rate_control back on and set an upload cap. Link to comment Share on other sites More sharing options...
phoenix977 Posted December 4, 2009 Report Share Posted December 4, 2009 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 More sharing options...
twipley Posted December 5, 2009 Report Share Posted December 5, 2009 I am just curious as to if you were able to reproduce the bug I have talked about last week. Link to comment Share on other sites More sharing options...
Daetlus Posted December 5, 2009 Report Share Posted December 5, 2009 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 More sharing options...
rafi Posted December 5, 2009 Report Share Posted December 5, 2009 a uTorrent bug ? try pref->bittorrent->enable-bandwidth-management=unchecked. If that works - report back here to the devs, that the uTP speed-limit-control should be fixed to behave like the old one... Link to comment Share on other sites More sharing options...
Daetlus Posted December 5, 2009 Report Share Posted December 5, 2009 Had tried turning that off, before coming here. Same problem. Link to comment Share on other sites More sharing options...
rafi Posted December 5, 2009 Report Share Posted December 5, 2009 and lastly try: net.calc_overhead = flase as well... if that works - it's THE known/reported bug... Link to comment Share on other sites More sharing options...
Firon Posted December 6, 2009 Author Report Share Posted December 6, 2009 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 More sharing options...
rafi Posted December 6, 2009 Report Share Posted December 6, 2009 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 & numbers1) with the overhead2) w/o the overhead 3) both ? If you choose - 1 - people will ask about the non zero (overhead) display - like the DL when seedingif 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 More sharing options...
Switeck Posted December 6, 2009 Report Share Posted December 6, 2009 Daetlus,Extreme settings, local peers, DHT, and even overhead estimation can cause uTorrent to use more upload than it's allowed to use for uploading torrent parts to peers. Link to comment Share on other sites More sharing options...
vebero Posted December 8, 2009 Report Share Posted December 8, 2009 The help icon in settings window looks very pixelated. Link to comment Share on other sites More sharing options...
aloznogrog Posted December 8, 2009 Report Share Posted December 8, 2009 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 More sharing options...
Firon Posted December 8, 2009 Author Report Share Posted December 8, 2009 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.