Bad-ass Caching SSD+HDD through NVMe 960 EVO 250GB

[BonzaiDuck]

"The east . . and the west . . . are mine . . The north . . . and the south . . . are mine . . . . All seems beautiful to me . . . "

So goes the VOLVO commercial. And so goes my car-racing simulations and anything else. This system smokes, man! I think I want to smoke something to celebrate! Real street-racing is illegal, but now we have Proposition 64 in California.

We-ull, Pilgrims! My project was a rave success! Mr. Spock? Warp Speed! Aye, aye, Captain Kirk! Engage NVMe drive!

INGREDIENTS: PrimoCache from Romex, Windows 7 64-bit SP1, 250GB 960 EVO NVMe in a Lycom PCI-E card and x4 slot, DDR4-3200 RAM, SATA SSD boot-system disk, SATA HDD "programs and data" disk.

I only created a single 100GB volume on the NVMe and converted it to Primo's caching volume.

There is only a single caching task: caching to 2GB of RAM is shared between SATA devices; the NVMe caching volume is shared between the same SATA devices. The SATAs are written to the NVMe, and the NVMe is written to the 2GB of RAM.

Using the 1GB test, here's the Anvil Benchmark for the HDD with deferred-writes disabled:

Same test with deferred-writes enabled:

And here's the Anvil Benchmark for the boot-system SSD -- no deferred writes:

Here's the same boot-system SATA SSD with deferred-writes enabled:

So that's it! I've reduced RAM usage by about 28% of the total. The storage overhead is mere megabytes owing to larger 32KB block sizes (Primo chose this for me; I might have selected 4KB blocks). Instead of using 4GB of RAM for caching, I only use 2GB.

Looks like I have no urgent need to double my 16GB of TridentZ!

And . . . like the HAL computer in "2001," "Dave? I can feel it! I can feel it, Dave! My mind is growing . . . My mind is growing!"

I don't see any reason to get a 1TB 960 Pro M.2 right now. This little 250GB EVO does the job!

I should benchtest the EVO by itself, which I'll do when I'm setting up the caching volume for the Windows 10 disk volumes. These screenies were taken from my Win 7 installation using Samsung's own NVMe driver.

But this is a helluva lot better than using an SATA SSD to cache the HDD.

Here are the other parts: Seagate 2.5" 2TB Barracuda with 128MB of onboard cache; ADATA SP550 SSD for the boot-system disk.

This is going to be BAD!!! I mean Ba-ba-ba-BA-a-a-UD! Bad to the bone! That is, it is good! I have been to the mountain! And the mountain is good!


Now there's going to be all sorts of skepticism about this, it was always a matter of what "floated your boat" when ISRT came along with the Z68 chipset. But forget the benchmarks! I can feel it! I can feel it! My mind is growing!

 

[XavierMace]

Bump up your test size and see if it's still so impressive. We had this conversation the last caching thread you had.

 

[BonzaiDuck]

Bump up your test size and see if it's still so impressive. We had this conversation the last caching thread you had.

Actually, I'll do that again -- and I did it before.

I observed that the sequential read test takes a hit. Other parts of the benchmark were much better, nor can I remember if any of these other file-size tests and queue-depths were even worse than the 1GB test.

On the upside, I can feel it! I can't believe it's a "placebo effect" sort of thing. Even web-pages load faster. It adds speed to gaming so that virtual reality is downright scary.

I have all my games on the spinner.

Now I've installed the version of Magician from the same download page offering the EVO driver.

So far today, on the 100GB caching volume, I've written 200 GB. At this rate, I would write 73 TB in a year's time. And I'm guessing that I would need to replace the drive or use a new storage strategy after about 5 years. It could be longer -- it could be less.

I think the forum also had a conversation about the "need for speed" and what mainstream users and even a good share of enthusiasts aren't likely to miss: the difference between NVMe performance and SATA performance.

But I've been tweaking this system for the good part of four months. It has been a daily ongoing preoccupation. And I can tell you -- I can feel it. It is profound.

I think it's also time to treat myself to a new keyboard and mouse. And maybe save some bucks while I watch the NVMe prices drop.

 

[XavierMace]

