µTorrent 2.0 released

[kamen]

@moogly

i don't use firewall.

windows firewall is desable

[Greg Hazel]

Oh my gosh - you released it without fixing the problem the two 2.0 versions (exact build) can't connect to each other ("UNKNOWN" torrent bug).

See here:

http://www.mediafire.com/?ynhumzyebhk

On the right side you can see the incomming connection in the Logger tab.

This one is also reproducable in my testenvironment (I have 12 test PCs under my controll).

"Incoming connection for a.b.c.d:p for torrent 'UNKNOWN'" is a bug, but only in the log message. It says "UNKNOWN" because it can not possible know which torrent the incoming connection is for yet. So, it's completely harmless. What you see there is one uTorrent client connecting to itself, seeing its own ID and disconnecting. Also completely harmless.

The only thing which is concerning to me are the log lines that say "Disconnect: Invalid header". Can you tell me more about 10.0.2.2:12345? The machine on the right seems to be 10.0.2.15, with one client running on 23224. What IP and port is the other client on? Is it on the same machine? What is 10.0.2.2 then?

If they are different machines, please disable encryption and capture the traffic with Wireshark and post it somewhere for us to look at.

[rafi]

@Greg: "connecting to itself" ? why should it even try ? better keep it's own IP out of the peers list... if there are a quite a few torrents trying AND RE-TRYING to connect to themselves - it sounds like waist of bandwidth and might cause router issues/loops...

Regarding the other issue, I was trying to set transp_disposition to 10 or 26 (uTP) while having ONLY seeding tasks. I see some difficulty maintaining uTP connections for uploading. It feels like peers keep disconnecting, mainly if there is more then one peer connected and uploaded to, before gaining speed.

I guess it can be caused by local issues, like my ISP messing up with them...

[Greg Hazel]

@Greg: "connecting to itself" ? why should it even try ? better keep it's own IP out of the peers list... if there are a quite a few torrents trying AND RE-TRYING to connect to themselves - it sounds like waist of bandwidth and might cause router issues/loops...

Regarding the other issue, I was trying to set transp_disposition to 10 or 26 (uTP) while having ONLY seeding tasks. I see some difficulty maintaining uTP connections for uploading. It feels like peers keep disconnecting before gaining speed.

I guess it can be caused by local issues, like my ISP messing up with them...

uTorrent is not always aware of it's own IP. Once it connects to itself and discovers it, it does ban that IP to prevent future re-connections. This works unless the router already has a bug where it rewrites looped packets. In either case it's rarely a waste of bandwidth since the packets never make it to the internet, and the attempt is too infrequent for it to be significant on a LAN.

Your uTP issues are unrelated to the post I commented on.

[xaxax]

I've seen utorrent 2.0 peers in various torrents, so it seems to me like that bug was fixed.

[Fazuul]

I'm not getting a setup dialog with 2.0 stable, it simply launches utorrent.

[rafi]

@xaxax : did you manage to get more with then a single-concurrent 2.0 uTP seeding/uploading-only connection in uploading tasks/torrents (bt.transp_disposition =10/26) ? or you didn't try that at all .

Greg:

uTorrent is not always aware of it's own IP. Once it connects to itself and discovers it, it does ban that IP to prevent future re-connections. This works unless the router already has a bug where it rewrites looped packets. In either case it's rarely a waste of bandwidth since the packets never make it to the Internet, and the attempt is too infrequent for it to be significant on a LAN.

Your uTP issues are unrelated to the post I commented on.

well, you are welcome, then, to review the capture+screenshot+log , and find out why there are still UDP messages there in-spite of the auto-ban.

I'm not saying the uTP issue is related to the previous poster, or even that it's uT related. It might be just bad luck not seeing multiple concurrent 2.0 peers actively uploaded-to. As I said, it can very well be my ISP... or not...

Just an observation FYI/review.

http://www.mediafire.com/?znioqzznzoj (capture is filtered by own IP)

Edit:

