µTorrent 2.0 released

[Step]

Hope it will help, my maximum speed is 512Kbit/s (for now) in both direction, but have troubles with bad line to provider

Here is log:

[2010-01-08 00:56:56]  uTP recv rate: 1624 setting TCP recv rate to: 138984 (min_receive_delay: 25ms diff: 1575 tcp/utp: 15/2)[2010-01-08 00:56:56]  No sending uTP connections.[2010-01-08 00:56:57]  uTP recv rate: 9005 setting TCP recv rate to: 139691 (min_receive_delay: 149ms diff: 707 tcp/utp: 15/2)[2010-01-08 00:56:58]  No sending uTP connections.[2010-01-08 00:56:58]  uTP recv rate: 0 setting TCP recv rate to: 141084 (min_receive_delay: 51ms diff: 1393 tcp/utp: 15/2)[2010-01-08 00:56:58]  No sending uTP connections.[2010-01-08 00:56:59]  uTP recv rate: 9448 setting TCP recv rate to: 142372 (min_receive_delay: 66ms diff: 1288 tcp/utp: 15/2)[2010-01-08 00:56:59]  No sending uTP connections.[2010-01-08 00:57:00]  uTP recv rate: 581 setting TCP recv rate to: 143660 (min_receive_delay: 66ms diff: 1288 tcp/utp: 15/2)[2010-01-08 00:57:00]  No sending uTP connections.[2010-01-08 00:57:01]  uTP recv rate: 25098 setting TCP recv rate to: 144423 (min_receive_delay: 141ms diff: 763 tcp/utp: 15/2)[2010-01-08 00:57:01]  No sending uTP connections.[2010-01-08 00:57:02]  uTP recv rate: 3197 setting TCP recv rate to: 144773 (min_receive_delay: 200ms diff: 350 tcp/utp: 15/2)[2010-01-08 00:57:02]  No sending uTP connections.[2010-01-08 00:57:03]  uTP recv rate: 436 setting TCP recv rate to: 145900 (min_receive_delay: 89ms diff: 1127 tcp/utp: 15/2)[2010-01-08 00:57:03]  No sending uTP connections.[2010-01-08 00:57:04]  uTP recv rate: 581 setting TCP recv rate to: 147608 (min_receive_delay: 6ms diff: 1708 tcp/utp: 16/2)[2010-01-08 00:57:04]  No sending uTP connections.[2010-01-08 00:57:05]  uTP recv rate: 14616 setting TCP recv rate to: 149309 (min_receive_delay: 7ms diff: 1701 tcp/utp: 16/2)[2010-01-08 00:57:05]  No sending uTP connections.[2010-01-08 00:57:06]  uTP recv rate: 9738 setting TCP recv rate to: 150261 (min_receive_delay: 114ms diff: 952 tcp/utp: 16/2)[2010-01-08 00:57:06]  No sending uTP connections.[2010-01-08 00:57:07]  uTP recv rate: 290 setting TCP recv rate to: 151626 (min_receive_delay: 55ms diff: 1365 tcp/utp: 16/2)[2010-01-08 00:57:07]  No sending uTP connections.[2010-01-08 00:57:08]  uTP recv rate: 23110 setting TCP recv rate to: 153334 (min_receive_delay: 6ms diff: 1708 tcp/utp: 16/2)[2010-01-08 00:57:08]  No sending uTP connections.[2010-01-08 00:57:09]  uTP recv rate: 6110 setting TCP recv rate to: 153355 (min_receive_delay: 247ms diff: 21 tcp/utp: 16/2)[2010-01-08 00:57:09]  No sending uTP connections.[2010-01-08 00:57:10]  uTP recv rate: 2066 setting TCP recv rate to: 154118 (min_receive_delay: 141ms diff: 763 tcp/utp: 16/2)[2010-01-08 00:57:10]  No sending uTP connections.[2010-01-08 00:57:11]  uTP recv rate: 436 setting TCP recv rate to: 155315 (min_receive_delay: 79ms diff: 1197 tcp/utp: 16/2)[2010-01-08 00:57:11]  No sending uTP connections.[2010-01-08 00:57:12]  uTP recv rate: 1453 setting TCP recv rate to: 156351 (min_receive_delay: 102ms diff: 1036 tcp/utp: 16/2)[2010-01-08 00:57:12]  No sending uTP connections.[2010-01-08 00:57:13]  uTP recv rate: 2509 setting TCP recv rate to: 157996 (min_receive_delay: 15ms diff: 1645 tcp/utp: 16/2)[2010-01-08 00:57:13]  No sending uTP connections.[2010-01-08 00:57:14]  uTP recv rate: 2182 setting TCP recv rate to: 158745 (min_receive_delay: 143ms diff: 749 tcp/utp: 16/2)[2010-01-08 00:57:14]  No sending uTP connections.[2010-01-08 00:57:15]  uTP recv rate: 1312 setting TCP recv rate to: 159494 (min_receive_delay: 143ms diff: 749 tcp/utp: 16/2)[2010-01-08 00:57:15]  No sending uTP connections.[2010-01-08 00:57:16]  uTP recv rate: 21407 setting TCP recv rate to: 161223 (min_receive_delay: 3ms diff: 1729 tcp/utp: 16/2)[2010-01-08 00:57:16]  No sending uTP connections.[2010-01-08 00:57:17]  uTP recv rate: 2657 setting TCP recv rate to: 162952 (min_receive_delay: 3ms diff: 1729 tcp/utp: 16/2)[2010-01-08 00:57:17]  No sending uTP connections.[2010-01-08 00:57:18]  uTP recv rate: 442 setting TCP recv rate to: 164023 (min_receive_delay: 97ms diff: 1071 tcp/utp: 16/2)[2010-01-08 00:57:18]  No sending uTP connections.[2010-01-08 00:57:19]  uTP recv rate: 9891 setting TCP recv rate to: 164527 (min_receive_delay: 178ms diff: 504 tcp/utp: 16/2)[2010-01-08 00:57:19]  No sending uTP connections.[2010-01-08 00:57:20]  uTP recv rate: 9747 setting TCP recv rate to: 165409 (min_receive_delay: 124ms diff: 882 tcp/utp: 17/2)[2010-01-08 00:57:20]  No sending uTP connections.[2010-01-08 00:57:21]  uTP recv rate: 15649 setting TCP recv rate to: 166662 (min_receive_delay: 71ms diff: 1253 tcp/utp: 17/2)[2010-01-08 00:57:21]  No sending uTP connections.[2010-01-08 00:57:22]  uTP recv rate: 0 setting TCP recv rate to: 168307 (min_receive_delay: 15ms diff: 1645 tcp/utp: 17/2)[2010-01-08 00:57:22]  No sending uTP connections.[2010-01-08 00:57:23]  uTP recv rate: 145 setting TCP recv rate to: 169840 (min_receive_delay: 31ms diff: 1533 tcp/utp: 17/2)[2010-01-08 00:57:23]  No sending uTP connections.[2010-01-08 00:57:24]  uTP recv rate: 24442 setting TCP recv rate to: 171338 (min_receive_delay: 36ms diff: 1498 tcp/utp: 17/2)[2010-01-08 00:57:24]  No sending uTP connections.[2010-01-08 00:57:25]  uTP recv rate: 0 setting TCP recv rate to: 172906 (min_receive_delay: 26ms diff: 1568 tcp/utp: 17/2)[2010-01-08 00:57:25]  No sending uTP connections.[2010-01-08 00:57:26]  uTP recv rate: 147 setting TCP recv rate to: 173760 (min_receive_delay: 128ms diff: 854 tcp/utp: 17/2)[2010-01-08 00:57:26]  No sending uTP connections.[2010-01-08 00:57:27]  uTP recv rate: 24442 setting TCP recv rate to: 175405 (min_receive_delay: 15ms diff: 1645 tcp/utp: 17/2)[2010-01-08 00:57:27]  No sending uTP connections.[2010-01-08 00:57:28]  uTP recv rate: 147 setting TCP recv rate to: 176588 (min_receive_delay: 81ms diff: 1183 tcp/utp: 17/2)[2010-01-08 00:57:28]  No sending uTP connections.[2010-01-08 00:57:29]  uTP recv rate: 8139 setting TCP recv rate to: 177344 (min_receive_delay: 142ms diff: 756 tcp/utp: 17/2)[2010-01-08 00:57:29]  No sending uTP connections.[2010-01-08 00:57:30]  uTP recv rate: 145 setting TCP recv rate to: 178100 (min_receive_delay: 142ms diff: 756 tcp/utp: 17/2)[2010-01-08 00:57:30]  No sending uTP connections.[2010-01-08 00:57:31]  uTP recv rate: 19629 setting TCP recv rate to: 178856 (min_receive_delay: 142ms diff: 756 tcp/utp: 17/1)[2010-01-08 00:57:31]  No sending uTP connections.[2010-01-08 00:57:32]  uTP recv rate: 147 setting TCP recv rate to: 179507 (min_receive_delay: 157ms diff: 651 tcp/utp: 17/1)[2010-01-08 00:57:32]  No sending uTP connections.[2010-01-08 00:57:33]  uTP recv rate: 0 setting TCP recv rate to: 180158 (min_receive_delay: 157ms diff: 651 tcp/utp: 17/1)[2010-01-08 00:57:33]  No sending uTP connections.[2010-01-08 00:57:34]  uTP recv rate: 145 setting TCP recv rate to: 180893 (min_receive_delay: 145ms diff: 735 tcp/utp: 17/1)[2010-01-08 00:57:34]  No sending uTP connections.[2010-01-08 00:57:35]  uTP recv rate: 0 setting TCP recv rate to: 181628 (min_receive_delay: 145ms diff: 735 tcp/utp: 17/1)[2010-01-08 00:57:35]  No sending uTP connections.[2010-01-08 00:57:36]  uTP recv rate: 145 setting TCP recv rate to: 182363 (min_receive_delay: 145ms diff: 735 tcp/utp: 17/1)[2010-01-08 00:57:36]  No sending uTP connections.[2010-01-08 00:57:37]  uTP recv rate: 0 setting TCP recv rate to: 183098 (min_receive_delay: 145ms diff: 735 tcp/utp: 17/1)[2010-01-08 00:57:37]  No sending uTP connections.[2010-01-08 00:57:38]  uTP recv rate: 147 setting TCP recv rate to: 183833 (min_receive_delay: 145ms diff: 735 tcp/utp: 16/1)[2010-01-08 00:57:38]  No sending uTP connections.[2010-01-08 00:57:39]  uTP recv rate: 0 setting TCP recv rate to: 184568 (min_receive_delay: 145ms diff: 735 tcp/utp: 16/1)[2010-01-08 00:57:39]  No sending uTP connections.[2010-01-08 00:57:40]  uTP recv rate: 145 setting TCP recv rate to: 185289 (min_receive_delay: 147ms diff: 721 tcp/utp: 15/1)[2010-01-08 00:57:40]  No sending uTP connections.[2010-01-08 00:57:41]  uTP recv rate: 0 setting TCP recv rate to: 186010 (min_receive_delay: 147ms diff: 721 tcp/utp: 15/1)[2010-01-08 00:57:41]  No sending uTP connections.[2010-01-08 00:57:42]  uTP recv rate: 147 setting TCP recv rate to: 186731 (min_receive_delay: 147ms diff: 721 tcp/utp: 15/1)[2010-01-08 00:57:42]  No sending uTP connections.[2010-01-08 00:57:43]  uTP recv rate: 0 setting TCP recv rate to: 187452 (min_receive_delay: 147ms diff: 721 tcp/utp: 15/1)[2010-01-08 00:57:43]  No sending uTP connections.[2010-01-08 00:57:44]  uTP recv rate: 145 setting TCP recv rate to: 188257 (min_receive_delay: 135ms diff: 805 tcp/utp: 15/1)[2010-01-08 00:57:44]  No sending uTP connections.[2010-01-08 00:57:45]  uTP recv rate: 0 setting TCP recv rate to: 189062 (min_receive_delay: 135ms diff: 805 tcp/utp: 15/1)[2010-01-08 00:57:45]  No sending uTP connections.[2010-01-08 00:57:46]  uTP recv rate: 65 setting TCP recv rate to: 189867 (min_receive_delay: 135ms diff: 805 tcp/utp: 15/1)[2010-01-08 00:57:46]  No sending uTP connections.[2010-01-08 00:57:47]  uTP recv rate: 290 setting TCP recv rate to: 190994 (min_receive_delay: 89ms diff: 1127 tcp/utp: 15/1)[2010-01-08 00:57:47]  No sending uTP connections.[2010-01-08 00:57:48]  uTP recv rate: 1181 setting TCP recv rate to: 191813 (min_receive_delay: 133ms diff: 819 tcp/utp: 15/1)[2010-01-08 00:57:48]  No sending uTP connections.