If you did, you never posted in the thread I was thinking of: https://forums.anandtech.com/thread...on-6700k-z170-sata-ssd.2488917/#post-38522033



Regarding this recent data though, what all have you done on your computer today? Because unless you've installed some games, that write rate sounds extremely high. I purchased a 512Gb SSD for my desktop on Nov 7th 2014. I've installed a variety of games since then as well as at least 1 clean windows install. I'm at 9.8TB written. If Primo is doing an excessive amount of swapping, that would greatly concern me. What does your SMART data show for it's lifetime used? This is something any consumer should think about before using SSD's for caching. It's going to get worn out far faster than normal. For example in my SAN, I've got MX100's for both the boot drive and the "cache" drive. I've used 4% of the life of the boot drive. I've used 105% of the life of the "cache" drive in the same time period (19,000 hours).

 

[BonzaiDuck]

If you did, you never posted in the thread I was thinking of: https://forums.anandtech.com/thread...on-6700k-z170-sata-ssd.2488917/#post-38522033



Regarding this recent data though, what all have you done on your computer today? Because unless you've installed some games, that write rate sounds extremely high. I purchased a 512Gb SSD for my desktop on Nov 7th 2014. I've installed a variety of games since then as well as at least 1 clean windows install. I'm at 9.8TB written. If Primo is doing an excessive amount of swapping, that would greatly concern me. What does your SMART data show for it's lifetime used? This is something any consumer should think about before using SSD's for caching. It's going to get worn out far faster than normal. For example in my SAN, I've got MX100's for both the boot drive and the "cache" drive. I've used 4% of the life of the boot drive. I've used 105% of the life of the "cache" drive in the same time period (19,000 hours).

First, here's the Samsung performance test of a second 100GB volume on the 960 EVO:

If they touted the drive at ~1,900 MB/s write-rate, it seems to fall short. I'd have to go back and see precisely what those specs were, because I think I'd also seen something more like 1,500.

I should probably check the 60GB caching volume on my other system -- built in late 2014. If the bundled software like Magician, Storage Executive, ADATA Toolbox or the Intel program provide TBW tracking, it should be installed. All of my boot-system disks are SSDs in this house. I think they're all under 10 TBW. I should check my 840 Pro upstairs.

Here are the 2GB test-size results for the HDD and SSD boot-volume:

So again, yes, the larger test-size really falls down on the first sequential test, but of course this is a cached HDD. The other benchmarks are still up there. Also, I think that the amount of writes I've done since installing the NVMe several hours ago may be initially high. If what I do tomorrow is similar to what I did today, the amount of writes should be less.

Assuming we treat these devices as something consumed to be thrown away, you'd have to ask how much you come out ahead or behind simply using the NVMe as regular storage or boot-system.

I haven't uploaded the SSD boot-volume result yet, but I can say that the hit it takes to the first sequential read test comparing to the 1GB test-size still leaves it showing closer to double the spec read-rate. I think it's something like 960 MB/s.

Using the deferred-writes feature really pumps up the write-test results. On the one hand, we dismiss these tests as "synthetic benchmarks." Then we concern ourselves about one test that might show MB/s less than the HDD spec. Taken all in all, though, I only see performance gains with no net losses. Of course, we're also talking about use-life or life-span and the initial outlay in dollars.

We're certainly eager to see what NVMe M.2 entries appear over the next year from Crucial and the other SSD-makers. I can't make any reasonable speculation as to whether I get my money's-worth on this 250GB EVO, although what it does for the slower devices and their own lifespans is definitely positive. I suppose I'd have to set up a spreadsheet and do some cost-accounting.

But if I could take this system to the county fair tomorrow for some contest, I'd be fairly optimistic even if it didn't win the "blue" ribbon.

I'd be curious to see what happens with a 32GB TridentZ kit. But that's more money to spend.

 

[XavierMace]

