write cache not working with RamDisk Pro

[molitar]

I have Primo Ramdisk Pro and I had it configured with FancyCache but when I installed PrimoCache it did not upgrade or overwrite the FancyCache so I lost my configuration. I do not see examples in the online tutorial since the whole interface has changed on how best to use the two with my SSD drive I wanting to use the 6GB Direct-IO cache I am using to make the 1GB cache for the PrimoCache with deferred writes to eliminate so much writing to the SSD drive.

Before there was a good tutorial on how to configure the two together but with interface change I am not sure how to go about this now to accomplish this. I have noticed a severe slow down and did not realize until recently that FancyCache had expired and that was the cause of my slow down. So can someone please help me with how to best configure this with RamDisk?

[InquiringMind]

I'm running both and, aside from deciding how to split memory between them, there's not really any complications involved in running them together (I would suggest a 50/50 memory split, unless you have specific reason to allocate more to one product).

If you have not already done so, uninstall FancyCache to minimise the chance of it conflicting with PrimoCache (as a general rule, it is better to uninstall when dealing with beta software). If you have already installed PrimoCache, I'd suggest uninstalling it, uninstalling FC and then reinstalling PrimoCache.

The biggest differences between PrimoCache and the previous FancyCache are:

• The settings dialog box needs to have its first item (the listbox showing the reason for using caching) set to Custom to allow you to modify all the other settings as you please.
• PrimoCache can use IM (Invisible Memory) exclusively for caching - a big benefit for 32-bit Windows users (who should set IM memory usage to whatever is available and main memory usage to 0). However indexes are kept in main memory and you will need to set a larger block size (new to PrimoCache, I found 64KB best for a 7GB cache) to minimise overhead here. The default (4KB) size won't even allow you to start a large cache on 32-bit systems.
• Write-Defer needs to be enabled to maximise write speeds, but be aware it can increase the chance of data loss (see the System fast, but unstable and Registry Corrruption threads for examples). If you do enable it, keep the write delay short (seconds rather than minutes and definitely minutes rather than hours).
• Use a quick, simple benchmark (like Crystal Diskmark) to check that your settings are the best for your system.

[molitar]

Ok so with 12GB of memory are you saying make a 6GB RamDisk and a 6GB PrimoCache? I currently do have a 6GB RamDisk. On defer write what have people found to be reliable? 10 seconds been quite reliable or should I make it a bit less than that?

Current config:

12GB RAM
4GB - 6GB RamDisk (Direct-IO)

For a test I setup the config as read performance > level 1 cache 1024 MB > 16KB

Read: 3180 MB/s
Write: 146.7 MB/s

My write speeds suck worse than having cache off as I have a 120GB SSD for my C drive.

If I set the cache to write defaults with > 1024 cache > 16KB

Read: 3121
Write: 142.4 MB/s

As you can see Crystal Disk test seems to have no performance in write at all.

[InquiringMind]

Re-reading your initial post, you mention using Primo Ramdisk to hold the L2 cache for Primo Cache - don't do this, just forget about L2 caching and have a large L1 cache. The suggested 50/50 split would seem a good place to start, but (if using a 64-bit version of Windows) you should calculate your highest memory usage (run your most demanding programs and use Task Manager to check memory usage, or better yet use Process Explorer or Process Hacker to monitor memory usage for a while and check their peak figures). Add another 10-20% to this to allow for future needs and then split the remainder between Primo Ramdisk and Primo Cache.

So if your peak memory usage was 3.5GB, round that up to 4GB which would then leave 8GB to allocate to cache and ramdisk (a 50/50 split would mean 4GB each, which should be fine unless you need a bigger ramdisk).

If you're running a 32-bit version of Windows, then things are simpler - use Invisible Memory only and all of it (nothing else can use it).

As I noted above, don't set Primo Cache's first setting to read or write, set it to Custom instead - that allows you to change everything else (if set to Read, Defer Write is tricky to enable). You will need to set Defer Write to see any major boost in write speeds, but keep the duration low if you do.

[molitar]

Well I still can't get write to work.. it's at a lousy 149MB/s on an SSD drive.. I have my Temp directory and paging file set to 6GB of my 12GB of memory that I have. I set up a 1024 MB cache for drive C (SSD) and when it does a write it's no different with our without. Write cache is not working at all.

BTW I even tried just write mode. Also the system will not let me select smaller block size than 4KB even though I have 6GB of free memory.

Ok found the problem to be LRU-F default option sucks write cache totally broken with it.

[InquiringMind]

Use the "custom" setting as suggested twice previously, and you should be able to set up the cache as you please. The other options (read and write) both restrict certain choices.

The performance figures I posted in the Benchmarking PrimoCache thread were obtained with LFU-R. Write defer setting and a large blocksize (64KB in my case) seem to be the most important factors in write performance.

4KB is the smallest blocksize available - there is no point in having a blocksize smaller than NTFS' cluster size, and that is 4KB by default.

[molitar]

Sorry should of specified better I can not choose anything but 64KB for the non SSD HDD's with PrimoCache but when I went back to FancyCache no problem it's a bug with PrimoCache so I reported it.

[InquiringMind]

If you're running a 32-bit OS, then there will be restrictions on smaller blocksizes depending on your cache settings (I need 16KB+ blocksize with a 7GB cache). That's because the reported "overhead" (which I presume is the indexing for the cache) uses conventional memory, so cannot exceed the 3.25GB limit (minus existing memory usage).

Given that PrimoCache can use invisible memory exclusively for its cache (FancyCache required 256-1024MB of main memory as L1 to provide anything close to full performance) I'd consider the trade-off a good one (PrimoCache is twice as fast on my system than FancyCache, with less system memory used), but the blocksize issue could be better highlighted in PrimoCache's UI and the error messages resulting from a too-small blocksize need to be more informative.

[molitar]

My kernel is patched so my OS sees the entire 12GB of memory and uses it.

[InquiringMind]

My kernel is patched so my OS sees the entire 12GB of memory and uses it.

I've read the thread discussing the patching, and things aren't likely to be so simple.

While it is possible to increase the total amount of memory usable (up to the PAE limit of 64GB) by such patching, limits still exist on each process (2GB each, unless you use the /3GB or /userva boot.ini flags to adjust them, though increasing the limit to 3GB will reduce the memory addressable by PAE to 16GB). There are ways to exceed that limit like AWE (Address Windowing Extensions) but that has to be coded in by the application developer.

Since it does involve memory management though, it would be sensible to try running without the kernel patch to see if it makes any difference.