questions about the ram cache

[rezad1393]

I have set my cache-size-mb to 128 which would mean that transmission program would download the file to ram untill its size gets to 128 MiB and then it flushes that to disk, correct?

I have some question about this.

1:
does this have a time limit? if I download a rare torrent that has an slow speed then that wouldnt get written to disk untill a 128 block of data is downloaded? if so then if transmission is sent a quit signal, does that data get saved to disk?

2:
is this cache for all torrents? or per torrent?

3: I tested with a torrent and my ram size goes up when it starts to download. so far good.
but when I stop the torrent it doesnt lower ram usage. does that mean that torrent wont get written to disk if stopped ?

[ckerr]

I have set my cache-size-mb to 128 which would mean that transmission program would download the file to ram until its size gets to 128 MiB and then it flushes that to disk, correct?

Mostly yes, but

• When the upper limit is reached, it doesn't flush the entire cache to disk. Rather, it flushes just enough to get the content under the limit again. It's been a long time since I wrote this code but IIRC this gave better overall performance since parts of the torrent often arrive out-of-order.

• When the torrent becomes complete, anything in the cache for that torrent is flushed. This is because we close the write file handle to the file before (possibly) renaming it, e.g. removing the .part suffix, and (possibly) moving it if the incomplete-dir feature is in use, and because further seeding will be used via a read-only file handle instead of a read-write filehandle.

does this have a time limit? if I download a rare torrent that has an slow speed then that wouldnt get written to disk untill a 128 block of data is downloaded?

Correct. There's no time limit.

if so then if transmission is sent a quit signal, does that data get saved to disk?

Should be, yes. I've never seen any issues with that. If there's an issue there, please file a bug report. Otherwise, if you're just asking because you're looking for best practices, exiting cleanly (instead of force-killing the process) should be enough. If you are feeling paranoid and want to be super-safe, you could stop the torrent before shutting down 😄

Is this cache for all torrents? or per torrent?

Per session, i.e. for all torrents together.

3: I tested with a torrent and my ram size goes up when it starts to download. so far good. but when I stop the torrent it doesnt lower ram usage. does that mean that torrent wont get written to disk if stopped ?

Most (all?) OSes don't immediately return freed memory back to the system for reuse; instead, they keep it around for the next time the app tries to allocate memory. The individual cache segments are freed inside the for loop in flushContiguous() here so I'm reasonably sure the cache isn't leaking.

[rezad1393]

I use transmission to download both popular and also rare file.
so I enlarged the cache size so that when download speed is high then the client wouldn't continuously write to disk.
but when I am just downloading a rare torrent and I have set the cache size to ,say, 128MB, then if after so many day the downloaded part is lower than that then it wont write to disk and if any bad thing happens to client to cause it to crash or exit badly (assuming clean shutdown writes the small downloaded data) then that data is lost which it not good for a rare torrent.

Can some time parameters be also implemented?
As I see it the cache is there so that I/O on hdd (or any storage medium) is not too high and this is a good thing specially for torrents that are have high seeds and get downloaded in large chucks.
But for rare torrent if there is no time limit (even after a week) then there is the danger of losing downloaded data that may not be again available.

Can you consider adding a time limit (even once a hour or even day) to help with this?
thank you.

[ckerr]

This seems like a pretty limited use case.

You could emulate this feature by having a cron job that calls transmission-remote to stop and restart the torrents periodically, since stopping the torrent will also flush that torrent's data from the cache.

[MichaIng]

For downloading torrents, I'd also suggest to generally not write the cache full and start to write to disk just when it's full, but doing so asynchronously. The purpose of the cache should be (IMO?) to flatten download speed and disk I/O, i.e. allow downloads to continue even if disk bandwidth is for some reason exhausted (e.g. on SBCs with SD card, or slow USB host, it can be very limited), and in case to keep writing from cache to disk, even if the download pauses. If the cache is first filled, it doesn't serve any of both purposes, but only increases permanent RAM usage and implicitly bears the risk of data loss (doubled downloaded of the parts hold in cache), for which I do not understand the benefit. If it's about reducing overhead due to writes smaller than filesystem block size, the native filesystem cache on Linux should reduce it sufficiently. EDIT: A small cache however is fine to be independent of native filesystem caching, which may not be always available/done, so for this the default of 4 MiB seems fine.

[GaryElshaw]

No shade on either of you, it often feels like development help is needed outside of the Transmission devs for dev help. I totally understand @rezad1393 edge case, it's just that some of us, me too, wouldn't know how to set up a cron job, and depending on OS, how to configure anything correctly.

[ckerr]

That's fair.

My point is that this is not a use case that many people are going to use. If I accepted all the feature requests like this, Transmission's code would be even more unmanageable than it is and every new feature would take even longer to add. (Or, more realistically, the maintainers would drift away from the project.)

So my goal here was to explain a way that this could be done outside of Transmission's codebase, because the choices are between "no" or "no, but..." and I wanted to at least give breadcrumbs on how it could be done.

[rezad1393]