2Gb is still only matching your cache, so the fact that the sequential read and any writes have already fallen flat on it's face is perplexing to say the least. That's straight spindle speed. Bump it up another notch and see what you get. Based on your previous screenshot and previous discussions, the way I understand it, < 2Gb should just be hitting your L1 (RAM) cache, then it should fall back to your L2 (SSD) cache , then you'd be hitting the spindles. If that's the case, there something wrong with those results (or Primo) as with a 2Gb test file, that shouldn't be hitting spindles which it clearly is when doing the sequential test as that's far too slow to be RAM or SSD even if only partially. The rest of the benchmarks are clearly only hitting RAM so really all that's doing is giving you a RAM benchmark.

That's a VM running off my RAID-Z2 ZFS array (with a failing ZIL, lol) of 7200rpm spinners which it's sharing with other running VM's. At no point in time should that EVER be faster than your setup, yet it's sequential reads is 4x. Something doesn't add up there.

Edit: Looking again at your original screenshots, your deferred write results also don't make sense. With deferred writes enabled, that's purely a RAM benchmark on the writes as well at which point those throughput numbers are far lower than it should be given the speed of your RAM.

 

[XavierMace]

Just for giggles, I went ahead and downloaded the PrimoCache trial to see if I could replicate those oddities. I left all the cache settings at whatever it defaulted to.

