write cache not working with RamDisk Pro

[molitar]

But it works fine with FancyCache so something is definitely broken in PrimoCache.

[InquiringMind]

Did you have the same cache size (1GB was mentioned above) with FC? Because CrystalDiskMark defaults to using 1GB data by default and it could be that the cache is not quite large enough to buffer writes fully. To check this, try rerunning Crystal Diskmark with a smaller test size (a good idea with SSDs anyway) like 500MB, or increase cache size to 2GB or so.

[molitar]

Yes same exact settings. in PrimoCache write cache only worked with the LRU logarithm and not with LFU-R. Using LRU it worked in PrimoCache for my SSD drive but than when I tried to use anything smaller than 64KB block size on any of my 4 standard HDD's it would not start. The memory cache amount was absurd too with PrimoCache.

SSD HDD I can enable cache at 4k and only use 116MB of memory. I choose 4k on my standard SATA HDD and it reports 962MB of memory!

As you can see there is severe problem with PrimoCache when it runs fine on 4KB block size though not very fast with FancyCache 0.8.1. I found it works best with testing around 32KB block size for best performance but it DOES work with any block size in FancyCache but not in PrimoCache. BTW I have never used Level -2 cache only Level-1 cache with a 5 second latency and using LFU-R in FancyCache it works fine and write cache works. BTW both C and G have same settings of 1024MB normally but in this picture I changed C temporarily to 2048 to see if I notice much change it boosted my read up another 1000MB on CrystalDiskMark benchmark for read so I will probably leave it at the 2048MB.

[InquiringMind]

SSD HDD I can enable cache at 4k and only use 116MB of memory. I choose 4k on my standard SATA HDD and it reports 962MB of memory!

The (indexing?) overhead is related to disk size, so your figures make sense with your hard disk having 8 times the capacity of your SSD. PrimoCache needs to be able to store blocks from any part of the disk, so its index has to be large enough to cover the whole disk. A bigger block size conversely means fewer blocks to track and a smaller index.

As you can see there is severe problem with PrimoCache when it runs fine on 4KB block size though not very fast with FancyCache 0.8.1. I found it works best with testing around 32KB block size for best performance but it DOES work with any block size in FancyCache but not in PrimoCache.

FancyCache didn't give details of its indexing overheads, but it still had to have them. PrimoCache is clearly doing things differently (and my experiences bear some parallel with yours in terms of block size) but the performance benefits plus the lower memory footprint (with a large block size) make it a good trade-off in my view.

However to get back to the question in my previous post, does CrystalDiskMark give significantly different write results with 500MB data selected?

[molitar]

On the 500MB question I ran a test at 100MB and 500MB results are...

100MB:
Seq Read: 2923
Seq Write: 2316

500MB:
Seq Read: 2918
Seq Write: 1909

1000MB:
Seq Read: 2961
Seq Write: 1827

Wonder why with a 2GB cache that the Write keep getting slower since I am only caching to RAM.

G Drive Test

100MB:
Seq Read: 3198
Seq Write: 2307

500MB:
Seq Read: 3202
Seq Write: 1806

1000MB:
Seq Read: 3186
Seq Write: 2087

Strange I get faster results on the G drive and the only difference is the drive is larger and I have the overcome HDD C1 issue selected that is not selected on the SSD C: Drive. Tests were done back to back so nothing changed like another app open or anything like that.

Paging File:
C:\ drive 256MB
R:\ drive 1024-4096 (RamDisk)
R:\ drive 2048 additional space used for Temp Internet Files and Temp directory

[InquiringMind]

Ah, thanks for taking the time to retest and post the results. Your initial results did state you were using 1GB cache while these mention 2GB cache, so it looks like the cache was too small initially to fully buffer CrystalDiskMark's writes (it repeats each test 5 times by default, so a default test run would involve 4x5x1GB or 20GB of reads and writes).

The C and G drives will be using different caches, so could you confirm that they are using the same configuration? If not, that could explain the different results.

[molitar]

Ah, thanks for taking the time to retest and post the results. Your initial results did state you were using 1GB cache while these mention 2GB cache, so it looks like the cache was too small initially to fully buffer CrystalDiskMark's writes (it repeats each test 5 times by default, so a default test run would involve 4x5x1GB or 20GB of reads and writes).

The C and G drives will be using different caches, so could you confirm that they are using the same configuration? If not, that could explain the different results.

exact same configuration except G drive does not have the Overcome HDD C1 issue checked. Otherwise they are both set the exact same now.. 32K sector size with 2048 MB L1 cache.

Now when I tested with CrystalDiskMark before with only 1024MB I tried with only 100MB, 500MB, and 1000MB and none of them did write work with LFU-R in PrimoCache.. it just would not use write cache at all. But when I changed to just LRU than it worked just fine. I decided on 2048 Cache as I decided to not cache my storage drives just my C drive and G drive which C drive has symbolic links for bigger programs and such on.

[molitar]

I reinstalled PrimoCache and yes write cache is broken with LFU-R.

Couple other things I noted. If I create my SSD drive cache first than I can only cache my standard SATA 1.5TB WD Black HDD with block size of 128kb! But if I create the cache for SATA first than I can create it at 64kb! Now when I create my SATA HDD cache first I can setup my 120GB SSD drive cache with block cache of 32Kkb just fine. Again LFU-R write cache does not work and I have to use LRU. BTW I am only using Level-1 cache.