Handling of UPD trackers' peers' count seems problematic (seeds count - seems ok) ... there is no corerlation between the peers numper displayed in the trackers' tab, and the one displayed in the main view.

It looks like when you "update" a udp tracker - the peers number is re-added to the global count . "clear peers list" - revert it to the correct count. It also seems like the total count just being increased randomly...

http://img16.imageshack.us/img16/8044/43364772.png

http://img12.imageshack.us/img12/4278/38407285.png

http://img222.imageshack.us/img222/671/90790721.png

http://img195.imageshack.us/img195/8425/69122807.png

[Greg Hazel]

well, you are welcome, then, to review the capture+screenshot+log , and find out why there are still UDP messages there in-spite of the auto-ban.

I'm not saying the uTP issue is related to the previous poster, or even that it's uT related. It might be just bad luck not seeing multiple concurrent 2.0 peers actively uploaded-to. As I said, it can very well be my ISP... or not...

Just an observation FYI/review.

(capture is filtered by own IP)

http://www.mediafire.com/?znioqzznzoj

I don't see a mention of the ban in your uT log. I also don't see a problem here. Wireshark says 192.168.2.3 is trying to communicate with 89.139.178.214 and it is not responding. So, it if can't connect to get the ID, it can't know that it is itself.

[SkyHi]

Seeding 6 torrents with 2.0 gives upload speed 70-90kb/s with up &downs.

Seeding the same torrents with 1.8.2 (still the best I think) gives my max upload speed of about 100-105kb/s almost flat.

Why?

[rafi]

Once it connects to itself and discovers it, it does ban that IP to prevent future re-

connections.

I though uT tries to detect it's public IP ...

I don't see a mention of the ban in your uT log. I also don't see a problem here. Wireshark says 192.168.2.3 is trying to communicate with 89.139.178.214 and it is not responding. So, it if can't connect to get the ID, it can't know that it is itself.

I don't see it either (89... is the router/public IP)... that is why I mentioned it... I believe that finding one's own public IP is a simple task by one of the many services available that uT can simply use (whatismyip etc) , at least optionally.

(PS: I edited my previous post with another issue)

[Greg Hazel]

I believe that finding one's own public IP is a simple task by one of the many services available that uT can simply use (whatismyip etc) , at least optionally.

There's no benefit to this. Either you can successfully connect to yourself and the ban occurs, or you can not and uT slows down how often it retries, and attempts other peers instead. Either way the traffic is not going across the internet, so there is no interesting wasted bandwidth. Consider the alternative of refusing to connect to a peer who is also behind your public IP.

[bugmenot2]

UTP seems totally useless to me, in fact it exhibits symptoms of exactly what it's supposed to solve.

That is congestion of my line to a point where it's not usable anymore.

I have ~10Mbit/s down- and ~85kB/s upstream, done some testing with utp only, mixed and I am now back at tcp only.

I capped my upload to 50kB/s this is the ping statistics to a host I have pretty much exactly 15ms latency to if my line is idle:

Approximate round trip times in milli-seconds:

Minimum = 41ms, Maximum = 67ms, Average = 52ms

Web browsing, SSH to my server etc. is still smooth.

With utp this goes in the upper 200-500ms with the occasional spike to 700 and more, even timeouts.

Funny thing is:

-upload in uT is slow

-download in uT is slow

And everything else pretty much grinds to a halt.

