bt.tcp_rate_control slows download speed a lot

[svalentin]

Hy, just reporting a problem I found out when I upgraded from 1.8.5 to 2.0:

With utorrent 1.8.5 I was easily downloading with speeds >8MB/s. When I upgraded to 2.0, I couldn't even go beyond 1MB/s on the same torrent. When I set bt.tcp_rate_control to false, my download speed blasted off from 500KB/s to 7MB/s and 5 seconds later to 10.2MB/s (100mbps cable limit).

I read somewhere that "bt.tcp_rate_control: Enabling this option tells µTorrent to use information from the uTP transport as hints for limiting TCP transfer rates."

I don't know how bt.tcp_rate_control is implemented, but it is not working properly when you don't have any caps or limits set.

I can't set a download speed limit because my speed varies depending from whom I download. From peers outside my country I can top 1MB/s, but from peers in my city 10MB/s is the limit.

Hope this helps!

[Firon]

Have you tried setting an upload cap?

It does work sans limits, but in a special case like yours, it probably wouldn't work right because you have two separate caps, which would throw off any calculations.

[svalentin]

I did some more tests and here's what I found out:

- setting an upload limit has no effect (I wasn't uploading anything to anyone though)

- setting a 10MB/s download limit made the download speed jump to 5MB/s, rise slowly to ~6MB/s and then wiggle between said values. If at any time I remove the limit, the download speed drops slowly to ~4MB/s

I know it's hard to expect from the algorithm to work in my "special" case, but isn't this case present in everyday life for a fast connection? The connection will be limited by the network path toward the peer, and if 3 peers are in 3 different networks, this will result in 3 separate caps.

I can live very well with this option off, I am not complaining. Hope I'm not misunderstood.

I just wanted to report this behavior so you'll know about this.

[Switeck]

Similar message thread about bt.tcp_rate_control here:

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

[svalentin]

Hi again!

First of all sorry if I didn't notice a similar thread.

Second of all I was looking into the router's logs for no apparent reason and found out it was detecting a UTP DoS attack from the peers. Once I disabled DoS protection from the router, utorrent is working fine with bt.tcp_rate_control true.

It accelerates more slowly than with the option off, but that is to be expected and it does reach approximately the same maximum speed. With bt.tcp_rate_control false the speed graph looks like an exponential function (quickly saturating the connection), with it true the speed graph looks like a linear function. I say this it's working as advertised.

Sorry for the false bug report. Hope this may help other users with similar issues!

[Switeck]

What router brand and model is doing this?

[svalentin]

D-LINK DIR-100 Firmware Version: v1.12

The option is found in Advanced -> Firewall & DMZ -> (uncheck) Enable DoS Prevention

(If i recall correctly, older firmware didn't have this option)

[Switeck]

Thanks for the detailed response! It'll make my job easier.

...And may let others know why their (same) router is having problems as well.

Another D-Link router with problems: http://forum.utorrent.com/viewtopic.php?id=68044

[dmululo]

Hi, the same issue is occuring here.

I have a good connection speed with my ISP (fiber to home) and as they developed a torrent cache using tcp peers to speedup my files transfers, when downloading a torrent where co-exist UTP and TCP connections, these cache peers (on my local network) become "useless" in comparison with the UTP rates achieved.

When disabling the bt.tcp_rate_control feature, those cache connections ramp quickly to 100mbits each one and my downloads just finish in a blink of an eye without hurting my ISP bandwidth usage!

So, when on, this feature turns to a "share unfriendly" feature for high speeds lines.

Don't you think that it would be a win-win game if you guys consider to fix this behaviour on the future versions?

Keep sharing.