Two implementation of auditing, there were more. We were using this to figure out how each behaves on different operating systems and drives to make sure we are using the fastest implementation by default on all platforms.
single opens the file once and uses that for reading from multiple threads.
rayon opens files as many times as there are farming threads and for each thread uses that dedicates file handle. rayon is the library we use for multi-threading stuff.
On Linux both perform similarly with small edge to rayon, Windows is problematic and rayon is MUCH faster there (your machine is likely much faster than old-ish machine I used for benches there, so you see even bigger performance gap). This allowed us to get rid of memory-mapped I/O and get even better performance on Windows and get some speed-up on other OSs too.
rayon is currently the default, there might be other options added in the future.
You should be able to audit well within 1s window because farmer receives a new challenge every second (1s is our slot time).
Generally you look at throughput and that will tell you how big should that SSD be for you to not be able to audit it quickly enough. Both CPU and disk performance impacts that, so if you add a second disk of the same size, the time will not necessarily increase 2x, it will likely have much less impact. It still gives you an idea about performance.
If you have high-end NVMe 4.0 or 5.0 SSD (or RAM disk) you can use this as an auditing CPU benchmark since SSD will no longer be your bottleneck.
For example this benchmark uncovered some CPU-related performance bottlenecks in the protocol and we have already improved auditing on the protocol level in Gemini 3g, 3g is more energy efficient than 3f in that sense and further research is ongoing, so there might be more improvements.