Given your DDR4-3200 vs my servers ECC DDR3-1333 (plus it's running in a VM vs bare metal), your RAM benchmarks are 3x-5x higher pretty much as I'd suspect. But I'm not seeing it tank when I match the test size to the cache size.

 

[BonzaiDuck]

Just for giggles, I went ahead and downloaded the PrimoCache trial to see if I could replicate those oddities. I left all the cache settings at whatever it defaulted to.

Given your DDR4-3200 vs my servers ECC DDR3-1333 (plus it's running in a VM vs bare metal), your RAM benchmarks are 3x-5x higher pretty much as I'd suspect. But I'm not seeing it tank when I match the test size to the cache size.

Here's the same 2GB test applied to the C: drive or boot-system SSD:

I'm keeping an "open mind" about all this, but it seems to be working as I'd hoped. I can barely read your screenies' small print, but it looks as though you used 2GB and 4GB tests. I'm going to kick up my RAM-cache size to 3GB and see what happens with the 2GB or even a 4GB test.

On the matter of TBW, it may be of equal importance that user habits, preoccupations and other factors determine how much "new stuff" is written to the cache daily. It also matters how many times the user deletes the caching task and re-creates it, or makes changes to the Primo configuration requiring the cache contents to be rebuilt by reading again from the slower devices and refreshing the cache.

I've been gaming a lot in the wee hours since I began this thread. I'm still at 200GB of TBW since I installed and configured the M.2 NVMe.

As much as I'm pleased so far with the results, anticipating that less RAM would be needed to get good benchies, and as much as I'm doing this to avoid "spending too much" with the initial release of the 960 Pro and EVO models, one could spend more and double the size of system RAM to 32GB. That's way more than I need for this and for non-caching purposes. So let me run these additional tests . . . upload them and post them here.

I remember a TV commercial for the Potomac Mills shopping mall in Virginia. Wild-eyed housewife steps up to the camera with a pair of boots in one hand and a mink stole in the other: "You see?! I saved 50% [the boots]; I saved 50% [the mink stole] -- I saved 100%!"

At least I'm not building the Maximum PC Dream Machine of the Year . . . .

Another thing --- I suspect there is an expansion card which holds 1x NVMe and 2x SATA M.2 cards, but it's a PCI-E x4 card. Depends on my priorities, but if I could put two NVMe drives on the same card, nothing would be wasted when I eventually spring for a large 960 Pro/EVO. I'm just wondering if it would require an x8 card . . . .

A PCI-E M.2 card nominally costs about $20, and I have two. If I spring for a larger drive to use both conventionally and with this caching, I can always put what's left of the 250GB EVO in another system that (hopefully) offers PCI-E 3.0.

 

[BonzaiDuck]

Here's the 4GB RAM-cache configuration with the 2GB test:

This is -- again -- the E:-drive spinner. I will go back and read again some observations XavierMace made, but I'm wondering how much my "cache-everything" approach of a single caching task affects this: the SSD and HDD share the RAM cache, whereas different tasks defined on those disks would allocate so much RAM exclusive to each SATA storage device.

And thing is -- I'm still using less RAM than I was with a regular SATA SSD caching drive. 44% of the 16GB is still available for use.

ANOTHER THING: I have yet to try a configuration that uses no RAM-caching. Then I would expect overall speed for either drive to fall somewhere between an SATA-III SSD spec and the NVMe's native speed expectation. When Intel's ISRT feature first appeared with Z68, various test-review sites -- at least a couple -- had concluded that the effective performance improvement would show bench speeds of about 80% of the caching-SSD's. And I don't think I'd have problem with matching problem- or test-sizes to the size of cache-allocated RAM.

That could mean a sequential read-rate of maybe 2,500 MB/s. I suppose I'll have to burn up some more TBW's to find out, and I wish I'd done it at the beginning, because I'd contemplated doing so before the Sammy 960 arrived. I just . . . got . . . too . . . . excited -- about it. My brain must've had a cache-reset.

 

[XavierMace]

Your last screenshot is showing the same thing. You've got a 4GB cache, yet a 2GB sequential write is getting spindle speeds. Therefore your caching is only boosting your read performance.

 

[BonzaiDuck]

Your last screenshot is showing the same thing. You've got a 4GB cache, yet a 2GB sequential write is getting spindle speeds. Therefore your caching is only boosting your read performance.

I think you've puzzled or confused yourself here. But it's my fault, because I'm also confusing myself, and I should've captured a screenshot with the Primo windows showing, because I don't remember anyway what the setting was.

However. I was poking around the online Primo Guidebook, their forums and questions/answers.

There is a fine distinction between cached writes and deferred writes. I had -- sometime today (and I already spoke to my confusion) -- chosen to select the "Read Only" option for the caches. But the read tests on the last screenie are both wanted and expected -- RAM-cache size matching the problem/test-size. This issue comes up on those forum posts and Q/A's. In bold-face, "choose a problem/test-size <= the cache size."

I remember that ISRT would take a hard disk from at most 140MB/s to maybe 300 or so. Yet some of us were all goo-gah that we'd cheated the price in the higher-capacity SSD market. [With an arm-and-a-leg paid for the low-capacity ~64GB SSD.]

What I thought disappointing today was a test I ran on the HDD with no RAM-caching and only the NVMe SSD-cache. But I also think I'd made the wrong selection either among "block size" options or "Read Only" vs. [etc.] -- perhaps even a combination of the two.

Anybody who wants to use this sort of feature, enhancement -- call it "unnecessary complication" whatever -- will end up tweaking and tuning it to fit a user's profile at a given time. But matching usage patterns to benchmark results per se would seem difficult or impossible.

On the other hand, if you like the benchmark results with any choice of problem/test-sizes you might pick, it's easy to get to a "set-it-fahget-about-it" point in the exploration. If one doesn't put data at risk with a combination of hardware instability and deferred-write setting, it has never been a program that causes the slightest problem.

And truth is, I've run it at length on the 2700K system -- months at a time -- with the deferred-write feature, and I STILL didn't have any disaster. At most, you either let the system initiate its own CHKDSK at boot-time, or initiate your own with the more extensive repair features.

Something else happens -- like the October Win Update rollup making my AV program turn the system into molasses on a cold day -- you say "wait a minute" and step back from it.

I suppose now that I've done battery replacements last week on all my UPS boxes, I could play with it again.

SOMETHING ELSE: While you can cache several drives of different types in a single RAM-cache segment under a single caching task, it's probably better to separate them into two or more tasks. The program allows you to allocate space for a particular disk WITHIN the caching-volume created by Primo. So with a 100GB volume, you can assign 50GB to the SATA SSD and 50GB to the HDD. Next question would be "What size would you allocate to each based on their relative base performance?"

 

[XavierMace]

I think you've puzzled or confused yourself here...There is a fine distinction between cached writes and deferred writes. I had -- sometime today (and I already spoke to my confusion) -- chosen to select the "Read Only" option for the caches. But the read tests on the last screenie are both wanted and expected -- RAM-cache size matching the problem/test-size. This issue comes up on those forum posts and Q/A's. In bold-face, "choose a problem/test-size <= the cache size."

I don't think I'm confused here.

PrimoCache doesn't cache writes, unless you defer writes. That's proven by your benchmarks and their website even states that in the description for the product. That makes your below statement in your original post incorrect.

There is only a single caching task: caching to 2GB of RAM is shared between SATA devices; the NVMe caching volume is shared between the same SATA devices. The SATAs are written to the NVMe, and the NVMe is written to the 2GB of RAM.

If the writes were being written to the NVMe, your write benchmarks would be showing the speeds of the NVMe device (well, technically RAM first). Even if you exceeded your cache size, SOME of the data would be hitting the NVMe (and RAM) and therefore that would be increasing your benchmark numbers. Your write results are showing straight spindle speeds on write which means it's not doing squat for you on writes (AKA sync writes). So, effectively PrimoCache is a read-only cache unless you defer writes (AKA async writes), which is where your risk for data loss comes in because at that point write operations go to RAM so if there's a power loss, you've lost any data that was in RAM.

ZFS (and most other file systems) give you the option of async writes, it's just not recommended. The difference is ZFS gives you a compromise by setting up a SLOG on fast flash storage. Now your writes go to flash first, then to the slow spindles. So you still have data integrity but aren't stuck with spindle speeds on write. As a paid product, I was expecting Primo to be able to do something along those lines for writes but that doesn't appear to be the case.

 

[BonzaiDuck]

I don't think I'm confused here.

PrimoCache doesn't cache writes, unless you defer writes. That's proven by your benchmarks and their website even states that in the description for the product. That makes your below statement in your original post incorrect.



If the writes were being written to the NVMe, your write benchmarks would be showing the speeds of the NVMe device (well, technically RAM first). Even if you exceeded your cache size, SOME of the data would be hitting the NVMe (and RAM) and therefore that would be increasing your benchmark numbers. Your write results are showing straight spindle speeds on write which means it's not doing squat for you on writes (AKA sync writes). So, effectively PrimoCache is a read-only cache unless you defer writes (AKA async writes), which is where your risk for data loss comes in because at that point write operations go to RAM so if there's a power loss, you've lost any data that was in RAM.

ZFS (and most other file systems) give you the option of async writes, it's just not recommended. The difference is ZFS gives you a compromise by setting up a SLOG on fast flash storage. Now your writes go to flash first, then to the slow spindles. So you still have data integrity but aren't stuck with spindle speeds on write. As a paid product, I was expecting Primo to be able to do something along those lines for writes but that doesn't appear to be the case.

I think the distinction Primo had made, and the interpretation I'd made of it, was whether the cache is refreshed simultaneously with writes to the slow/cached device, versus writes only to the latter. I think this is the distinction they make between "Read and Write" versus "Read" settings and "Deferred Writes." Under the "read and write" scenario (correct me if you think I'm wrong . . ) -- data is being written simultaneously to the cache and the cached device, the latter being the common denominator in determining the time it takes to make those writes.

In any case, their online guide makes that point. For that, I'd expect to see spindle write speeds whether the cache is refreshed with writes intended for the slow device -- or not.

Truth be told, I expected even better performance arising from the M.2 NVMe. But I think of it this way. We're not worried about "using" all the storage or the "lost" RAM with this solution if only concerned about performance. We're duplicating data between levels of storage, to take advantage of the faster speeds. If it doesn't always appear that there's an advantage or that the cache seems "empty" by comparison to expectation, I won't get my panties in a bunch about resources "wasted" in the caching.

I guess the biggest question that stays in my mind is "why there aren't more choices of software." SuperSpeed's solution only implements part of the PrimoCache offerings and options. But those are the only two options I'd found in searching for caching software.

 

[BonzaiDuck]

Here's an interesting result. You can run Magician's benchmark against drives other than the Samsung. I ran it against the ADATA SP550 SSD boot disk -- labeled "C:" in my other screenies:

Here, the read-rate is almost double what I'd get with Anvil. The write-rate is also somewhat higher -- and as before, with no deferred-writes enabled.

It seems that allocating as much as 6 GB of RAM for that part of the caching regime still leaves plenty out of the 16GB 2x8 kit I'm using. Maybe usage scenarios will change and I would need more, but during a gaming session, I still come up with about 6 GB of RAM available. Right now, I'm allocating 3GB for the SSD and HDD respectively and separately.

Here's the Magician benchie for the Seagate Barracuda spinner:

 

[BonzaiDuck]

So I trimmed the Barracuda's RAM-cache by a third to 2,048 MB. Then I ran the Samsung benchtest against it once more. Read performance (according to the benchmark) has more than doubled to over 8,000 MB/s. Write performance actually seems higher than it should be, but it's within the overall electro-mechanical range:

 

[BonzaiDuck]

It all depends on the benchmark program. If Magician is to be believed, using the NVMe M.2 as a caching drive may actually prove out a need for less RAM in the caching regime.

 

[sdifox]

Shrug. Just bought 48GB of ddr3 rdimm for my PE R710. Cost like US$84. Figure it will do more good than ssd caching for a vm host.

 

[BonzaiDuck]

Shrug. Just bought 48GB of ddr3 rdimm for my PE R710. Cost like US$84. Figure it will do more good than ssd caching for a vm host.

I wouldn't have the slightest doubt of it. "VM Host" is a completely different profile than that of my workstation.

Excluding those differences, more RAM would only help my system on top of the NVMe. But I hibernate the system, and the smallest hiberfil.sys will be 50% of total RAM.

It seems I have plenty of RAM available now, despite 2,048 MB allocated to each caching task of two.

I can look at the Anvil results. I can look at the Magician results. And I have my own sense of things from gaming or running other programs. Without being able to conclusively know that one or the other benchmark is showing useful and meaningful numbers, I think I'll run some tests with Magician and choose the RAM allocation that gives the most reasonable score for that device.

I'd say that 8,791 MB/s for the Seagate Barracuda has some Lebensraum for reducing the RAM allocation. Similarly, the last post I made for the ADATA SP550 boot drive showed something like 20,000, and I reduced the RAM size by 512MB so the second test put it at 18,000. Lots of Lebensraum there, also.

The way it stands, with 2GB + 2GB = 4GB allocated to the SATA SSD and HDD, I still show just short of 8GB of free RAM while gaming. I could actually increase the size of the RAM caches, but if the performance is still apparent from using less, I'll use less.

 

[BonzaiDuck]

Just continuing this after my obsession leaked over into a thread about HDD obsolescence [if you find the current thread, post #49, I think.]

Ran AS SSD benchmark. Primo is up front in their online "guide" about using a test-size less than/equal to the size of the RAM cache. That's where, as XavierMace notes, this falls down. But it really depends on how your usage profile is going to cause something like that to happen. You'd have to load a program that would grab, say, 4GB of RAM all at once. Or you'd need some sort of dynamic RAM-caching. The test itself is almost irrelevant except for the possibility that such a thing might happen.

Otherwise, the sequential read on AS is similar to Anvil and about half that of the Samsung benchmark.

ANOTHER UPDATE: I've run out of space on my webpage allocation, or there'd be more screenies. AS SSD gives results similar to Anvil, and the same trends with matching cache and test/problem-size. I tested an uncached hot-swap spinner with Samsung, and the numbers seem about right.

You will use up TBW's most noticeably when you delete the cache from the disk and start over, or when you reset the cache. Need to verify latter as same as former. I reallocated the SSD or L2 cache to about 38GB for the SATA SSD, and about 75 GB for the spinner. I can see the boot SSD filling up faster.

So I'm lookin' at a 960 Pro 1TB, but I would be doing the same thing with it that I'm doing with the EVO, It would also become boot-OS-System partition with two 400GB volumes and two equal caching volumes. In the meantime, I'm going to fiddle with the EVO some more . . . There are still a lot more cartridges in the bandolier before I need to swap in "the Big One."

 

[BonzaiDuck]

From the hits or replies to my thread, there must be limited interest in this sort of thing.

But here's what I've discovered so far. Whether with or without adding RAM-caching at the top of a tiered arrangement, you will get a performance improvement over SATA SSD speeds for both SATA SSDs and HDDs. For some reason, the benchies don't "show" it with Primo without RAM-caching. I've put in a question via e-mail to Romex about choosing benchtest programs -- asking for "enlightenment."

Another thing. If you accelerate a spinner with either SATA or NVMe SSD, and you choose or need to transfer a large number of files to the HDD, you're best to suspend its cache. Why? IF the cache was set up to cache both reads and writes -- the "writes" is why. Or -- you'd see the TBW increase at a faster rate for the caching SSD. This is among all those little complications and "management-time overhead" you'd put in with this type of configuration. A lot of folks won't go for it.

Finally, suppose -- as do I --that you have a dual-boot configuration with Win 7 and Win 10. You can only share the caching SSD (SATA or NVMe) by defining separate caching volumes -- one for each OS. This would also mean that the source volume -- the accelerated volume -- cannot be shared between the OSes. So you could only create a shared volume on an HDD that is only cached to RAM, and you can't save that cache at restart/shutdown between OSes. If you were all goo-gah about caching with an obsession to embrace all the subtleties, that's the reason right there to increase RAM. But since you might change files under one OS and access them through the other, the RAM-caches cannot be used persistently. They must be re-created at boot time.

If you hibernate the system under one OS, the RAM data will be saved anyway, and hibernation circumvents the boot-choice at startup.

 

[BonzaiDuck]

Still waiting for Romex support to come back. The problem with the SSD-caching in the mix, benchtests except for (possibly) Magician don't show the performance due to the NVMe caching drive without RAM, but the performance is "there."

The last Sammy Magician test I made on the hard disk with the NVMe cache and 2,048 MB RAM clocks in at about 11,000 MB/s. A similar SATA-III hard disk, without the NVMe but with the same 2,048 MB RAM allocation clocks in at about 3,150 MB/s.

But when you remove the RAM-caching from the former task, the benchies only show the performance of the source disk itself.

The PRimoCache people need to explain this, and I asked for a pointer as to what benchtest would show what I want to show. . . .

 

[XavierMace]

From the hits or replies to my thread, there must be limited interest in this sort of thing.

Very limited and the rest of your post pretty much says why. It's primary benefit at the consumer level is for epeen benchmarks. It's not doing squat for you on writes, it's drastically reducing the life of your SSD, it's using CPU cycles, and it's reserving RAM. Outside of artificial benchmarks, what are you actually gaining from it? How much does it reduce your boot time? How much does it reduce your game/application load times? So far all you've provided for real world info is "you can feel it". Unfortunately, that's not proof of anything. My grandma swore that switching to CenturyLink DSL from Cox Cable made her computer faster.

As I said in your other thread, it's largely a pointless product for desktops. You can't choose what's on the RAM cache (which is why people still use RAM Disks) which means you're never going to get everything you use cached unless you've got a metric crap ton of RAM and if you can afford enough RAM for this to make a constant real world noticeable difference, you could have afforded to just buy a bigger SSD in the first place which may not give you as good of performance in your select benchmarks, it provides a much better global performance increase.

Then there's the cost. Many SSD's these days include caching features for free (IE: Samsung RAPID, Crucial Momentum). Romex wants $30 per PC or $120 per server and you still have to buy suitable hardware plus IMO, it does an inferior job at caching. Admittedly it's configurable but it's inability to cache writes unless you go ASYNC, severely limits it's usefulness and you can get that ability for free elsewhere.

The PRimoCache people need to explain this, and I asked for a pointer as to what benchtest would show what I want to show. . . .

This basically proves my point. All your benchmarks have been carefully selected to provide optimal results and in no way mirror normal usage.

 

[BonzaiDuck]

I think I'm coming around to a conclusion consistent with that.

The best results I see from it are in caching HDDs. I can only explain that by saying I allocated a nominal 1GB of RAM equally for each SATA device, including the boot SSD. The benchmarks for the SSD fall flat. The HDDs show sequential read-rates between 4,000 and 11,000 on Magician -- less stunning results with other benchmarks.

And when I eliminate the RAM tier for any of the devices, it falls flat. The best that can be said for it is the RAM-caching, which we would all agree or observe as the most reliably performance-enhancing aspect, and then you'd be better off spending the money on a 32GB kit of RAM to take advantage of it.

It was a gamble of a $130 experiment. I may as well just go ahead with my original plan and get a 1TB NVMe M.2. The 250GB unit I now have can go in the household's Ivy-Bridge system, which can take advantage of the PCI-E 3.0 spec as it does with this rig.

 

[XavierMace]

Don't get me wrong, I'm not criticizing you for giving it a spin. I've got a server rack full of equipment that's basically just to play with. It's just not a product I personally could recommend to anyone.

 

[BonzaiDuck]

Don't get me wrong, I'm not criticizing you for giving it a spin. I've got a server rack full of equipment that's basically just to play with. It's just not a product I personally could recommend to anyone.

I could continue to say "I haven't had problems with it," and -- like 2016 politics -- it wouldn't be entirely true. But the problem I just had was my own goddam fault.

This morning, I decided that I would continue tweaking the Windows 10 installation on this wonderful dual-boot system. The Primo program needs a logical volume to convert to a caching volume. You can't create a logical volume within Primo, but rather you need to create such a volume before Primo converts to its own format and use. After that, the volume appears in disk management as "healthy" but of "unknown" type. And of course, you're not going to give it a drive letter. But Primo will allow you to label it.

So, unthinking, I went forward to use a volume I'd created in Windows 7 with a label of "Win10_L2_Cache" to a Windows 10 caching volume. In Primo, you have to reestablish the label (like the descriptive one you'd create in Windows first). And in Windows 10, the attempt to use that volume failed.

Why? Why?! Because I had perhaps forgotten to install the Samsung driver for the NVMe. I had THOUGHT that Win 10 had a native driver for it. But it would've been better if I'd left the space unallocated and created that volume in Windows 10. I'm a little hazy about what happened after that, but I think I deleted the volume in disk management. Either way, I sought to restart into Win 7 again. Whatever -- maybe I deleted the wrong volume, because the Primo Label doesn't appear in Disk Management.

And I thought I'd borked my dual-boot system, so meticulously and perfectly created, built up, maintained in every way. Just not as far along in the Windows 10 side of the dual-boot, but all the drivers -- except the Sammy 960 EVO driver -- were installed. I was "going forward." I made a stupid mistake.

I was scurrying for WHS-2011 USB keys, to find out that you can't do a bare metal restore with them using a Z170 chipset and UEFI BIOS. It would've been sooooo easy to simply do a bare-metal restore to the same SSD. But the skinny on the street says you can only use the WHS2011 "client restoration disc" -- and I couldn't move forward with that, either. Tried to do a "Windows Repair" -- no cigar. Couldn't do it with the Win 10 optical disc I'd created; couldn't do it with Win 7 already complicated by the USB3 driver problem that required a slip-streamed OS install disc -- which in turn would not offer you the Repair option. Tried booting into Acronis. Went online searching for some miracle utility from a company or source I could trust. I remained . . . calm . . .

Removing the drive, allowed Primo to "let go" of the two caching volumes it expected to be there, and the system would then boot fast and neat. Looking at the Primo configuration and what it "thought" were caching partitions, I see more or less what happened. But, generally, once you physically remove a drive included in a caching task, Primo simply drops the task and shows it empty and bereft of disks. Different, if you delete the wrong caching volume, and it may grab something else that appears in the dialog like the long string identifying a Volume Shadow Copy file or designator.

So like the character Ray Lucca of the '80s "Crime Story" drama says to Richard Farina as the FBI man, "I'm back. I'm bad. I'm on top. You wing-tip bozos don' got nuthin' on me."

At the moment, I don't think I need an L2 cache with this program. 2GB or more of RAM accelerates the HDD fine. Whether the RAM caching is persistent or not, there aren't any volumes to bork by mistake. The benchies look damn good for an HDD.

I think instead, I'll get a 1TB 960 Pro drive to stick in there. But it would cost less to get a 32GB 2x8 DDR4 kit. And I'm going to get along just fine while I ponder spending money and planning for the future.

No hurry. The L2 feature does work, but it doesn't show up in the benchies. I may not stop using the program, but one doesn't have to use every major feature effectively. I notice that Superspeed's SuperCache only offers RAM caching. I think I only tried that one briefly, but wanted something equivalent to Primo's L2.

Anyway, that's enough on the experimentation. I'll just re-deploy the EVO to another system. Well -- let me think about that for a bit . . . .