I tried bandwith management on/off, calc_overhead on/off (utp overhead is ridiculous btw if it's displayed correctly), lower settings for connect_speed... nothing helps.

So I guess my question is: what's killing my line if it's not the bandwidth (works fine with higher up/down in tcp mode)?

I already set a global max. of 120 connections, so unless utp disregards this setting I'm at a loss whats going on here or how this is supposed to be better or if it's just me?

[dajomas]

I wrote some tools that make use of the WEBAPI (yes token authentication is being used) and under version 1.8.5, they work like a charm but in version 2.0.0, I do get a token but calls to for instance the getprops or list functions give me an error 300 back.

Sadly, this means I have to revert back to version 1.8.5

Has something changed in the API or is this a bug. The weirdest thing is that the webui works just fine....

The problems I encounter happen with uTorrent 2.0.0 in combination with webui 0.362 and 0.370

Greetinx

Johan

[rafi]

bugmenot2

I have ~10Mbit/s down- and ~85kB/s upstream, done some testing with uTP only, mixed and I am now back at TCP only....(utp overhead is ridiculous btw.... )

Also, having a 2015:1 connection is rediculous... but you are right - uTP with >5% overhead will never work for you in full download capacity. uT should improve/reduce it ... And you better use external speed measurement tools, cause I think that uT speeds are not so accurate; try also to reduce your UL limit a bit .

[user9475]

xaxax, hang diagnostics were added sometime in 2.0's development process for when it detects that the GUI thread has hung (the window became unresponsive). It has been useful to solve various issues.

is there an option to disable this reporting/connecting to the utorrent server? I can forsee a FUD storm that's sure to arise once people start using 2.0 and noticing these connections in their logs.

[Firon]

Not a specific option. You'd probably have to disable check for updates.

UTP seems totally useless to me, in fact it exhibits symptoms of exactly what it's supposed to solve.

That is congestion of my line to a point where it's not usable anymore.

I have ~10Mbit/s down- and ~85kB/s upstream, done some testing with utp only, mixed and I am now back at tcp only.

I capped my upload to 50kB/s this is the ping statistics to a host I have pretty much exactly 15ms latency to if my line is idle:

Approximate round trip times in milli-seconds:

Minimum = 41ms, Maximum = 67ms, Average = 52ms

Web browsing, SSH to my server etc. is still smooth.

With utp this goes in the upper 200-500ms with the occasional spike to 700 and more, even timeouts.

Funny thing is:

-upload in uT is slow

-download in uT is slow

And everything else pretty much grinds to a halt.

I tried bandwith management on/off, calc_overhead on/off (utp overhead is ridiculous btw if it's displayed correctly), lower settings for connect_speed... nothing helps.

So I guess my question is: what's killing my line if it's not the bandwidth (works fine with higher up/down in tcp mode)?

I already set a global max. of 120 connections, so unless utp disregards this setting I'm at a loss whats going on here or how this is supposed to be better or if it's just me?

It's very possible your router doesn't like the extra UDP traffic.

[magao]

Also, having a 20:1 connection is rediculous [sic]

Actually, it's quite common here in Australia - I've got approx 20Mbps (sustained) download and 0.85Mbps sustained upload. ADSL and ADSL2+ are the primary forms of connection, and even cable users are artificially capped to similar down/up speeds. People usually only get better down:up ratios because they're further from the exchange and their download speed drops dramatically. I've got <1km of cable to the exchange, new wiring + central filter in my house and new ADSL2+ router, so I've pretty much got the best possible on ADSL2+.

The other option is that some ISPs offer Annex Mode M (if you're connected to their DSLAMS, and not Telstra's), which allows you to sacrifice some download bandwidth for upload. If you're lucky you might get to 2.5Mbps upload. I could really use the extra upload (since I work from home 3 days per week), but unfortunately whilst I'm with such an ISP (Internode), I have to use Telstra's DSLAM.

Anyway, I seem to be managing to download just fine - got 15Mbps down with uTorrent 1.8.5 the other day, and approx 8Mbps down with uTorrent 2.0 yesterday.

[endeavor]

...got 15Mbps down with uTorrent 1.8.5 the other day, and approx 8Mbps down with uTorrent 2.0 yesterday.

Was the download speed difference you got between uTorrent v1.8.5 & v2.0 because of uTorrent itself, or was it just because of your momentary downloading opportunity?

iow, are you saying that v2.0 can download faster than v1.85?

[uthappyuser]

rafi wrote:

Also, having a 15:1 connection is rediculous

Ridiculous? How is having what's available to you ridiculous? Should I tell my ISP to take away my download bandwidth so that you approve of their ratio? Your comment is ridiculous.

[Gimlei]

My speeds are going up and down with uT 2.0 if the "Enable bandwidth management" option is turned on. Seems to be connecting to a peer, uploading almost at max for a few seconds, then speed dropping to zero, peer disappearing from peer tab, after a minute or two this peer reappears and situation repeats. Pls see a more detailed post w/ screenshots in "Speed issues" section.

[magao]

I wasn't actually watching it (just checked the average) but its impossible to just look at two torrents and compare. The only reasonably valid way is to collect your maximum sustained speeds over a significant period of time and compare them. Individual torrents are luck of the draw (although if you've got a good i.e. non-Australian upload speed, you're more likely to get consistent performance).

Unfortunately, I'm not in a good position to do comparisons as I've made several changes recently - new ADSL2+ router, upgraded my server to Windows 7 (64-bit), upgraded to 2.0. I can say that with Windows 7 and the new router my speeds are definitely better, can't say anything about 1.8.5 vs 2.0.

Speaking of which - could be new hardware (just upgraded my main machine), could be software, but whereas with my E6300/XP machine I could get approx 400Mbps from my Windows 7 server, with my i7 860/Windows 7 machine I can get 900Mbps from my Windows 7 server i.e. I'm pretty much maxing out my internal 1Gbps network. Now the wait is on for consumer-level 10Gbps hardware ...

[xaxax]

@xaxax : did you manage to get more with then a single-concurrent 2.0 uTP seeding/uploading-only connection in uploading tasks/torrents (bt.transp_disposition =10/26) ? or you didn't try that at all .

I don't have a real test environment so can't really test that. I have bt.ransp_disposition set to 15 (default).

@uthappyuser and @magao, and others...

I think the rest of us are all just envious of your massive download bandwidth.

[Simon100]

I'm having erratic d/l speeds with uTorrent 2.0. I've switched back and forth between the latest 1.8.5 (17414) & 2.0 (17920). I've pulled the plug on my other computer and connect via wired, only computer connected is the uTorrent running computer. From my traffic graphs from my router, I see erratic up/down behavior. I disabled Bandwidth Management and it still is slow. I notice not many clients will connect with me. As soon as I run 1.8.5, MANY seeds & clients start uploading & downloading. Could it be uTP's fault, tryuing to prevent the saturation of my line? I've restricted my up/l to 80% of available bandwidth to allow plenty room for ack's to be sent. I've also tried it on a dd-wrt & also a Tomato router, and I get the same results.

I'm still not particularly familiar with the more Advanced features, but how or what settings should I set in order for uTorrent 2.0 (17920) to behave more like 1.8.5? I love the new look of 2.0 and the extra features as well, so I'm wondering if I can set it so that at night it would behave like 1.8.5 and consume/saturate my connection since no one will be interactively connected. In the daytime, I can let it manage bandwidth. In it's current form, it slows all the torrents down considerably on my ADSL line even when nothing else is running. Also I can let my router shape traffic if the need arises, right now my router does not handle any QoS shaping or filtering.

Any help would be GREATLY appreciated! Many Thanks!

Simon

[rafi]

possibly wrong uTP overhead calculation (bt.transp_disposition = 10) :

(from IRC: <alus> _rafi_: that seems to be an overhead difference )

[magao]

I think the rest of us are all just envious of your massive download bandwidth.

Wasn't long ago I had 10Mbps down/0.25Mbps up (on Optus cable) ... torrenting was somewhat difficult because it was so easy to saturate the upload with ACKs. I think the best I ever managed to download was about 400kBps (i.e. approx 3Mbps or 1/3 of my available). Now with the increased upload I can manage around 5 times the speed ...

In addition to the highly asymmetric down/up speeds here in Australia, we also have pretty restrictive quotas. I have 50GB/month, and then I'm shaped to 64kbps down and up - or I can buy additional data blocks. My ISP doesn't count uploads (except on one of its plans) but many other ISPs include all uploaded data in the quota as well.