Romex Software Forum

Hello,

I have the following configuration on my Lenovo x220:

a) 8 GB System Memory (much of it unused in my Windows 7 x64 installation - I have set Paging to 0 MB)
b) 20 GB SLC Intel 311 SSD (mSATA) - SLC so it can withstand write cycles better than MLC
c) 320 GB SATA 3Gbps 7200 rpm drive.

My disk partition looks like:

Disk 0 [Basic, 298 GB, Online]:
SYSTEM_DRV , 1.17 GB NTFS, Healthy (System, Active, Primary Partition)
Windows7_OS (C:) 287 GB NTFS, Healthy (Boot, Crash Dump, Primary Partition)
Lenovo_Recovery (Q:) 9.8 GB NTFS, Healthy (Primary Partition)

Disk 1 [Basic, 19 GB, Online]:
Cache (R:) 19 GB NTFS, Healthy (Primary Partition)

My FancyCache settings are basically set to the default except I use the MBU with the SLC SSD:

FancyCache Configuration;

Cache C: only
Block Size: 8kB
Cache Size (level 1): 2048 MB
Algorithm: LFU-R
Caching Strategy: R/W
Enable Defer Write: [ ]
Release After Write: [ ]
No Write-Flush At Shutdown (!): [ ]

Enable Level-2 Cache: [X]
Size: 6400 MB
Algorithm: MBU
Invisible Memory: No
SSD/Flash/Other: [R:]

My Goals are:

a. Three Level Hybrid SSD/HDD Storage; 2 GB L1 in System Memory, 20 GB L2 in SLC SSD, 320 GB in HDD, similar to the Intel RST / Nvelo Dataplex solution.

b. Efficient use of the SLC SSD without worrying about write/read cycles.

My questions are:

1. Do I need to worry about other built-in windows mechanisms like: SuperFetch, ReadyBoost, ReadyBoot, PreFetcher, etc. - is there a list of competing/conflicting technologies in Windows 7 x64 and a way to check that they are really disabled if need be?

2. What are the configuration suggestions for the SLC SSD?

3. Although L2 Persistence is a nice feature being developed for boot up, I was wondering how early FancyCache is introduced during boot up. If it's too late it may not be useful for fast boot, correct?

4. Is L1 Persistence being worked on as well?

Thank you! I think with all the activity with Intel's SRT and Nvelo's Dataplex this product is in the right place at the right time.

hroth

Sorry, I forgot to answer this post.

hroth wrote:1. Do I need to worry about other built-in windows mechanisms like: SuperFetch, ReadyBoost, ReadyBoot, PreFetcher, etc. - is there a list of competing/conflicting technologies in Windows 7 x64 and a way to check that they are really disabled if need be?

There shall be no conflicts with built-in windows mechanisms.

hroth wrote:2. What are the configuration suggestions for the SLC SSD?

I think you may try "LBW" L2 cache algorithm if you use SSD as L2 cache. This algorithm can reduce write amount on SSD.

Thanks for the reply!

I don't mind more writes to the SLC SSD; it's made to be written to compared to an MLC.

Also, I upgraded to 16GB of DDR3 memory; 9 GB to FancyCache. It's very fast.

How does FancyCache interact with the built-in Windows File Cache? I did a brief experiment; I loaded Word, Excel, etc. and then stopped fancycaching and restarted. They still started very quickly without "reading bytes" (according to the Performance Monitor).

That means they were in Windows File Cache and we didn't have to go out to disk. I suppose this is fine except I don't know a way to control the Windows File Cache size. Registry edits?

Is there an optimal tradeoff between Windows File Cache size and FancyCache size?

I started reading the Windows Internals 5/e book by Russinovich et al and realized the tradeoff question is not easy to answer; it depends on the user behavior, system memory, and the version of Windows!

With Windows Internals and RAMMap (http://technet.microsoft.com/en-us/sysi ... s/ff700229) it is a lot clearer to guide your settings.

Here's my research so far. Windows 7 SuperFetch replaces utilities like eBoostr and should grow perpetually, at least to a nominal user's habits. Where it excels is programs that use the same *files* over and over again. I think it has a lot of (hidden) heuristics on how to choose which file to cache, but we can assume it's at least similar to LRU.

FancyCache supplements this with *block* level caching. One instance (shown on Romex' web site) is where you want to cache only a certain volume or disk. Another instance is a file or raw disk I/O that SuperFetch cannot or will not handle. That's why on folks' benchmarks FancyCache does so well; I'm presuming SuperFetch doesn't cache any of the CrystalDiskMark payload.

For example with:
http://www.compuhento.com/2011/10/under ... s-ram.html
http://www.compuhento.com/2011/11/fancy ... drive.html

(Especially the YouTube video on the second post) hentosama demonstrates faster reloading of files on an 8GB XP 64bit system with 2GB R/W FancyCache. My caveat is that XP-64 doesn't have Windows 7 SuperFetch - it would be interesting to see a similar showdown there as hentosama hints that performance is similar; given that you give Windows 7 enough RAM.

I'm assuming everyone has at least 8GB of DDR3 for a modern system. At $19 for 8GB this is a no-brainer.

So the current research shows optimal settings are:

For Windows 7. SuperFetch has gotten a lot smarter in Windows 7, so it's best to keep that on.

i. So with the Registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"DisablePagingExecutive"=dword:00000000
"LargeSystemCache"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters]
"EnableSuperfetch"=dword:00000003
"EnablePrefetcher"=dword:00000003

ii. To take care of the occasional disk I/O and pad your SSD with deferred writes:

With 16GB, set FancyCache to 4GB (12GB for programs+SuperFetch)
With 8GB, set FancyCache to 2GB (6GB for programs+SuperFetch)

iii. Future research - would be interesting to see how FancyCache competes directly against SuperFetch but SuperFetch is doing a decent job (if it ain't broke...)

Similar to this analysis of how eBoostr competes against SuperFetch.. I think understanding how SuperFetch chooses files is again key.

http://www.ocztechnologyforum.com/forum ... Superfetch

It looks like eBoostr is no longer supported or developed; perhaps it's a wash against SuperFetch. The eBoostr heuristic is found here:

http://dotnet.agilekiwi.com/blog/2008/1 ... works.html

Hope that helps someone starting out...

The only question I have remaining is why we set FancyCache to 4kB block sizes. I know that reflects the volume/disk block size but I would think there would be advantages to reduce overhead with larger block sizes. Could someone point me to the forum message where Romex started to advocate 4kB block sizes for maximum performance?