is there a way to commit the data with no restart?
I remember "pkill -HUP transmission-da" for reloading the changed setting from from storage, so maybe something like that?

[ckerr]

Now that's a nice idea! File an enhancement request for that please 😄

[rezad1393]

what that mean?
how do I do that?
do you mean for me to write a patch? not possible with my limited knowledge.
if you mean I can request it somewhere then where? in issues? If so then should I point it to this discussion?

[ckerr]

No, not a patch. Please file an issue at https://github.com/transmission/transmission/issues

Thank you!

[MichaIng]

Just to clarify, is this used as download cache only, or for seeding torrents as well? For seeding torrents a larger cache makes sense, to reduce disk reads (e.g. lead if spin down/silent) while seeding. For downloads however (as mentioned above), I do not see the need for a larger additional cache (on top of native filesystem cache) at all.

[ckerr]

Just to clarify, is this used as download cache only, or for seeding torrents as well?

It's for downloading only -- the goal is to batch together adjacent disk writes. Even a small cache like this can dramatically reduce the number of write calls to the OS in a BitTorrent client since it's extremely common to request batches of contiguous blocks from a peer.

There is a separate, automatic prefetch mechanism used for reading blocks from disk before sending them out. When we are working through a batch of block requests, we try and prefetch the ones that we anticipate will be sent out as soon as more bandwidth is available. This is prefetching is done at the OS level (e.g. posix_fadvise()) and does not need any size config options.

[MichaIng]

Many thanks for the clarification. In our implementation we set this to 10% of physical RAM size (I think it was believed to be a combined download and upload/seed cache), which is then way too much 😄. The default 4 MiB should then indeed be fine in most cases to be independent of proper filesystem caching.

[Pentaphon]

The default 4 MiB should then indeed be fine in most cases to be independent of proper filesystem caching.

Is this really enough these days when most people have 2GB of RAM or more, usually 8GB?

[MichaIng]

That systems have more RAM does not mean that they have larger filesystem buffers, larger block/cluster sizes or a worse Internet connection. I.e. the factors which affect the benefit of a download cache have not changed. And the way it currently works, a larger download cache usually has zero benefit but only downsides: increased average RAM usage, fluctuating/batched download speed and disk writes, in case overall slower downloads (depending on bottleneck) and more data is lost on craches.

[ghost]

[andreygursky]

@no1ninjah

The write cache size is not hard-coded in 6bbe6537cbd31c7ef874e032b218dbdc98baba97 just set to a default value of 4 MB. Everyone is free to adapt the value for "cache-size-mb" in settings.json to a desired one. Moreover, in the git main branch user is allowed to bypass the write cache completely by supplying the value 0 (#5668).

Are we not just creating extra work for the CPU and bus by having another cache?

It's vice versa. By writing in 16 KB blocks, you will issue a write OS system call (with context switch into kernel) 8 times instead of only once if writing in 128 KB blocks.

studying ram useage and writes second by second I came up with around 16MB as an optimal setting.

What about a detailed CPU usage? Optimal in what sense?

[andreygursky]

@MichaIng

I do not understand how a second 16 MiB caching layer, ...

... until the cache was flushed to disk (well, handed over to the kernel write buffer?), which seems additionally inefficient to me.

See my comment above about system call overhead.

[MichaIng]

By writing in 16 KB blocks, you will issue a write OS system call (with context switch into kernel) 8 times instead of only once if writing in 128 KB blocks.

So this is about CPU usage only, not about effective download speed? Is this (the CPU utilisation due to write syscalls) really a relevant factor on common servers nowadays?

[andreygursky]

Well, this depends. As long as OS cache is not full calls to write() might not block and thus should not affect download speed.

Is this (the CPU utilisation due to write syscalls) really a relevant factor on common servers nowadays?

While it's a general CPU architecture design issue, it's especially got much worse with recent CPUs since about 2010. You may find information about spectre CPU vulnerability enlightening. But the negative impact varies largely depending on particular usage pattern.

[MichaIng]

As long as OS cache is not full calls to write() might not block and thus should not affect download speed.

And an additional 4 or 16 MiB cache won't change much about whether the native write buffer of 20% memory size will be full or not. And one could also raise it via /proc/sys/vm/dirty_ratio or /proc/sys/vm/dirty_bytes.

But the point about about CPU utilisation when directly writeing every packet received is a good hint. So we know what to watch out when benchmarking.

[rezad1393]

And the other problem remains that Transmission seems to download and write in batches, i.e. downloads to its cache until its full, then stops downloading until the cache was flushed to disk (well, handed over to the kernel write buffer?), which seems additionally inefficient to me.

I think I saw something like that when I put the ram cache to a high enough value.
the app wo)uld download a torrent with fast peers but then speed would go to zero for a while (my hdd is not the fastest and its filesystem is fragmented) and then after some seconds would download again.

I will test to see if it is still true. with new versions.

[rezad1393]

right now I can't reproduce it with my internet speed and ram size.
my speed is 2MB/s and I set the ram cache to 64mb and I don't see dipping in download speed.
so maybe something changed,