[FR]: Add Aggregate Group Speed Capability

[walkerp1]

Is your feature request related to a problem? Please elaborate.

At times, my public tracker upload saturates my bandwidth to the point that my private trackers get choked. For example, I might have anywhere from 3-20 public seeds running at any one time and 20 Mbps that I'd like to contribute to the swarm. If I set limit_upload_speed to 1 Mbps for that group, it doesn't infringe on private tracker bandwidth, but there are times that it would only be utilizing 15% of the available pool.

Describe the solution you'd like

I would love to see a share limits configuration item, group_upload_speed, that would distribute upload speed across all running torrents in the group. In the example above, if 10 torrents were active in the "public" group, I would expect the upload speed limit to be set at 2 Mbps for each. Naturally, this configuration item would be mutually exclusive with limit_upload_speed.

Does your solution involve any of the following?

• [X] New config option
• [ ] New command option

Describe alternatives you've considered

Right now I use limit_upload_speed for the "public" group, but since the number of active torrents in the group varies, I have to take a "least amount of impact" stance that underutilizes my bandwidth.

Who will this benefit?

Anyone who likes to contribute bandwidth to public trackers without adversely affecting their private trackers could find this configuration item useful for maximizing their throughput.

Additional Information

No response

[bakerboy448]

So the input would be some bandwidth and then qbm would need to do the math to calculate the size of the group and then divide said limit by the size to then apply the upload limit to each?

seems like a rather complex highly niche request given publics can already be limited

[walkerp1]

It's a pretty simple request that I'd estimate at about 10-20 lines of code and documentation. I'd just bang it out myself, but I thought there might be some others interested in the capability.

[walkerp1]

Well, it sounded interesting so I went ahead and did just that. It's in production right now on my system and working as desired. Have a look.

[bobokun]

@walkerp1 , can you please test the latest develop branch to see if your aggregation group speed is still working as expected? Thanks!

[walkerp1]

Certainly, I'll give it a whirl.

[walkerp1]

When we do this at share_limits.py:187 if group_config["limit_upload_speed"] == 0: group_config["limit_upload_speed"] = -1

...we lose the ability to do this at share_limits.py:277 self.set_tags_and_limits( torrent=torrent, max_ratio=group_config["max_ratio"], max_seeding_time=group_config["max_seeding_time"], limit_upload_speed=group_config["limit_upload_speed"] if group_config["limit_upload_speed"] else group_up_limit, tags=self.group_tag, )

since group_config["limit_upload_speed"] is no longer a present/absent indicator.

[bobokun]

Hi @walkerp1 , can you please test again? Thank you!

[walkerp1]

The last set of tests were a success, @bobokun. The group upload speed was properly apportioned across the group entries and groups with limit_upload_speed set used that instead (preferred over group). However, note that when limit_upload_speed is set to -1 naturally (no limit), it will be bypassed by the new check, which is an unintended consequence. Some other global flag would probably be more appropriate, perhaps.

[bobokun]

Do you think it makes more sense to have a global flag under settings or for each priority in share limits?

[walkerp1]

Since each group is evaluated separately, it seems appropriate to have it in the group_config and assigned in update_share_limits_for_group where it is already being assessed.

[bobokun]

Hmm, as I was coding this I realized that if the group_upload_speed is defined at the group_config level, then it doesn't make sense to define a limit_upload_speed variable as well to override. I don't see a use case where a user could define both group_upload_speed and limit_upload_speed in the same grouping. Does this make sense or am I not understanding this correctly?

[walkerp1]

It is fair to say that you only really need one speed defined in the group config and that it would contain either a limit speed or a group limit speed, determined at runtime per group. There is no current plan to merge the two in any way.

[bobokun]

What are your thoughts on having just a limit_upload_speed variable and a separate Boolean variable called enable_group_upload_speed. This way the limit upload speeds get defined in one variable and the toggle enables the calculation to split the limit upload across the group

[walkerp1]

Yes, that sounds cleaner than maintaining both and trying to keep them meaning what you think they mean as they mutate.

[bobokun]

@walkerp1 , can you please test the latest changes in develop and use enable_group_upload_speed: true in your config instead?

[walkerp1]

At share_limits.py:193 group_config["limit_upload_speed"] = round(group_config["limit_upload_speed"] / len(torrents))

is getting executed for each torrent rather than once per group, resulting in the wrong values being applied for the 2nd evaluation and after.

[bobokun]

@walkerp1 thanks for the feedback, can you please try again with the latest update?

[walkerp1]

This one looks like a winner, @bobokun. All permutations were handled properly, even the ones where I messed up the settings.