Jump to content

clarification of the rate limit settings


microser

Recommended Posts

Posted

I would like to make sure I understand them

  1. bt.tcp_rate_control: Enabling this option tells µTorrent to use information from the uTP transport as hints for limiting TCP transfer rates.
    My interpretation - dynamically limits tcp rate beyond the global max, based on uTP data. Is that correct?
  2. bt.ratelimit_tcp_only: Enabling this option tells µTorrent to limit the upload and download rates for TCP connections based on information received over the uTP transport rather than using static global rate limits.
    My interpretation - it seems to say that it completely ignores the global max for tcp, is that correct? So what is the global max used for then, uTP? If "Apply rate limit to uTP connections" is also unchecked, then the limit, even though set, will not be used at all (as if unlimited)?

Posted

bt.tcp_ratecontrol is done based off calculated maximums that uTP got while running. If you have a cap set, then it will never let tcp exceed that. This is whether or not uTP ratelimiting is turned on.

bt.ratelimit_tcp_only appears to be badly named and seems to actually just be controlling whether rate limits are on at all.

Posted
bt.tcp_ratecontrol is done based off calculated maximums that uTP got while running. If you have a cap set, then it will never let tcp exceed that. This is whether or not uTP ratelimiting is turned on.

bt.ratelimit_tcp_only means it will ignore caps for uTP, but still cap TCP. If you disable this and also disable uTP ratelimiting, then all caps will be ignored.

That's not what the help file says, is it wrong? It says that when enabled, it will ignore global static max for tcp and limit it based only on uTP data. Also, uTP limiting has a separate setting ("Apply rate limit to uTP connections"), if your interpretation is correct ("it will ignore caps for uTP") then wouldn't these two settings be in conflict?

Posted

bt.ratelimit_tcp_only appears to be badly named and is doing something else entirely. Let me go find out what it's actually doing.

But my explanation for tcp_rate_control is correct.

Posted

I like to know what it does too, and since it is defaulted to ON I suggest to rename it to something that people will understand , and not come back here ask why the speed is over the limit..

If it override the set limit - you should definitely - make it OFF as default!

Posted
I like to know what it does too, and since it is defaulted to ON

bt.tcp_ratecontrol is the one that's on by default and I think it's more or less clear what it's supposed to do: (rate limit TCP based on uTP data)

bt.ratelimit_tcp_only is the one that's unclear, that Firon is looking into. It is false by default.

There are four settings bits related to rate control producing 9 distinct combinations, so it's definitely a must for all these settings and their interaction to be clear.

  1. Bit 1: Whether global static limit is set.
  2. Bit 2: "Apply rate limit to uTP connections" - dependent on bit 1
  3. Bit 3: bt.tcp_ratecontrol
  4. Bit 4: bt.ratelimit_tcp_only - dependent on bit 3

because of the dependencies there are 9 instead of 16 combinations.

Posted
yes: Greg Hazel :)

Well, he's not volunteering. You've been on this board a while, what do you think is happening here? Seems like a reasonable request, to clarify a pref, why would they ignore it?

Posted

ratelimit_tcp_only will apply the speed limit to TCP if uTP connections are low. If "enough" uTP connections exist then the limit is automatically removed and uT tries to regulate TCP using uTP data. Seems to work well except apparently doesn't fall back well on packet loss.

Posted

This thread has been hijacked and derailed. Firon you appear to have modified you first post at some point.

bt.ratelimit_tcp_only appears to be badly named and seems to actually just be controlling whether rate limits are on at all.

This makes no sense, there is already a different setting in the ui that toggles rate limiting.

Why can't a dev provide a definitive explanation already, it's been weeks.

Posted
And I described it above already.

Your explanation echoes my own interpretation from the first post, which Firon did not agree with, before saying he would find out for sure. Since there's been disagreement/confusion, there needs to be a definitive answer from someone with access to the source (ideally a dev)

Archived

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

×
×
  • Create New...