uTorrent 2.0.1 vs 1.8.5 - Speed

[Oneinunity]

Yay, am I glad that I followed this thread and others that mention to disable net.calc_overhead as a last resort. Contrary to 2.0.1, the new 2.0.2 I downloaded today tried to adjust my payload to the upload limit instead of the total load. I could therefore only get it to work fairly well if I lowered the limit to 60 kB/s instead of the recommended 90 kB/s. So I went through all the recommended tweaks without any result, and as part of it I checked net.calc_overhead and it was already set to false, as the default setting. Finally I set it to true and it immediately solved everything. The upload limit could be set back to 90 kB/s and it behaves again like 2.0.1 did, but smoother, with less fluctuations on the BWMeter. So this is actually the opposite as what some others experienced. But anyway, it works fine now. Is net.calc_overhead really disabled in the default 2.0.2 configuration?

Only that uTP overhead... 30 to 50% overhead? The developers better find a real solution fast, for this is not going to make the protocol very popular. Seems it is only used by µTorrent anyway...

[rafi]

But anyway, it works fine now. Is net.calc_overhead really disabled in the default 2.0.2 configuration?

Unfortunately, yes (see the change-log). Some people couldn't do the simplest thing you did - increase their UL limit, so the devs wanted to help them out ...

Only that uTP overhead... The developers better find a real solution fast

I fully agree. My examples/posts are all over the forums. Unfortunately (again...) the devs disagree, and look at it as a small price to pay for better congestion control

For now, you can use some of my tips to try and reduce it...

Seems it is only used by µTorrent anyway...

For now, and uT is ~50% of the world's BT clients. The are planning to provide open-source for uTP to others.

[Oneinunity]

"But anyway, it works fine now. Is net.calc_overhead really disabled in the default 2.0.2 configuration?

Unfortunately, yes (see the change-log). Some people couldn't do the simplest thing you did - increase their UL limit, so the devs wanted to help them out ... sad"

(sorry, got no idea how to get a proper quote box on this forum)

Well, then the devs have a problem. I think the solution will prove worse than the disease, because the speed wizard still supposes it is enabled, resulting in far too high settings. Now the people will have to set it to roughly 60% or less to get it to work somewhat. And I actually came to this forum because of that problem. It is then no longer possible to find an upload limit that is optimal under all circumstances. But everyone will start off with too high upload limits now.

"...a small price to pay for better congestion control"

I think it will only increase what I see already happening anyway. Seeders in particular will prefer other clients. If they all seed 20% faster the choice is not hard. Greed will win over internet awareness.

[rafi]

I'm not sure I understood why you think that setting a high UL limit will not work also when calc_overhead is false, and under what conditions - seeding ? downloading ?

I think it will work for most people, that have a 1:6 connection or better. People with less upload than that - yes, in some cases, they will get capped during high speed download, when overhead will get near their own ISP UL limit, and they'll have to reduce the uT limit. Still, they can provision a second limit for when they do not download.

Don't get me wrong, I think calc_overhead = true is a better choice... but it has it's issues too...

oh, and - 'quote' is explain here ...

[Oneinunity]

I'm not sure I understood why you think that setting a high UL limit will not work also when calc_overhead is false, and under what conditions - seeding ? downloading ?

I'm sorry, I was not very clear in my explanation.

First a bit of background. I'm running Windows 7 Ultimate and I've been using µTorrent for about 3 years. Usually the latest stable version, although lately I had upgraded to the 2.0.1 Beta. Download bandwidth is 8 Mb/s (1 MB/s), upload 1 Mb/s (128 kB/s). The speed wizard recommends 90 kB/s UL and I was using this limit without any troubles (except high overhead, particularly when downloading) in 2.0.1 and below. I never experienced any troubles of the kind that your forum posts are usually about. I used the speed wizard and set µTorrent to its outcome. Or lower, as the case may be, (there are other computers in the network using Skype for high quality video calls) without it causing problems. Advanced settings at their default values, so net.calc_overhead was switched on.

At the time of the upgrade to 2.0.2 I was heavily downloading. After the upgrade µTorrent started choking the internet, including its own downloads. When I checked what was happening it became clear that µTorrent was trying to make the payload equal to the UL limit of 90 kB/s. This 90 kB/s is the recommended TOTAL upload, including overhead. So it was no miracle that it choked the internet. I could get it to work by dramatically lowering my UL limit (to 60 kB/s or lower)

which was not very satisfactory, considering my former UL payload, roughly between 65 and 85 kB/s, depending on overhead.

So then I found out that net.calc_overhead was switched off. After switching it back on I could raise my UL limit back to 90 kB/s and everything was back to normal. In the mean time I have lowered it to 80 kB/s to provide a bit more headroom for other applications and other computers in the network and that does not cause a problem either. So I was expressing my concern that I would not be the only one experiencing a choked internet connection after upgrading to 2.0.2, only because net.calc_overhead has been set to false in this revision. It makes things worse.

Meanwhile I have no more problems with this revision at all. The high upload overhead is mainly due to download uTP traffic and I indeed consider it a small price for a better internet, for the moment. uTP itself seems to work like a charm, indeed a lot better than before. Still, if ways could be found to decrease the number of download ACK's while keeping the same performance that would be most welcome of course.

To summarize: I think switching off net.calc_overhead in 2.0.2 was a bad and unnecessary move that made things worse for a lot of people. And I advise anyone experiencing troubles with a choking internet connection to set net.calc_overhead back to true and enjoy a better client.

[rafi]

To summarize: I think switching off net.calc_overhead in 2.0.2 was a bad and unnecessary move that made things worse for a lot of people. And I advise anyone experiencing troubles with a choking internet connection to set net.calc_overhead back to true and enjoy a better client.

I can only second that... I know the devs think so too, but since there was no mention of this change or any instructions for upgraders to conpensate the limit, they folded under the "pressure" of those posters that did not understand what was going on, and thus the reduced speed. My conclusion - you have to do the upgrade wisely to get the result you want. Too bad