Opened 12 years ago

Last modified 10 years ago

#2997 assigned Enhancement

Auto-calculate upload slots per torrent

Reported by: nifoc Owned by: charles
Priority: Normal Milestone: Sometime
Component: libtransmission Version: 1.91
Severity: Normal Keywords:


See this ticket for more information.

This patch adds support for automatically setting the number of upload slots per torrent. This is done by calculating: 1 + (upload_speed / 6).

Note: I'm not sure if I've put this in the right place (updateBandwidth). It also overwrites everything someone might have set via settings.json if the upload speed is limited - globally or scheduled doesn't matter. So in case someone hasn't limited his/her upload speed, it will fall back to the hardcoded (or settings.json) value. IMHO this seems to be the best way of doing it, because calculating the slots in rechokeTorrent would be overkill, especially for people with unlimited upload speed. I'm currently testing this patch and so far (running for 3+ hours) it seems to work quite well.

Attachments (2)

auto_upload_slots.diff (1.3 KB) - added by nifoc 12 years ago.
auto_upload_slots_with_limit.diff (30.3 KB) - added by nifoc 12 years ago.

Download all attachments as: .zip

Change History (11)

Changed 12 years ago by nifoc

comment:1 follow-up: Changed 12 years ago by Longinus00

I'm not sure where you got the formula from but it seems to allow too many slots per torrent. Basically, assuming only one torrent fully saturated, the formula is going to allow ~6 kBps upload speed to each peer on average. Think about it this way, it recommends more upload slot than the current 14 for any upload speed faster than 84 kBps, slower than a 750kbps connection.

comment:2 in reply to: ↑ 1 Changed 12 years ago by nifoc

Replying to Longinus00: This formula is basically what many "BitTorrent? speed guides" suggest. But I see what you mean ... maybe there should be some kind of upper limit? Limiting the number of max. slots to (e.g.) 14 would be trivial. I'm just not sure what a sane number would be. Any suggestions?

Changed 12 years ago by nifoc

comment:3 Changed 12 years ago by User294

As for me I run into situation when there is only 1-2 active torrents seeded (+ number of inactive ones) and a fast 30Mbps symmetric link. In this scenario Transmission behaves poorly and only uses ~30% of link bandwidth because there is only 15 leechers connected per torrent and they fail to consume all available bandwidth. So, in fact, 2/3 of connection bandwidth is unused while there is many peers who can actually download from us at the moment. And yeah, keep in mind: ideally, someone can have a 100Mbps link and may want to saturate it with a single torrent. Why not? I guess that in this case slots have to be as high as 100-200 per torrent or so in some scenarios. And if I can download from 100 peers I guess it's ok to upload to them as well.

Last edited 12 years ago by User294 (previous) (diff)

comment:4 Changed 12 years ago by Sato Ambush

In my humble opinion the number of upload slots calculated based onto that equation by nifoc but also the number of slots suggested by user294 are too high and way too high.

if i take an upload bandwidth of lets say 80 kb into consideration, like i have at home, i get, based on nifocs equation, 14,3333 slots for uploads assigned, which is similar to the slot number used in recent transmission builds. but if i look into the peers tab in the inspector i have around 2 or 3 peers with transfers and the rest is idling with 0,0 kb transfer and stress the available upload bandwidth with its overhead. not good for the swarm at all imho. i think those high upload slot numbers on especially small upload bandwidths are deadly for it.

i would recommend a different more empiric approach. why not predefine slot numbers for speed ranges. like 0-25 kb 1-2 slots, 2-3 slots 25-75 kb per torrent and so on. with a upper limit of 14 slots or something (those numbers would be open for discussion). and in the next step monitor the behaviour of the peer upload transfer speeds on the torrent. means every few minutes monitor how many peers have upload rates near 0. and if the overall speeds aren't at the max then cut the number or increase the number of slots per one depending on its behaviour over the time.

comment:5 Changed 11 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 2.20
  • Owner set to charles
  • Status changed from new to assigned

comment:6 Changed 11 years ago by fijam

By the way, please leave the option to set the number of upload slots manually.

comment:7 Changed 11 years ago by jordan

  • Milestone changed from 2.20 to Sometime

There's not time left to get this done before the 2.20 without it being a rush job.

comment:8 follow-up: Changed 10 years ago by gunzip

if this ticket ever comes up for consideration, i think it would be nice to have a manual entry in settings.json for maximum no. of global upload slots in addition to the existing per-torrent:


that way as more torrents are added the amount of upload bandwidth per slot doesn't become ridiculously low. my 2 cents but these proposed empirical formulas for assigning slots are more witchcraft than science. i think just the addition of one global setting would serve the purpose.

comment:9 in reply to: ↑ 8 Changed 10 years ago by SIO

  • Cc… added

This bug affects me too :)

I think the best solution is the one suggested by gunzip in comment#8: no unprovable calculations and gets the job done.

Hope to see it implemented in one of new releases

Note: See TracTickets for help on using tickets.