Opened 11 years ago

Last modified 5 years ago

#3076 reopened Enhancement

Local peers speed limit

Reported by: seryibaran Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.04
Severity: Normal Keywords: local peer speed limit retracker
Cc: darwin2kx, transmission@…, amontero@…


There's no way to set a speed limit separately for local peers. This would be particularly useful for local retrackers or other means of local peer discovery.

Currently if I set speed limit then I won't be able to take advantage of local peers' download/upload speed boost. If I disable speed limit then my Internet connection chokes.

An option to disable speed limits for IPs matching a mask (like 10/24, 172.21/16, 192.168/16) would be really nice.

Attachments (1)

transmission_unlimited_speed_local_networks.patch (14.2 KB) - added by benoar 7 years ago.
[PATCH] Unlimited speed for peers on local networks

Download all attachments as: .zip

Change History (28)

comment:1 follow-up: Changed 11 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

Interesting, but I don't see the majority of users using this. Closing as bloat.

comment:2 Changed 11 years ago by User294

Actually for example in ex-USSR many networks are running over Ethernet (including dozen of huge metropolitain area networks with millions of users) and local subnet is allowed to have full 100Mbps speed while "global" Internet limited to subscription's data rate (which is 2...30Mbps usually). Having two separate limits could be handy. Though surely this feature is not a top priority and adds bloat and not easy to implement in wat which would satisfy all users of similar networks.

Btw, it also could be a good idea to use local peers discovery and/or prefer peers from same subnet if possible, this can increase download speeds by several times and/or reduce "external" traffic (that's what is warmly welcomed by all ISPs, they even set-up so called "retrackers" who gives local peers rather than remote when possible).

comment:3 in reply to: ↑ 1 Changed 11 years ago by IRON

Replying to livings124:

Interesting, but I don't see the majority of users using this. Closing as bloat.

I think that this will be very usefull feature. In Deluge this feature is present and lot's of users in our LAN doesn't wont to change torrent client only because this feature. I support this feature request very much. Now I need to power off speed limits while downloading torrent from LAN. It is not easy-to-use.

Last edited 11 years ago by IRON (previous) (diff)

comment:4 Changed 11 years ago by net147

I use this feature all the time in other clients. I support this feature request.

comment:5 Changed 10 years ago by darwin2kx

  • Cc darwin2kx added
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.92 to 2.04+

I would love to see this feature as well. I cannot imagine it would be difficult to provide a config option for LAN speeds based on Local Peer Discovery. I hate having to uncap my upload speed just to attain a reasonable speed inside my own LAN, because it saturates my external connection as well during that time.

This is not an example of a bloat feature, and I can see moving to Deluge if it supports this feature (not a threat, just a needed enhancement to Local Peer Discovery).

comment:6 Changed 10 years ago by livings124

  • Resolution set to wontfix
  • Status changed from reopened to closed

This is still a feature only a small handful of people would use, and adding yet another set of bandwidth limit fields (and inevitably other settings to work with speed limits) is not an option.

comment:7 Changed 10 years ago by howl

In some countries like the ones said by User294 this could be very useful and it's a lot of people with these Internet connections. I'm not going to reopen it because I don't use local peers but wanted to give some ideas that could match the developing principles of transmission. Instead of a extra speed limit could be a boolean to prevent the limit take effect for local peers (usually local connections doesn't suffer network overload).

About the way to apply this I'm not sure, because "the lans" of these cities won't give lpd as they aren't in the local network between them. Implementing a way to select interfaces is not the philosophy of transmission development, and making it applied only for lpd won't be useful for the connections said.

comment:8 Changed 10 years ago by seryibaran

I am sorry, but I just don't get what's the point in having local peer discovery if you can't take advantage of local speed. Don't get me wrong, I just love Transmission, but uTorrent works with local peers as expected.

comment:9 follow-up: Changed 10 years ago by pauls

This is still a feature only a small handful of people would use

Surely it's exactly the same number of people that would use local peer discovery in the first place. The reason for limiting my bandwidth is not because my local network can't handle it, but because the upstream link cant. When I'm talking to local peers the bandwidth limit is just in the way.

Maybe there's a situation where local peers are bandwidth limited (a university maybe), but you're either one or the other, so make it a single checkbox "Apply bandwidth limit to local peers"

comment:10 Changed 10 years ago by cdmarcus

My reason for using Local Peer Discovery is so that if I download a torrent on one machine, I can get its contents to another one using only my local network rather than re-downloading it, setting up another file sharing system, or using a sneakernet. For my purposes, not having a separate speed limit severely limits the utility of the LPD feature. If I leave the speed limit low, I might as well just re-download the torrent over the Internet. If I disable the speed limit, it swamps my Internet connection. I'm not sure I see the purpose of Local Peer Discovery if the speed limits are the same -- I don't much care whether data gets transferred over the Internet or my LAN if they're going to be capped at the same rate.

I understand the need to keep the interface simple, but I second pauls' notion that the number of people who would use a separate speed control are probably the majority of people who would use LPD at all. Transmission needs both for utility, or none for simplicity. Having one but not the other simply doesn't make sense.

comment:11 Changed 10 years ago by neglesaks

Having been a long time user of Transmission, as well as having this feature relevant to me also for reasons mentioned by others in this thread, I'll initiate by acknowledging that I first highly agree with the Transmission mission of being a simple and intuitive BT client.

But as others, esp. cdmarcus above have pointed out, it makes no sense to add a feature that will be handicapped by other features of the application (here, the global bandwidth cap).

