Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

FAQ, getting help, user experience about PrimoCache
BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

OK. I've started a few threads seeking guidance since I joined.

I've been using PrimoCache since July, 2014, on a cumulative five systems, four desktops and a laptop. This was with license for four PCs, but I had to transfer the license once from a dead computer to a new one. Romex knows all about it if they archive their customer-support-requests.

I've learned a lot more about the program over the last few months in comparison to the ~80 days of trial plus the longest-running license or oldest purchase-date.

I think you could put computers into generally-accepted categories according to function and usage. "General Purpose Workstation" would include some mix of rendering, gaming, media access, and day-to-day applications. "Laptops" have special or more restrictive limitations, so make an interesting case. "Server" is another situation, and Romex offers a Win Server 2008/2012/etc. compatible license.

So I'm thinking folks could describe their usage-pattern, and explain how PrimoCache works for you, with attention to the various settings and why you chose them.

This might in turn help people who are looking at the program and unsure as to wanting it, needing it, if they can use it, or especially -- how they may best use it.

I could post my own configurations later, if people think this is a worthwhile idea. Well, here goes -- "Submit" --

SuliTuli
Level 1
Level 1
Posts: 2
Joined: Wed Apr 05, 2017 7:28 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by SuliTuli »

Hi.

This is exactly the thread I was looking for =)

I would like to post my setup here and seek for advice and guidance.

I have a workstation where I run some CPU and memory intensive programs, I also use that workstation for occasional video editing and gaming.

My OS, programs and video editing tools are installed on my 1TB Samsung 960 EVO M.2. My games, however, are installed on my 4TB WD Black HDD. I have 32GB Hyper X Predator 3000MHz DDR4 RAM.

I have added both the M.2 NVMe SSD and the HDD into the same Cache task and assigned some settings with the guidance of the website. I have created a 50GB volume on my SSD and assigned that to L2 cache. I also chose 8GB of RAM for the setup. I am not sure if I have done it all correctly, and if my system would or should benefit from this setup at all.

Oh MemoryPros, please assist me with this quest of seeking enlightenment =P

Here are screenshots of my settings and the stats of each of the drives:

Settings
Image

SSD
Image

HDD
Image

BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

Well, SuliTuli, I'm glad the idea drew your interest. With other things on my plate, I don't have screenies to post today, but I'll respond.

I've had to navigate a configuration that's just a bit more complex for being a dual-boot setup -- Win7 and Win10. In this, I discovered that my new chipset -- Z170 -- won't allow successful backup to my WHS-2011 server (to be replaced eventually with new hardware and Win 2012 R2 Essentials). I discovered that Macrium Reflect allows backup to a network drive under windows 10 for all the OS partitions. So that problem was resolved.

I wanted to have L2 cache defined for both OSes, but ran into trouble. There's another thread about that. It may still be possible, but I can "let go" of that ambition for Windows 7. So here's what I have, that works.

The only cache arrangement for the 960 Pro (either Win 7 or Win 10) is L1 on my Z170 Skylake system. Which brings me to your description: Why are you caching the 960 Pro "C :" drive to itself? Totally unnecessary! I think you should only create a separate caching task for that, using L1 or RAM caching.

Then, define a second caching task for the HDD WD Black. Now -- here's where I myself ran into some trouble for using both L1 and L2. The L2 was created as 100 GB partition on the 960 Pro for an HDD and any other SATA SSDs or HDDs I might add to the system. It also had an L1 cache, and for some reason, I would generate some correctable disk errors on the HDD after a software installation that was probably in the magnitude of maybe 40GB. I think it happened about twice, and Macrium would fail its daily backup. Running CHKDSK through Windows 10 corrected these errors. After I deleted the L1 cache for the HDD (and etc.), I had no more errors on the HDD.

So, with 16GB of RAM, I set up 4,096 MB of RAM for the 960-Pro (boot-system volume) and no L2, and the 100GB SSD-cache L2 with no L1 for the HDD.

Of course, the size of your L1 cache should be mindful of the size of files you access, and I wouldn't store video captures or similar files on that cached disk: it doesn't need it.

At this point, I don't allow deferred writes for either caching task, just for safety. But I have the C : drive 960 Pro (Windows 10) configured to Prefetch the previous cache after a Restart, to start at Windows boot-time. Nothing like that is needed for the SSD-cached HDD (the 960 Pro provides a 100GB volume for that) -- because it is persistent cache.

Of course, the size of L1 will depend on the amount of RAM you can afford to allocate to it. The size of the L2 would be tempered by the amount of overhead in RAM needed, and you would of course use a bigger block size to reduce that overhead. I've discovered, even in gaming, I have piles of RAM unused after the 4,096 MB L1 cache. And if I could only benchmark the SSD-caching of the HDD, I would know just what advantage it affords. Even so, the hit-rate should be some indication. If the 960 Pro seq-read bench shows ~3,500 MB/s, you might expect to accelerate an HDD to between 60 and 80% of that. Of course, the 960 Pro may not show a full 3,500 MB/s, so your guesstimate may be lower. Yet, it would probably increase the effective read-rate for a 150 MB/s HDD by a factor of 10. That's just my best guess.

