That is helpful. So each farm uses ~50% of CPU core at that plot size, which is not great, we should be able to optimize it further (at least I hope so).
3 farms on the same disk should be suboptimal, but no way to know except to test it. While I agree 2300 IOPS is not a lot, I’m not sure if every read actually translates to a single IOPS. It should be.
According to benchmarks drives should have no problem doing that many reads, which might indicate that auditing CPU overhead is the reason here.
We have auditing benches in monorepo, but they generate plots each time you run them, making it very time consuming to run. I’ve created following ticket to implement such a benchmark: Create auditing benchmark that can be used with existing plots · Issue #1914 · subspace/subspace · GitHub
It’ll look something like this so anyone can run it:
subspace-farmer bench audit /path/to/farm
Not very high on my list due to higher priority tasks, but we’ll get it done.