More and more places are getting optical connections. This means with large amounts of torrents, the hard drive can become both noisy and a bottleneck.

Beyond the Peer read caching, the following would be welcome:
1) In the right click menu, a "Load to RAM" option above the "Constant Seeding". This would cache all the torrent's files into RAM upon startup with a status indicator (example "Seeding+R"
Of course along a limit specified in Setting > Transfer > Files > "Stop caching into RAM, when free memory is below MB"

2) In the Settings > Transfers > Locations, the ability to set RAM as a primary destination for "Incomplete Piece Storage Location" and another path when running out of memory or when Tixati is shutting down would not only benefit hard drives, but also for SSD users.


I've tried to achieve the second one with multiple RAMdisk software, but they don't really work well with torrent clients. Deluge, qBittorrent, µTorrent, Tixati and Transmission crash at some point, probably because of some unique disk management strategy.

This comment is not meant to sound negative but my technical perspective and opinion.

1) Are your files defragmented?
2) Torrents only download sequentially within a block. That means peer read caching is the correct setting. The entirety of data is downloaded randomly
3) Your OS automatically caches read/written files in memory until it needs to clear the cache due to other apps requiring it or the files there being too old. That means if you read a small file, it is only once read off the disk and each following read is served entirely from RAM cache

4) Peer read caching. It only makes sense for Tixati to read data sized to torrent's block size: we assume the entire block will be sent/saved. However there's no explanation what the named settings actually do.
I recommend to set 2MB blocks if you have up to 20mbps speeds and 4MB blocks if above. This was determined empirically but not statistically and not in a controlled fashion.
If your files are fragmented (torrent's blocks will not align with file system clusters) then peer read caching breaks: instead of reading a continuous piece, your HDD jumps back and forth between fragments.

Given all of the above there's no reason to keep entire files in RAM. If they're accessed frequently, they'll never leave OS cache. If infrequently, instead force Tixati to read bigger pieces at once. Ideally: one piece at a time. If the remote leech is downloading sequentially then it can in theory read more at once. Buy more RAM.

I cannot comment on RAM disk because I haven't tried. Tixati relies on incomplete piece storage to be saved if your computer is shutdown/crashes. If it's in RAM then they will be lost. Other clients just write to the target file and don't have this problem. Sometimes it can be useful.

Here is a specific example. 10 GB of transfer (fits in RAM, but the OS won't keep all in filesystem cache) with 100 average peers (only few of them will download sequentially) and 50 Mbps average speed. And there is also the use case of running Tixati portable from an USB flash drive.

Regarding incomplete files, I meant incomplete files and incomplete pieces. Keeping them in RAM until Tixati is closed or the file download is finished to prevent disk fragmentation. Basically set default download location to RAM, and upon completion, move to disk. For me crashes became rare enough.

In regards to your second point, what RAM disk software have you tried. I have a 170GB ImDisk ram disk, that I point all of my downloading to, before moving it to spinning disks after completion. I have been running this solution for a few years now without any crashes. What OS do you run this on? How large do you set your disk to be?