I've been looking at the prospect of buying a 2TB Crucial MX300 to supplement my 960 Pro. I have the budget for it. I'm just not in a hurry to pull the checkout-string, because I don't have any "hourglass" moments with my Seagate Barracuda.

SuliTuli
Level 1
Level 1
Posts: 2
Joined: Wed Apr 05, 2017 7:28 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by SuliTuli »

Hi BonzaiDuck,

Thanks for your reply, I have read it through carefully. Based on what you explained, I have made changes. Also made screenies to reflect these changes =)))

Here is what I did:

I deleted the HDD from the single cache task I had set with both drives in it and assigned the following settings to the task which now includes only the SSD:

Image

I then created a new cache task for my HDD with the following settings:

Image

The SSD then has these stats after the change:

Image

And the HDD has these stats:

Image


Basically with my previous setup, I had 20GB of RAM used usually, so I do have the RAM to spare for all these cache tasks, even when gaming and running some programs. I did enable defer-write on the SSD because I never have any blackouts nor PC problems, and I rarely am writing anything significant onto the SSD.

Again, thanks for your reply, let me know if you notice any fault in the changes I made.

All the best!

BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

That appears to be identical to what I did. I can only say that it worked without missing a stitch for the months configured. I discovered only a LIKELY problem of using the L1 and L2 simultaneously on an HDD. Even the HDD could contribute partially to causes of the minor errors discovered by chkdsk, because it has a 128MB cache of its own -- a compensation for other factors in design.

It seems better to follow the KISS principle and keep it simple. I have not had any disk errors since I began doing it that way.

I'm also just clueless about some simple mathematics or 2D graphs explaining the relationship between some pattern of usage, file sizes within the OS and the turnover rate in the cache. I say this because you must have something like a 2x16 32GB memory kit. I added 2x2 4GB to a system that had 16 for a total of 20GB. I intended to use the extra RAM for working with PrimoCache. That 2700K / Z68-Gen3 system follows much the same approach I've used with the Skylake 6700K / Z170 system. It gives me cable-premium channels and all other content through my SiliconDust network tuners 24/7 -- we're making bets on when the 42" LG HDTV finally dies, but no sign of any change since we bought it. The Sandy Bridge system hasn't missed a lick, and I use it for a lot of other computing tasks.

The latest trouble -- something I could report in a separate thread -- arises with trying to upgrade Windows 10 Build 1607 to 1703. It is possible that the PrimoCache-formatted caching-volume on an SSD (SATA or NVMe) confuses the installer, and generates some sweaty misery until you see how it might be a problem. There is a utility named EasyBCD for fixing boot config data for systems with boot-problems. IT will throw an error screen with a fairly verbose presentation of drive enumeration data, and it extends beyond the bottom of a 1080p Windows screen so that it can be neither scrolled or moved. It must be terminated through Task Manager.

Once you delete the PRimo caching volume and "ghosted" drives shown in Device Manager "Disk Drives,*" EasyBCD functions properly. The solution, barring problems with other causes that interfere with OS upgrades, is probably to delete the caching volume when making these sorts of OS Build upgrades after deleting the caching task itself. Then after the upgrade, you would create a new basic simple volume on the caching SSD and configure it to be reformatted by PrimoCache for L2 usage and start over. These are minor setbacks because a cache could hold a lot of content speeding up numerous applications; you have to re-establish the cache as you follow any of some profiles for using your computer.

For an SSD, this increases the accumulating TBW until failure some 10 years later. But one might only do it a couple times a year, otherwise. There is also the loss of TRIM until Romex releases the rumored version 3. So replacing the cache volume from time to time is probably a good idea for that reason as well.

* In DM, highlight "Disk Drives" and in "View" from the title menu select "Show hidden devices." You may find these ghosted devices from hardware you had connected recently like a USB external drive, a USB flash drive, or some hard disk or ssd you recently swapped out of the system. Uninstall or delete them.

BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

EXPENSIVE EXPERIMENTS in an Update to this thread:

RAM -- the original kit was a G.SKILL F4-3200C14D-16GTZ TridentZ 14-14-14-34 kit -- 2x8GB = 16GB. The advice that G.SKILL, fellow enthusiasts and I myself offer discourages adding a second kit of the same RAM model and size in favor of replacement with a 2x16=32GB F4-3200C14D-32GTZ kit. That would mean spending ~$385 in addition to the original ~$180 -- either putting aside the 2x8 kit or selling them used. Adding a second kit of the same means an outlay of only ~$180 and continued use of the original kit.

Penny-pincher that I've been this month, I decided to risk buying the second 2x8 kit. Lo' and Behold! They run at 3,200 Mhz 14-14-14 with no changes to VCORE or VDIMM (XMP 1.35V), and only a 30mV increase in VCCIO from the "Auto" range of 1.51--1.62V to 1.82V. Rock-solid. No problems resetting the CPU clock speed back to the OC setting of 4.7Ghz.

