Archived

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

Firon

µTorrent 1.9 alpha 15380

Recommended Posts

How to enable and disable it:

Preferences > Advanced, set bt.transp_disposition to:

255 - both TCP and uTP (default)

10 - uTP only

5 - TCP only

does this control work with 1.8.1 ? what does "0" value do i?

Share this post


Link to post
Share on other sites

Hey guys, I just checked this beta out and already see a tremendous impact on my bandwidth. I have I am downloading from binary newsgroups at nearly 90% speed with uTorrent 1.9 build 13485 chugging along seeding at about 70% of my upload capacity. Before, on the previous versions it seemed as if the dual between David and Goliath ensued when both apps were running side by side. In the past, a slightly used uplink created a bad download rate, like a simple drip creating a ripple that turned into a wave. I get best of both worlds now, I'm seeding while I'm downloading from another place at nearly full speed ... a fair compromise.

I'll do more comparitive analysis later, now I go to watch my pRon.

Share this post


Link to post
Share on other sites

@Mojo: you can't use TCP up- and download like that without Traffic Shaping. Your TCP-ACK's will het delayed by the upload-traffic, hence you need to prioritize those. That you can use 90% download and 90% upload among different apps simultanously.

Share this post


Link to post
Share on other sites

Today I found the µTorrent-alpha-news and changelog. I thought the µTorrent development was stalled, but it seems still alive. Actually I'm one of those persons who say, µTorrent is complete, please provide bugfixes only. However such improvements are very welcome. If it wasn't for 1.8, 1.9 is telling me Bram Cohen knew what he did. µTorrent is in excellent hands. Good job devs.

Nice changelog btw, I love the short explanation thanks.

*Waves and starts reading wikipedia "UDP hole punching" article*

Share this post


Link to post
Share on other sites

@TG: It's called queued seed, and it's behaving exactly as should be expected. queue.dont_count_slow_ul is doing its job by starting previously queued torrents.

Share this post


Link to post
Share on other sites

Wow this is awesome. Prevents my sandvine using isp from throttling.. full u/l speed to fellow [utp] peers. Ain't seen that in over a year. (i noticed bittorrent 6.1.1 clients w/ utp too.)

Share this post


Link to post
Share on other sites
How to enable and disable it:

Preferences > Advanced, set bt.transp_disposition to:

255 - both TCP and uTP (default)

10 - uTP only

5 - TCP only

does this control work with 1.8.1 ? what does "0" value do i?

0 turns it off on 1.8.1 (accepts uTP, but won't make any connections on its own). I don't know if the other values will work, you can try it.

Share this post


Link to post
Share on other sites

Never mind about my previous post, everything works all right with build 13485.

I had 100% CPU load on 13520.

Share this post


Link to post
Share on other sites

That crash has already been reported, and alus has stated that it's been fixed -- all in the first page. Do read the thread, please?

Share this post


Link to post
Share on other sites

this is nice to see a new protocol implemented -- I like to see new technology being developed.

the only problem I ever experienced with uTorrent (should still be in v1.9) is the "downloaded" column in the trackers tab. the torrents I'm downloading show multiple trackers, and sometimes in some torrent the three trackers report the same values, e.g. 1343, and some minutes after, I press update on each of them and the number has gotten down to 342 or up to a few thousands. most often, though, the three values are different from each other, and with the tests I've done it seems that the "real" value is shown maybe one fourth of the times.

someone ever heard about that? maybe a separate thread should be created for that issue, but given this thread is about new releases how about suggestions be made inside this very one? /2 cents

Share this post


Link to post
Share on other sites

@ Ultima, I have not set the queue on it though, nothing should be queuing... it didnt on 1.8.1 it went green straight away.

Share this post


Link to post
Share on other sites

@TG: What do you mean you haven't "set the queue on it"? If you never stop a torrent, it's considered as part of the queue. There is nothing else to it. That you've never seen it happen is just coincidence, because it's always done it here (and again, it's perfectly expected when queue.dont_count_slow_ul is taken into account).

Edit: Or am I misinterpreting something? Is it going from gray to green?

Share this post


Link to post
Share on other sites

I'm experiencing a strange thing with 13485 and 13521 build also.. I have a connection monitor application that monitors all my network activities and utorrent shows way lower down and upload rates! for example I see that my full upload bandwith is taken (400k) but utorrent shows 20-40k !!! in download it shows like half of the real thing in average, I did the client reset thing (deleted settings.dat then re config the client) so far I see that if the client does not detect its own traffic correctly then trackers will take that false result meaning that I1m uploading without any normal result! Please fix this issue! At these tests I had ONLY Utorrent running!

Share this post


Link to post
Share on other sites

Maybe so but its impossible for that to cause what I said as a bug as it was no problem in the past versions 1.8x

I think I1ll try to disable the uTP protocol and see if thats the problem or the bug is more serious.

Update: it seems that now the speeds are right however it is also clear that whatever encryption is being used by utorrent it's NOT working!! my ISP still can limit me! I don't know how "Halite" client makers do their encryption but that WORKS (I think it has two modes plaintext and rc4 and it uses both but i don't know witch one of them are best as I red rc4 is better but uses more cpu), but the whole client is crap in usage. So the speed display bug is caused by the new protocol in utorrent that's for sure. And now I know that my ISP only limits TCP or maybe UTP but it does not have a clue about this new uTP (yet).

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.