So it appears to me that the sequentials reads from the RAM Disk are about twice as fast with PrimoCache enabled than without PrimoCache. Also the IOPS are significantly higher on when PrimoCache is enabled.
Only the 4K-64 Thread reading/writing shows about twice the speed on the uncached RAM Disk.
So for sequential work, using a HDD with PrimoCache seems better than a RAM Disk. And the RAM Disk is better for highly concurrent I/Os as it seems. I still wonder a bit why that is, however, different measurement tool, slightly different results.
Unfortunately I can not measure the Primo RAM Disk with DIrect IO mode, nor a normal HDD RAID enclosure with the AS SSD Benchmark, because the first one does not show up and on the second one the Benchmark always crashes.
I stand with my finding that for my work PrimoCache is actually making the RAM Disk twice as fast - and a HDD using PrimoCache is as fast too! The values I see in AS SSD before it crashes on the HDD are even higher than that of the cached Primo RAM Disk SCSI... The same I've already seen in ATTO Disk Benchmark 3.05.
The only question I remain with right now is what exactly happens with this 4K-64 Thread measurements, as the IOPS had been higher on the cached disk, why do 64 Threads turn out slower than without the cache?
Last edited by Axel Mertes on Thu Jan 19, 2017 1:43 pm, edited 1 time in total.
@Axel Mertes, many thanks for these testings!
Yes, this is kind of weird. Theoretically, ramdisks shall be faster than cache. I have reported this issue to our R&D colleagues and will study it later.
Increasing defer write latency may be able to increase performance as long as the available memory does not run out. However, the longer the defer write time is, the more risky it gets when there is a powerloss or simply a blue screen crash.
For unimportant data I even use "forever" settings, which is nearly close to a typical RAM disk, which is only saving to disk when you close down the system - or memory runs out.
If your defer write time is too short, the system may be still writing data to the cache, while the cache begins writing back to the harddisk drive at the same time. If memory is low (filling cache completely up), this will end up in PrimoCache no longer being fast at writes, as it can only store only directly to HDD or to cache, when other cache blocks have been free'ed up by writing them to disk first. As I wrote - it depends on your memory size, the defer time setting, your workload. Finding the right balance is very much dependend on what you do. On a desktop it may be hard to find "THE" solution, but you may still feel accelerated. On the other hand, having writes cached - if its not really necessary - is something I would currently recommend to avoid for security reasons.
I have my main server volumes running with read only caching, while I have a disk-to-disk backup ("intelligent" mirror running scripts or software such as Syncovery) that utilizes a write cache with 300s deferred writes. This way the mirror tasks runs really fast, and in case of a failure its unlikely that I loose all at once, as at least the original has no write delays, so I could mirror difference later again.
I can't really say that a 4 GB RAM PC is not recommended for using PrimoCache, but its clear that the less RAM you have, the more likely Windows and other programs will run out of memory (strongly depending on what you do) and will instead beging swapping in/out RAM pages to the swap file. So by dedicating memory to PrimoCache you may end up forcing your computer to stronger swapping, which could affect overall performance strongly.
The best would be to do what you usually do and track the RAM usage using e.g. Task Manager. If you see that you never use more than 2 GByte for instance, its potentially save to dedicate some RAM to PrimoCache. Usually PrimoCache will offer you to use as much RAM as it finds free, so creating a cache in the moment of strongest PC memory usage might be a wise decision. If PrimoCache finds too few RAM, it may not work out, as e.g. the index for the cache will usually take some serious amount of RAM too (and this overhead gets bigger, if your HDD and Cache block size is small..., so 64KB blocks is smaller overhead than 4KB blocks).