I also had a spare 960-EVO 256GB M.2 NVME drive fitted to a Kryo-M.2 PCIE card and heatsink. Who needs SLI for graphics with a GTX-1070? Not I, so I put it into the second PCIE x16/x8 slot. Impact on the graphics card is only a 1% degradation in performance, and it's OC'd already to core 2,000Mhz and memory 4,400 Mhz. I decided to use the entire EVO for caching.

I replaced a Seagate Barracuda 2TB 5,400 rpm spinner with a Crucial MX300 2TB SATA SSD. As a person with a hardware addiction problem, I justified the $500+ on the Crucial as a convenient allocation of savings on the RAM.

I've now cached the original NVMe 960-Pro System-Boot volume to 12GB of the RAM, and the Crucial is cached to the NVMe EVO. Sooner or later, I may see what things are like caching the Crucial exclusively to RAM like the NVME Pro drive. Plenty of RAM to go around, unless I change my usage profile.

But! Everything proves out Rock Stable with HCI Memtest-64 Pro, LinX, IntelBurnTest and ASUS ROG RealBench. I think I can even tighten the RAM command-rate to 1.

At this point, the performance is phenomenal, although hard to notice except through benchmarks.

When will PrimoCache 3.0 be released? And should I try the BETA if I'm using this monster for regular work as well as gaming?

Folks! This is what you call "Techno-Lust!" And lust -- after all -- is an addiction!

BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

Here is a thought that needs proving or verification, but I've not found a further explanation for it.

I use Macrium Reflect [workstation] v.7 as "most-trusted disk utility" and as scheduled backup. Our workstations are backed up to a WHS-2011 (Server 2008 R2) system nightly. If the server OS allows automated backup of Windows 10 machines, the resolution to make it so is way too troublesome, or it doesn't even work. You might be able to use Win 10 backup to put it's files on a shared volume, but the backup schedule would be run from the workstation -- not the server. I chose to use Macrium instead, keeping "full," "differential" and "incremental" backup files, and managing them according to available disk space.

Of course, the local backup volume and physical disk is not cached. A source drive had been cached to both L1 and L2. Every so often and too frequently, the Macrium backup would fail, pointing to errors needing correction with CHKDSK. There was nothing wrong with the source disk; nothing wrong with the RAM; nothing wrong with the caching SSD. I discontinued the L1 caching of the source drive, so that it is only cached to L2.

The problem went away. I wouldn't know whether this issue might have been addressed in the Beta, or whether it even was. It would not be a responsibility of Macrium to correct it. But veterans here at Romex attest to L1 and L2 working just fine -- together, for the same disk or disks -- without other software complications. They show no indication of using Macrium. Maybe they are using Windows Backup; I couldn't say.

So it may be true that using additional, other software can limit your configuration options under Primo Cache.

rutra80
Level 5
Level 5
Posts: 57
Joined: Fri Aug 14, 2015 9:10 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by rutra80 »

Doesn't using L1 RAM cache for reads seem wasteful? Windows uses free memory for file system buffer so anything you reread will be fetched from RAM anyway. Since PrimoCache v3 I set L1 RAM cache to 100%-write so it is used for deferred writes only, and L2 SSD cache to shared read/write.

BonzaiDuck
Level 6
Level 6
Posts: 79
Joined: Wed Jan 11, 2017 12:57 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by BonzaiDuck »

rutra80 wrote:Doesn't using L1 RAM cache for reads seem wasteful? Windows uses free memory for file system buffer so anything you reread will be fetched from RAM anyway. Since PrimoCache v3 I set L1 RAM cache to 100%-write so it is used for deferred writes only, and L2 SSD cache to shared read/write.
Interesting idea, and I may want to give it a try. If you are correct in your first sentence, the significance of it would be greater with systems fitted with less memory.

Hodor
Level 2
Level 2
Posts: 6
Joined: Mon Mar 19, 2018 2:24 am

Re: Somthing toward a "sticky:" Suggestiion for a configuration discussion for various PC usage patterns

Post by Hodor »

rutra80 wrote:Doesn't using L1 RAM cache for reads seem wasteful? Windows uses free memory for file system buffer so anything you reread will be fetched from RAM anyway. Since PrimoCache v3 I set L1 RAM cache to 100%-write so it is used for deferred writes only, and L2 SSD cache to shared read/write.
I see it the same way. I use a small 384MB write-only L1 cache because Windows' memory manager already functions as a read cache. Using L1 as a both read/write cache typically causes write data to be flushed too often in my experience.

I only accelerate my gaming HDD though. The smallish write cache is quite big enough to handle Steam/Origin/uPlay client updates and most game updates tend to be on the smaller side anyway. Larger patches can then overflow onto the SSD cache where necessary.

I would also love to see a specific subforum for guides. My use case would obviously be quite different from someone else's, for example, as mine is quite dependent on bandwidth.

Post Reply