rapiddisk VS chiapos

I found that an alternative on Linux is RapidDisk. I installed it with no issues. However, I have to open terminal and enter a couple of commands manually to re-load the RAM drive as cache after boot, specifically:

Rapiddisk https://github.com/pkoutoupis/rapiddisk

As for ramdisk cache, what I was looking into is Primo Ramdisk which was mentioned a LOT around here, especially with high density plotting. Unfortunately that is only for Windows, but I found something similar for Linux: https://github.com/pkoutoupis/rapiddisk/ At this point I havent tried it, maybe indeed kernel module compiling will be enough, maybe not.

No need to reverse engineer anything. It's explained in all the detail you need in the Chia Proof of Space Construction document. It's implemented in chiapos though I find madmax's implementation of the plotter to be easier to read: https://github.com/madMAx43v3r/chia-plotter/tree/master/include/chia

If true, my assumption is they are implementing a Hellman attack on Table 1. Chia already describes the process here: https://github.com/Chia-Network/proofofspace/blob/master/proof_of_space.md#Hellman-Attacks and gives example code here: https://github.com/Chia-Network/chiapos/tree/main/hellman_example

I'm trying to farm plots created with different keys on a different machine. I know that I could add the plotter machine's keys to the farming machine and there is no official way to edit plots and change keys, but I'm interested in hacking things and looking at plotter_disk.hpp of chiapos, this is how the header (first few bytes) of a plot file looks like:

git clone https://github.com/Chia-Network/chiapos.git cd chiapos && mkdir build && cd build && cmake .. && make -j8 ./ProofOfSpace check -f plot-k32-???.plot \[num\_iterations\]

Is this the branch https://github.com/Chia-Network/chiapos/commit/369c9e773d9d43b00696771aad46cc5b4c54e785 ?

on my list above is just hard to do perfectly unless you specifically engineer the system that way. Thsi project probably manages to hit erasure blocks just right by virtue of the fact that it uses fairly large files, but it could probably be tuned to work better. You could maybe get partway there by changing the internal buffer size of the buffered disk in the plotter and recompiling/pip install-ing the plotter. In that case the buffer size would need to be the same size as the erasure block size of the SSD (or a multiple of it), but that is generally ~64-128MB these days. This approach would also cause somewhat higher memory consumption because the internal buffer size is for each bucket in each sort manager that is being actively written to, so more buckets with a larger buffer -> more RAM use (this is outside the memory limit you set on the command line).

By the time you get to NVME you are definitely CPU starved; give it more buckets and leave RAM at 3390. I dont think you can go past 512 without applying https://github.com/Chia-Network/chiapos/pull/202

The changes from https://github.com/Chia-Network/chiapos/commits/main commit cleanly into combined with the exception of the std::cout << "Using optimized chiapos"; bits which can be manually fixed, just FYI.

Sure you're not thinking of the P1 speed up from #208?