screenshot of uTorrent:

and speedtest.net results:

[Firon]

You're maxing out your connection. There is no problem here.

[Fadeout]

This is to prove I'm not lying. Done with the udp test build in the last page:

[2010-01-08 02:53:21]  No sending uTP connections.[2010-01-08 02:53:24]  uTP recv rate: 182738 setting TCP recv rate to: 4610296 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20)[2010-01-08 02:53:24]  No sending uTP connections.[2010-01-08 02:53:25]  uTP recv rate: 36712 setting TCP recv rate to: 4612039 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20)[2010-01-08 02:53:25]  No sending uTP connections.[2010-01-08 02:53:26]  uTP recv rate: 95599 setting TCP recv rate to: 4613782 (min_receive_delay: 1ms diff: 1743 tcp/utp: 97/20)[2010-01-08 02:53:26]  No sending uTP connections.[2010-01-08 02:53:27]  uTP recv rate: 93628 setting TCP recv rate to: 4615525 (min_receive_delay: 1ms diff: 1743 tcp/utp: 96/20)[2010-01-08 02:53:27]  No sending uTP connections.[2010-01-08 02:53:28]  uTP recv rate: 169761 setting TCP recv rate to: 4617268 (min_receive_delay: 1ms diff: 1743 tcp/utp: 98/20)[2010-01-08 02:53:28]  No sending uTP connections.[2010-01-08 02:53:29]  uTP recv rate: 130318 setting TCP recv rate to: 4619011 (min_receive_delay: 1ms diff: 1743 tcp/utp: 99/20)[2010-01-08 02:53:29]  No sending uTP connections.[2010-01-08 02:53:30]  uTP recv rate: 71825 setting TCP recv rate to: 4620740 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20)[2010-01-08 02:53:30]  No sending uTP connections.[2010-01-08 02:53:31]  uTP recv rate: 166866 setting TCP recv rate to: 4622476 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20)[2010-01-08 02:53:31]  No sending uTP connections.[2010-01-08 02:53:32]  uTP recv rate: 121539 setting TCP recv rate to: 4624205 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20)[2010-01-08 02:53:32]  No sending uTP connections.[2010-01-08 02:53:33]  uTP recv rate: 151166 setting TCP recv rate to: 4625934 (min_receive_delay: 3ms diff: 1729 tcp/utp: 99/20)[2010-01-08 02:53:33]  No sending uTP connections.[2010-01-08 02:53:34]  uTP recv rate: 93895 setting TCP recv rate to: 4627670 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20)[2010-01-08 02:53:34]  No sending uTP connections.[2010-01-08 02:53:35]  uTP recv rate: 168245 setting TCP recv rate to: 4629406 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/20)[2010-01-08 02:53:35]  No sending uTP connections.[2010-01-08 02:53:36]  uTP recv rate: 178124 setting TCP recv rate to: 4631142 (min_receive_delay: 2ms diff: 1736 tcp/utp: 99/19)[2010-01-08 02:53:36]  No sending uTP connections.[2010-01-08 02:53:37]  uTP recv rate: 97705 setting TCP recv rate to: 4632878 (min_receive_delay: 2ms diff: 1736 tcp/utp: 97/19)[2010-01-08 02:53:37]  No sending uTP connections.[2010-01-08 02:53:38]  uTP recv rate: 171582 setting TCP recv rate to: 4634607 (min_receive_delay: 3ms diff: 1729 tcp/utp: 97/19)