I'd also like to point out, that it makes no sense either not to have local peer discovery active; the point of the entire program is to distribute data. Disabling LPD would mean that you were intent on distributing your data non-locally, but not locally (or in other terms, slow and expensively as opposed to fast and cheap). I cannot see how this would be anythign but absurd, and for the tiny fraction of users where it would make sense, I'm sure they are sufficiently technically capable enough to set up a block in the hosts file.

Would it make sense to have LPD fall under the PEX functionality? If yes, remove the "LPD enable" checkbox entirely, and implement an automatic bandwidth override for local peers if the PEX/LPD is enabled.

(Of course there is a question of what the internal/local bandwidth cap should be if there is no way to user-configure it in respect of user interface simplicity, but that should also be decidable based on the oldest hardware/OS Transmission can run on, coupled with some simple accounting done by the application of how fast the local peers can accept data, plus how fast the machine itself can provide it from storage. Personally, I cannot imagine a likely scenario where providing data to local peers would cause a significant hit on system performance, but in any case, I believe smart caching would go a long way to alleviate any possible problems caused by the absence of a local bandwidth cap).

My .10 $.

comment:12 in reply to: ↑ 9 Changed 10 years ago by shadowlmd

  • Cc transmission@… added
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 2.04+ to 2.32+

Replying to pauls:

Maybe there's a situation where local peers are bandwidth limited (a university maybe), but you're either one or the other, so make it a single checkbox "Apply bandwidth limit to local peers"

Indeed, it's not a "set of bandwidth limit fields", it's just a single checkbox. It is present in uTorrent for ages and noone ever complained about it's complexity. And it makes a lot of people happy.

comment:13 Changed 10 years ago by livings124

  • Version changed from 2.32+ to 2.04+

comment:14 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed
  • Version changed from 2.04+ to 2.04

comment:15 Changed 9 years ago by jordan

#4472 has been closed as a duplicate of this ticket.

comment:16 Changed 9 years ago by Harry

Why even have the LPD option if you can't have an option to send unlimited bandwidth to local peers? :(

comment:17 Changed 9 years ago by a005

  • Resolution invalid deleted
  • Status changed from closed to reopened

Without this feature I have to look for a replacement...

Please do not close the ticket, even if you dоn't have a plan to implement it in the near future

comment:18 Changed 9 years ago by cfpp2p

Right now we've got #1079 'Webseeds do not respect speed limits' (which is ~sort~ of what's wanted here for local peers), and #4402 'Transmission Bandwidth allocation getting overflows' which would be a problem for setting very high bandwidth limits on local peers. I'm running in circles... dizzy patching in circles...

comment:19 Changed 9 years ago by collegeitdept

I think this feature may not be "desirable" by the mass of Transmission users because most don't understand enough of computing. I do think that this would benefit TREMENDOUSLY all Transmission users and BitTorrent? users. This would help alleviate the bandwidth/consumption load for ISP and help slow data caps and throttling!!! Transmission should really really implement this feature ASAP for that one reason.

Until then, I guess all of us Transmission users will have to re-download every time we need a file on another Mac. Which goes against exactly what BitTorrent? protocol was designed to be - an EFFICIENT method for transferring.

Please implement this feature... add a simple "Apply bandwidth limit to local peers" to the advanced tab in the Preferences window please.

comment:20 Changed 9 years ago by collegeitdept

Can we please have this option implemented so that users (us) can have the power to determine how our bandwidth will be allocated please?

Just a simple checkbox in the Advanced tab of the Preferences window.

comment:21 Changed 9 years ago by collegeitdept

I meant to say the checkbox option added to the 'Network' pane of the Preferences window.

comment:22 Changed 8 years ago by amontero

  • Cc amontero@… added

+1 for an override speed caps for LPD peers. IMHO, most use cases enbling LPD are precisely looking for this benefit, too. Also +1 since torrenting looks for *efficient* file sharing.

Changed 7 years ago by benoar

[PATCH] Unlimited speed for peers on local networks

comment:23 follow-up: Changed 7 years ago by benoar

The patches I just attached allow for an unlimited upload/download speed for peers which are inside networks listed in the new "local-networks" session configuration key. The syntax for it is a string of "network/prefixlen" (e.g. "" or "2001:db8::/48") separated by space, comma or semicolon (like the RPC whitelist).

There is no UI as I was too lazy for it, but you can set the configuration key by hand in the "settings.json" file.

Tested working on version 2.52, then rebased the patches onto SVN to get these ones, compiling OK and hopefully running well.

comment:24 in reply to: ↑ 23 Changed 7 years ago by shadowlmd

Thank you for patches, benoar! I hope devs will include them into next release.

comment:25 Changed 7 years ago by benoar

Actually, re-reading my patch, I am not sure it works for IPv4 (I only tested it for IPv6). It may need to htonl() the addresses beforehand, or not htonl() the mask; I can't wrap my head around it for now. If someone feels like addressing this… (I am mostly interested in the IPv6 part, 'cause I am not doing LPD but only using IPv6 global addressing capability to allow my peers in differents subnets to communicate)

comment:26 Changed 7 years ago by amontero

Also, looks like that the desired "seed ratio" for LPD'ed or explicitly added peers should be unlimited, or at least different from non-locals.

comment:27 Changed 5 years ago by tal9000

I wonder that this feature is so little demand, I myself could do it well and am search also a torrent client of this on my NAS ( QNAP ) supported. Unfortunately I have not found this with transmission now. My hope now is that it will eventually still inserted, via settings.json would be enough for the low demand. Thank you for reading and the work done on the project.

I apologize for my bad English. Merry Christmas

Note: See TracTickets for help on using tickets.