Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2832 closed Enhancement (wontfix)

Advanced options for torrent-caching

Reported by: Renara Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.83
Severity: Normal Keywords:


I've been following the changelogs and noticed that a bit of work has been done towards reducing disk activity, which is awesome, really appreciate that, and I'm sure my poor torrents drive does too =D

I was just thinking it might be nice to have some advanced options for power users to control this a bit more. The main ones I would like is the ability to give Transmission a big(ger?) chunk of RAM to use as a cache; I have 10gb and am getting more soon, so I can spare a bit! In addition, it could be possible to assign a chunk of another drive for caching as well, allowing us to assign some RAM for frequent access, and a hi-speed drive for less frequent access.

The reason I'd like this is that my torrent drive is of course quite large since torrents are usually at their best with large files, and that can eat up the space pretty fast, but it's just an ordinary moving parts drive, so avoiding thrashing if I can is a big plus! I'd like to take the weight off the drive where possible, so being able to choose to dedicate more RAM to that task would be particularly nice.

The updates that have come through have made a really noticeable difference in my case already, so this isn't needed as much, and I assume Transmission automatically decides how big a cache it currently tries to allocate, but it'd be great to be able to give it more, perhaps under an advanced tab?

Change History (5)

comment:1 Changed 12 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed
  • Type changed from Bug to Enhancement

We appreciate the thought that has went into this, and understand the concern, but this level of control is outside of our design goals. This would not be used by a lot of people, while a lot of others will just set it to a random high value because of their lack of understanding - I think it is better to try to optimize this situation in code without exposing this sort of control.

comment:2 Changed 12 years ago by charles

Renara: at some point we're going to make better disk caching a default value anyway to follow the "Just Works" goal w/o having to add GUI preferences for it. Maybe there could be some settings.json options but IMO this doesn't warrant a place in the GUI.

I don't have the disk cache ticket # handy atm, but this is a duplicate of that.

comment:3 Changed 12 years ago by Renara

Ah okay! Would it be at all possible then instead to add an RPC call or similar that lets me query how much RAM is being allocated and used for this purpose? Perhaps a general purpose resources query where you pick one or more values to query, or added to the session-get method if that's more appropriate? This way I can be meddler-me and see how well the auto-cache size is doing on my system, or other machines I might run Transmission on (am thinking of getting a dedicated machine sometime soon).

comment:4 Changed 12 years ago by charles

If I had to distill the decision process down into a single formula, it would be User Demand divided by Complexity. The more people want something, the more likely it will be added. The more work something is, the less likely it will be added.

This ticket fails on both items. The smaller failure is complexity of adding the RPC calls, documenting it, making status items available, updating the RPC clients to handle these options, and so on. Compared to big items like encryption and DHT this feature's complexity is small, but it's still nonzero. The larger failure is User Demand -- nobody is asking for this, and even if a handful of people showed up asking for it, that's still a handful of people weighed against (1) the complexity mentioned earlier and (2) literally years of nobody asking for this.

I'm pretty sure that disk caching will exist in some form in Transmission, but it probably will not be interactively tweakable in the way you're suggesting here. For example DHT is a much more prominent feature, and it still doesn't have *any* visible user feedback yet.

comment:5 Changed 12 years ago by Renara

It's great to hear that even better caching is planned! I had an idea that doesn't really deserve its own ticket, at least not now, so I hope you see this:

Basically, even with a really good automatic algorithm for determining RAM used by caching, it's going to be hard to get it perfect (if such a thing is even possible), so I think an advanced tab is still a must at some point. What I'm thinking though is better than the original proposal; basically you'd have a slider, at one end is "Minimum memory use" and the other is "Maximum performance", while the middle is "Balanced" or "Best of both". Basically this would allow the user to tweak the allocation depending upon their needs, with some text under the slider giving an estimate of the minimum/maximum memory use and caching efficiency at that setting. Basically at maximum performance the algorithm would allocate all the RAM it needs to get the best level of caching efficiency it can, and will be slow to give that up as system RAM becomes limited. At the other end of the spectrum minimum memory usage will practically disable caching beyond the current pre-fetching that is already done, except when the system has been idle for some time and there is a lot of RAM available. The middle (default) notch will aim for good performance, without using too much memory.

I think when caching is involved the scale is roughly logarithmic; throwing more RAM at it has declining results depending on the exact nature of the task, so the middle setting will usually sit at a good point on this scale and be fine for most users. But for people who have a machine that runs nothing but Transmission, bumping the memory use right up to get an extra few percent cache-hits would be desirable. It's hard to say how well that will hold for torrents though due to their very random nature. Presumably cache-size would depend upon number of active peers, and the speeds they are operating at. This would provide a target RAM usage, however, the slider would tweak the minimum and maximum values, which would be based on a percentage of the user's RAM. So the default might never go above 50% of system RAM, and never below 20%, but would favour somewhere around 35%.

I realise more caching updates might still be a long way off, and an option to control it wouldn't be needed from day 1 (I may give this idea a new ticket when updated caching does hit though), but I think the slider gives some control to the user, but the exact values would ultimately be up to the algorithm used to calculate how much memory is used. Just something to keep in mind! It's just that even with a perfect "just works" implementation you may still see cases where someone has a lot of RAM, but uses most of it regularly on games or high-demand programs, so might need Transmission to scale back a bit more. At the other end of the spectrum, someone might have a relatively low-spec machine running nothing but Transmission, and is happy for it to eat up all the available RAM.

Regarding DHT; I'll be honest and say that while I understand the basic workings of it, I don't really understand the user impact. It's possible this slider could be used to control all aspects of Transmission's memory usage for caching and so-on, then Transmission can decide how much to allocate within that, i.e - if DHT needs a certain amount then it will get that first.

Note: See TracTickets for help on using tickets.