µTorrent 2.0 released

[Greg Hazel]

Yes, those problems indicate issues with bt.tcp_rate_control, not uTP.

[Ondoy]

On #520, overhead is much more why call it to stable. I can't understand.

Maybe I'm not strong in English, Sorry for that.

[Greg Hazel]

So 17.5% is too high, but 9.5% is ok? Is 13.5% ok?

[Ondoy]

I mean utp design for maximize bandwidth, why it's overhead more than tcp which older.

I though utp will use bandwidth less than tcp and finished download quicker because it's use lesser overhead.

[Greg Hazel]

You're mixing a few concepts. uTP was designed for minimizing congestion, while still maximizing throughput. It does add some overhead, which we'll work to reduce. The effective rate of throughput minus overhead (sometimes called "goodput") is slightly reduced as a result, but this is a small price to pay for a more responsive network.

We're working on lowering the overhead, but outside of rafi's scary-looking graphs, you shouldn't have any serious problems with it.

[Ondoy]

I have no problem, just confuse and not see real benefit of utp when compare to tcp.

Again my English is weak.

[Greg Hazel]

The benefit is that you no longer need to set and upload rate limit in order to keep from overloading your internet connection. Anyone on the network can check email, browse the web, do whatever, and uTP will transfer as fast as possible without getting in the way.

[rafi]

"scary-looking" ? ... next time I'll put some smilies on them... it's just how reality looks, using highly precise state-of-the-art measurement tools... you should buy some for yourselves... ;P

And as for uTP changing your (Internet) life, and not limiting your upload - I like it. though - it takes two to tango... are you in contact with other clients' devs ? which one is working on it ?

[Greg Hazel]

I was referring to your red highlighting and bold formatting.

[Ondoy]

Hmm... I can get it. Just last one question what is tcp rate control how it work.

[Greg Hazel]

bt.tcp_rate_control was our attempt to slow down TCP based on the information we can learn from uTP connections. Where this fails is when the speed of uTP connections is tiny compared to the speed of the TCP connections we're limiting - in your case, the TCP connection is an ISP-level seed box, so there's no way normal uTP connections to other peers could go as fast.

We're working on improvements to this.

[rafi]

I was referring to your red highlighting and bold formatting.

Well, I tried my best to scare you there, but seems like I missed the red 8% improvement I expect ... at the least... ;P

[moogly]

bt.tcp_rate_control was our attempt to slow down TCP based on the information we can learn from uTP connections.

I imagine if a user set bt.transp_disposition=5 (only TCP traffic), the use of bt.tcp_rate_control is reduced to zero, isn't it?

[arvid]

I imagine if a user set bt.transp_disposition=5 (only TCP traffic), the use of bt.tcp_rate_control is reduced to zero, isn't it?

Yes, tcp_rate_control only kicks in when there is a significant number of uTP peers trying to upload (or download) stuff.

[rafi]

it is ALSO depended on bt.transp_disposition shows a mix of uTP and TCP (bits 1 or 4), right ? if both uTP bits 2 & 8 are 0 - it will not function too, right ?

[Firon]

tcp rate control will not work if there are no active uTP connections, or even just a few. So naturally, if uTP is disabled, then tcp rate control will not kick in.

And for your reference,

1 = outgoing TCP

2 = outgoing uTP

4 = incoming TCP

8 = incoming uTP

16 = new uTP header (2.0+ only)

255 = use everything (future-proof).

[GHammer]

So then, is a setting of 10 not the way to get utp only?

[Firon]

10 will do uTP only, yes.

26 will limit you to just 2.0 (and up) users.

[GHammer]

I've been using 10, but just to make clear.

26 or 16 as indicated in your reference post?

Thanks for an elegant app!

[Zarggg]

2 (uTP Out) + 8 (uTP In) + 16 (2.0+ Header) = 26

[rafi]

Firon wrote:

tcp rate control will not work if there are no active uTP connections

OK than. so it had no effect on my TCP-only or uTP-only tests here (bt.transp_disposition = 5/10):

http://forum.utorrent.com/viewtopic.php?pid=451492#p451492

(since it was 'true' at the time)

I have added more remarks/conclusions at the bottom there. My (educated...) guess - is that the extra DL overhead might be caused by the extra transactions/packets transferred in uTP due to smaller packets' size.

Also I have suggested some more statistics here:

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

[Auzl]

Sorry for making my first post here and not knowing much.

I just wanted to ask if it's okay to upgrade to 2.0, if I usually don't care much about configuring everything I can and if 1.8.5 has been working so well here. All these latest posts are making me not want to...

[rafi]

Yes it's OK. I use it... You can save/backup your uT 1.8 *.dat files and always go back if you really have to.

[Firon]

I use 2.0, it works pretty well for me.

[lusus]

Hi:

I use utorrent since some months ago, and I'm very happy with this software. Now I'm using 1.8.5.

I have a question about the option "Enable bandwidth management" in utorrent 2.0.

I will explain my case: I like to use always all the available bandwidth (250 KB/s) of my connection to upload on ed2k and BT networks. Normally emule is using nearly all the available bandwidth (250 KB/s) because utorrent is not uploading any files, but when utorrent is uploading "at the maximum" and emule is uploading "at the maximum" too, utorrent uses 2 / 3 of the upstream bandwidth (166-167 KB/s) and emule 1 / 3 (83-84 KB/s). I'm a user of private trackers with ratio limits, so I would like even that utorrent used more upload bandwidth when bot are uploading "at the maximum".

The ideal for me would be that, by setting higher limits both on emule and utorrent 250-260 KB/s (all upstream bandwidth), utorrent used almost 250 KB/s if needed, and, if not, emule used all the bandwidth to upload.

So, with utorrent 2.0, with "Enable bandwidth management" activated, would I upload at less speed when utorrent is in "competition" with emule? If it's not activated, would it be like in utorrent 1.8.5 (2/3 for utorrent, 1/3 for emule "in competition")?

Thanks