[Switeck]

Fadeout, that's with net.calc_overhead set to false?!

[rafi]

fadeout: looks familiar to me... next time, fadeout, include the download as well (I estimate it to be ~800K)... and it's more likely cacl_overhead is set to true, Switeck. Thus the effort to take overhead into account toward the limit .

http://img686.imageshack.us/img686/5090/75065638.png

Edit:

And another issue - I suggest to improve the speed-graph so to avoid confusion and questions related to breaking of the limit by overhead. Here is my suggestion: http://forum.utorrent.com/viewtopic.php?pid=444873#p444873

Feel free to comment over there or here ...

[arvid]

So, how about providing an option to include overhead INSIDE the limit ?

That's what we're trying to do. As a matter of fact, I just found the bug that has been causing these problems, so this will definitely be fixed in the next RC. (Obviously it's not considered fixed until you guys sign off, so stay tuned for the next release).

[Anonymous1]

Help file cant be downloaded properly

It download only utorrent-help.zip [169 bytes]

EDIT

updating help file to newest uT 2.0 will be nice too

[Firon]

Yeah, I know. RC2 hits the wrong URL. This will be fixed in RC3.

[flak]

Upgrading from RC1 to RC2 seems to have produced a weird phenomenon for me with regards to the uTP protocol.

Whereas previously with bandwidth management enabled connections seemed to favour uTP over TCP (bt.transp_disposition set to 15) and worked a treat, RC2 appears to do the opposite after a period of time. The effect for me is being connected to 80 -90% of peers on TCP with download and upload speeds reduced to a crawl. Restarting UT solves the problem, albeit temporarily.

Setting net.calc_overhead to false helps a little but not much.

Isn't uTP prioritised as a rule of thumb or is it just a crap shoot?

[rafi]

Firon:

Yeah, I know. RC2 hits the wrong URL. This will be fixed in RC3.

What should be the help file name, format and location for uTorrent to open it correctly with F1 ? Whatever I've tried didn't work...

and @flak: as I remember - it tries connecting with uTP first and only if unsuccessful - tried with TCP. And I hope it does that only with uT peers V1.83+ ...

[Ultima]

http://forum.utorrent.com/viewtopic.php?id=63408

It tries them simultaneously, and whichever one gets responded to first gets established first. If uTP is accepted after TCP, it is prioritized, so the TCP connection is dropped in favor of uTP.

[rafi]

my bad, though I don't see any point to try both with a client the couldn't possibly support it.. just waste of bytes... and who knows, he might even ban you ...

[Ultima]

See the quote in the thread:

[20:05:46] <&alus> connecting doesn't eat significant bandwidth

It wastes more time to wait to try serially and wait for fallbacks to occur. And why would the peer ban? If the peer doesn't understand uTP, it can simply (and in all likelihood, would) ignore the UDP packet. If it does understand uTP, it should understand that this was an attempt to establish uTP connection over TCP.

[rafi]

I didn't suggest to send one request and then wait and send another one (conditionally, delayed). I suggested to check the peer's client ID first (a less CPU/com intensive, an if statement) before sending a second redundant message to a non uT client. I always prefer the less intensive and simpler task . Even if it does not load your connection. Don't forget - a router might be involved here as well (with it's own connections' timeouts and max limit).

And alus is not always right you know...

[Ultima]

That doesn't make any sense on various different counts.

[ul][li]Why should µTorrent not request uTP connections for non-µTorrent clients? uTP is going to be a standard protocol extension that any client can support.

[/li][li]Comparing peer ID? That's already assuming you connected to the peer via TCP -- how else would you know what the peer's ID is? So by extension, you are advocating serial connection attempts, first using TCP, then trying uTP.

[/li][li]Doing extra checks in the extension header wastes as much -- if not more -- bandwidth just to find out if the peer supports uTP.

[/li][/ul]

So uh, no. If the peer doesn't support uTP, it's as simple as throwing away that UDP packet.

[rafi]

I though the peer's client Id is known from the tracker/DHT scrape/lists or PEX. If not - you are right...

[Ultima]

The only things sent in the peer lists are the peers' IP:port combinations. But again, even if client IDs were sent with the peer list, it isn't a viable solution because uTP isn't planned to be µTorrent-exclusive.

[flak]

This

If uTP is accepted after TCP, it is prioritized, so the TCP connection is dropped in favor of uTP.

and

So uh, no. If the peer doesn't support uTP, it's as simple as throwing away that UDP packet.

...which is what I thought.

And yet I am certain that RC2 (in my case) is prioritising TCP over uTP and not the other way round. For example, peers that I am connected to begin with uTP but after time revert to TCP on the same torrent, say, after a tracker update. The IP address of the peer is unchanged, as is the port. The vast majority are on UT 1.83+ as well. Stop and restart torrents and/or uTorrent and the connection to those same peers reuses uTP once again. So unless uTP is being disabled 'in situ' this shouldn't be happening, right?

Is it possible to be choked by uTP connections thus forcing a switch to TCP? Perhaps that is why stopping/restarting UT eradicates this problem temporarily, even if RC1 worked fine?

[osm0sis]

I figured out my problem with magnet association not sticking. Using a clean install of Windows 7 and uTorrent, it doesn't mess up (ie. all stay associated after install) until I put maindoc.ico into %AppData%\uTorrent. After that icon file goes in all associations need to be redone and uTorrent simply can't redo the magnet one for some reason. Removing maindoc.ico allows it to reassociate correctly with magnet links again. Any chance of seeing this longstander fixed?

[syfer]

Hi what is Enable bandwidth management and do i need it on?

[Step]

Yesterday, when downloading torrent, chart speed was a sawtooth shape, uTP was enabled and torrent had 1 uTP client (other 19 is non uTP), setting bt.transp_disposition to 5 or bt.tcp_rate_control to false gave a smooth graph and vice versa, is it normal?

[Switeck]

flak,

What you're seeing is an artifact of uTP connection failures and high reconnect rates by other clients. Your end first establishes an outgoing uTP connection to them...at some point it gets disrupted/fails/breaks/etc. Then the other end makes an outgoing connection to you, using of course regular TCP instead of uTP...because they're NOT set up to make outgoing uTP connections.

[TheLeechKing]

When trying torrents with large numbers of seeds/peers this build seems to lag the internet connection to the point where browsing is impossible, even when utorrent is downloading/uploading at speeds >20kb/s

On such torrents it fails to ever get to my top speed (120kb/s), instead it varies wildly around the 3-20kb/s area. If connected to the torrent for long enough, it may periodically shoot up to 60-90kb/s, but this only lasts for a few seconds before it's back to 3-20kb/s.

On well seeded torrents with a lower number of peers, the client works perfectly and gets up to top speed within a few seconds.

Not sure why this is happening. Is it trying to connect to too many peers at once? (I have the global max connections set to 400 and the upload slots set to 5)

[ShAQ]

Is there a solution available for the problem that you are unable to upload torrents via webui (linux/wine) and that two identical utorrent 2.0 rc2 (latest) won't connect to each other?

If needed I can't reproduce this behaviour in our testfarm (3-12 pcs).

[DreadWingKnight]

Stop using the 0.361 webui and start using the 0.362 dev webui.