Cache SSD+HDD (like Intel SRT) for old system?

[Phynaz]

I think the Primocache stats are wrong.

It says I've written 4GB today, but the Intel SSD Toolbox says I've written 6GB. Maybe Bitlocker overhead?

 

[Phynaz]

I'd be careful of using that long of a deferred write, especially on an encrypted drive. You can see write improvements with as little as 10 seconds defer.

Eh, it's a laptop. Not like it's about to lose power unexpectedly.

 

[Phynaz]

I believe the entire drive has to be dedicated to the L2 storage, it can be partitioned into more than one cache....but the entire drive is a special "format" and is unrecognized by windows and samsung magician.

Not the entire drive, but it does require a dedicated partition.

Edit:
It's a shame they don't use a file on an existing partition.

 

[BonzaiDuck]

Like I said before -- if the benefits seem apparent -- AND -- if the software in combination with OS and hardware yields total stability, then go for it.

I just really like their 90-day trial-period. WHO DOES THAT?!! All through it, the laptop was both stable and fast. No problem with sleep and hibernate. Nichts. Nada.

So I paid for it. I can still use it on one more PC.

 

[hawtdawg]

primocache is pretty awesome if you have a lot of excess ram you can throw at it

 

[BonzaiDuck]

primocache is pretty awesome if you have a lot of excess ram you can throw at it

4GB is more than sufficient for office applications, web and e-mail -- together with perhaps some remote database access, programming where time/performance-testing isn't a priority and so on.

A lot of people in recent years -- maybe going back to 2010/2011 -- likely purchased systems with 8GB, especially if they'd been casual gamers and had to replace a household desktop.

Enthusiasts probably upgraded to 16GB from 8GB systems originating from "enthusiast-system-builder" or OEM.

Only certain types of applications can use all of that RAM at once. Application updates may eliminate memory leaks, leaving more Free and Available RAM.

So this sort of thing especially makes sense, and I suspect the best advantages from it arise with 16GB or higher. But I'd cited my 2007-era laptop, its 8GB of SO-DIMM and SATA-II controller for an MX100. I generally have more than 2GB free with a 3GB cache and several business or communications apps loaded. I can watch recorded video wirelessly, and I haven't yet set up the system to see if I can get adequate wireless TV -- with a laptop monitor that is not 1080p HD. And it occurs to me that the monitor is fully capable of 720, so why not?

But in addition to direct RAM usage, different applications and their files will benefit differently from any advantages of caching an electro-mechanical disk to SSD, and so the variation of benefit applies across the board of configurations.

But it makes sense, no? Instead of burdening RAM with more than an essential RAM-cache, use an old small-capacity, SATA-III SSD to accelerate an HDD of any size, and the bigger -- probably the better. So far, the only power-consumption of the slightest consequence is probably the single HDD. No extra controllers. No concern about what BIOS mode for storage.

Or you could define a set of varying usage patterns and define different configurations for all three (or more) pieces of hardware. Then choose when you use.

 

[BonzaiDuck]

Here's some things I believe can be done.

Take for instance my configuration of a Sammy-Pro or EVO boot/system disk, 16GB RAM, second 60GB SSD, and a 500GB HDD (or 1TB, etc.)

The Sammy is already cached with RAPID. But I can turn off RAPID, create a new cache "task" after I create the first cache task for an L2 SSD<-HDD. In the new cache task, I could use the "add volumes" option to create a RAM-cache for both the Sammy and the "HDD." The HDD already accelerated would mean that effective performance would move in the direction of the cached Sammy Pro.

All of the caching would occur under a single, defined amount of reserved RAM. Somebody could test it -- I dunno -- maybe I will. Just . . . maybe . . .

 

[ctk1981]

I upgraded to 32GB this time around due to my experience with primocache. I'm also a gamer and with the recent requirements of the witcher 3 announced it looks like that may have been a good idea.

I use 8GB of ram in front of my unencrypted partition that houses games, apps, etc. 4GB of ram in front of my encrypted partition. Samsung rapid is using 4GB itself for the 840 pro I run as my OS. That leaves me 16GB of ram for everything else. Perfect.

I'd rather hammer the Ram for a cache than a SSD.....you get faster performance from the ram and almost all manufacturers offer a lifetime warranty on ram anyways whereas SSD makers are ~3 years and you may or may not get a refurb drive as a replacement. I've only had to RMA ram to crucial before.....and the process was smooth. They even found me a stick that was made the same week as the one I had (dual channel kit.).

One thing I have been considering though is a larger/faster L2 cache drive, just to ensure that I have the fastest performance possible when not hitting the L1 cache....(games mostly).....due to the fact the HDD that I'm using is a 5400RPM Red WD drive....lets face it, not even remotely a high performance drive. I may go to a 256GB XP941 or SM951 drive in PCIe configuration to use as a L2 cache. Figure 150/50GB L2 storage in front of my two partitions should ensure the greatest performance.

 

[BonzaiDuck]

I upgraded to 32GB this time around due to my experience with primocache. I'm also a gamer and with the recent requirements of the witcher 3 announced it looks like that may have been a good idea.

I use 8GB of ram in front of my unencrypted partition that houses games, apps, etc. 4GB of ram in front of my encrypted partition. Samsung rapid is using 4GB itself for the 840 pro I run as my OS. That leaves me 16GB of ram for everything else. Perfect.

I'd rather hammer the Ram for a cache than a SSD.....you get faster performance from the ram and almost all manufacturers offer a lifetime warranty on ram anyways whereas SSD makers are ~3 years and you may or may not get a refurb drive as a replacement. I've only had to RMA ram to crucial before.....and the process was smooth. They even found me a stick that was made the same week as the one I had (dual channel kit.).

One thing I have been considering though is a larger/faster L2 cache drive, just to ensure that I have the fastest performance possible when not hitting the L1 cache....(games mostly).....due to the fact the HDD that I'm using is a 5400RPM Red WD drive....lets face it, not even remotely a high performance drive. I may go to a 256GB XP941 or SM951 drive in PCIe configuration to use as a L2 cache. Figure 150/50GB L2 storage in front of my two partitions should ensure the greatest performance.

NOW! NOW someone has triggered my interest in a 32GB RAM kit!! Oh, the money-pit of computer-enthusiast obsession!

 

[ctk1981]

NOW! NOW someone has triggered my interest in a 32GB RAM kit!! Oh, the money-pit of computer-enthusiast obsession!

LOL.....welcome back to the dark side.

 

[ashetos]

Just keep in mind that RAM disks are a tradeoff between performance and data reliability.

In the event of a crash/BSOD or power failure there will be data-loss.

You should also keep in mind that only I/O writes will make a difference, since reads are already cached by NTFS, and file-system caching is more efficient than a RAM-disk since there is one less memory copy operation in the I/O path. Moreover, this amount of memory can be reclaimed by applications if they need it.

So, to conclude, RAM disks will mostly speed up writes, at the expense of file-system integrity. However, if you feel that the importance of the data is small, the probability of a crash is low and the hassle of restoring your data to a previous state is worth it, then the extra performance is worth it.

 

[ctk1981]

Too late to reply in length, but no. Primocache is not a ramdisk.

 

[ashetos]

It may very well not be technically a RAM-disk, but you must keep in mind that DRAM caching has all the data reliability hazards that affect RAM-disks mentioned above.

You must be aware of the dangers and not allow any false sense of security or you will be surprised.

 

[ctk1981]

On the write side, if using deferred write then yes....there is a possibility of lost data during a bsod or power loss. On reads, no..its a cache...a copy of something already on a HDD or SSD. And even with an extra memory copy operation, ram will always be faster than a ssd or HDD. You're talking a huge difference in bandwidth, speed, and latency between the two.

Whether or not you'll be able to notice it is another story when comparing ssd and ram caching. But when put in front of a slow turning HDD the difference is readily noticible. I have my concerns with deferred writes and a encrypted drive for the reasons you pointed out....so I simply turn off that option for that particular partition.

As always, regular backups should be used by anyone who values their data. I can perform a complete restore to yesterdays backup in under 5 minutes if need be. Hardly time consuming or a chore as you have made it out to be.

 

[BonzaiDuck]

Too late to reply in length, but no. Primocache is not a ramdisk.

I was going to say that, too.

Both SSD-caching for HDDs and the RAM-caching for either usually defaults to read-caching with immediate direct writes to the slower storage level unless you specify otherwise. The SSD-caching is persistent through re-boot; the RAM caching isn't.

I never had hard disk corruption with ISRT when my system BSOD'd or froze (from tweaking the clocks and a one-time problem of contentious devices). The accelerated boot/system disk survived, and I may only have reinitialized the caching SSD a couple times over a few years.

And so far, I haven't had any problem with the RAM-caching -- either RAPID or Primo-Cache. Now I've tested two aspects of Primo that can be mutually exclusive or work together. I've tested it on a laptop and two desktops -- first of the latter an LGA_775 configuration that I decommissioned. Haven't had a single problem with it.

 

[ashetos]

I am not against DRAM caching, I'm just raising awareness of the issues.

Also, read DRAM caching is dumb, NTFS already does this. If you are to use a RAM-disk for a cache you should cache both reads and writes in write-back mode, or deferred writes as they call it.

I can't think of a single scenario where write-through DRAM caching is useful, when NTFS already does it. If you go that way, go all the way through!

 

[ctk1981]

That cache must not be as efficient as a Samsung rapid or primocache ram cache then...because I've ran three separate benchmark programs and all three show significant read gains over not having one. Proof is in the pudding, you can cry up and down till your blue in the face but the two are different and there are gains to be had enabling a read only ram cache if one desires.

 

[ashetos]

That cache must not be as efficient as a Samsung rapid or primocache ram cache then...because I've ran three separate benchmark programs and all three show significant read gains over not having one. Proof is in the pudding, you can cry up and down till your blue in the face but the two are different and there are gains to be had enabling a read only ram cache if one desires.

Of course the benchmarks show gains, since the benchmarks do raw I/O. This means the benchmark goes through the NTFS cache to evaluate the underlying storage.

That means, the benchmark goes through the NTFS cache (because it is the correct thing to do), but not through any third party cache (because the third party cache presents itself as a device).

I am not blue in the face, I just know what I'm talking about.

 

[ashetos]

For reference:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364218(v=vs.85).aspx

You can grep in the source code of any benchmark the keyword FILE_FLAG_NO_BUFFERING.

I can verify that CrystalDiskMark source code uses this flag to evaluate performance. You can examine any benchmark source code and be sure that all benchmarks use raw IO.

 

[ctk1981]

Of course the benchmarks show gains, since the benchmarks do raw I/O. This means the benchmark goes through the NTFS cache to evaluate the underlying storage.

That means, the benchmark goes through the NTFS cache (because it is the correct thing to do), but not through any third party cache (because the third party cache presents itself as a device).

I am not blue in the face, I just know what I'm talking about.

If that is true then why does no benchmark produce the same number, whether it be with or without a ram cache in front of it? Ram cache always wins. And in real world usage as long as the ram cache (be it primocache, superspeed or others) is having a high % hit rate is quite noticible....especially on an older system as the OP inquired about.

Primocache does not present itself as a device. Its apparent you have never used this software at all. When I say ram cache I mean cache, not disk. Primocache is not a ram disk at all. Neither is samsungs rapid or superspeed. Primocache works at the block level....its L2 cache is not formatted to a filesystem and I imagine what it does in L1 is also at block level data.

Lazy write and deferred write are less worthy to me than the read side. It is exactly what the name implies....deferred, delayed, lazy...you will never actually increase the write speed due to the fact that whatever you are writing to be it ssd or HDD is slower than the memory. It may appear to be faster, but there is always a delay at the end of the transfer when windows claims its done copying.....its because of the delay configured and will take that much longer.

 

[coercitiv]

Holy smokes.

Remember you are now twice as vulnerable to power loss issues, including BSODs.

This was a lesson I had to learn the hard way when using RAPID mode enabled on my 840 Pro equipped laptop.

[EDIT] for some reason I did not notice the 2nd thread page, so my warning is clearly in excess. However, my example is not, I did lose files due to a write caching solution.

 

[coercitiv]

I don't think my nephew is technical enough to manage what goes on an SSD and what goes on the HDD with a typical SSD+HDD system. That's why I think it would work best to have a caching solution where only 1 logical drive is presented to Windows.

I'll be the stubborn guy who tells you what you clearly asked not to be told: with a 240GB SSD the best (caching) solution is your nephew.

Put windows, office, browser on the SSD, everything else on the HDD. I'm using this type of config with my HTPC and it does wonders to performance, even allowing the HDD to power down when not needed. (idle, browsing).Sure (some) games will not load as fast, but the OS will run overall faster.

PS: it's also easier to maintain, since the software layer is another piece in the puzzle that can go wrong. (what does that button do?)

 

[ashetos]

If that is true then why does no benchmark produce the same number, whether it be with or without a ram cache in front of it? Ram cache always wins. And in real world usage as long as the ram cache (be it primocache, superspeed or others) is having a high % hit rate is quite noticible....especially on an older system as the OP inquired about.

Primocache does not present itself as a device. Its apparent you have never used this software at all. When I say ram cache I mean cache, not disk. Primocache is not a ram disk at all. Neither is samsungs rapid or superspeed. Primocache works at the block level....its L2 cache is not formatted to a filesystem and I imagine what it does in L1 is also at block level data.

Lazy write and deferred write are less worthy to me than the read side. It is exactly what the name implies....deferred, delayed, lazy...you will never actually increase the write speed due to the fact that whatever you are writing to be it ssd or HDD is slower than the memory. It may appear to be faster, but there is always a delay at the end of the transfer when windows claims its done copying.....its because of the delay configured and will take that much longer.

Block-level actually means it presents itself as a device. You don't know what you're talking about.

 

[R0H1T]

Block-level actually means it presents itself as a device. You don't know what you're talking about.

I'm not sure if primocache works on the block level or not but AIDA64 storage test, which does raw I/O, is the only one I've seen that doesn't yield any benefit with the said application. Correct me if I'm wrong but I suspect this is what raw I/O or block level access should look like :hmm:

 

[ashetos]

I'm not sure if primocache works on the block level or not but AIDA64 storage test, which does raw I/O, is the only one I've seen that doesn't yield any benefit with the said application. Correct me if I'm wrong but I suspect this is what raw I/O or block level access should look like :hmm:
snip

Primocache works at the block-level, as the developers state in their website, as most storage caches do. There are also some cache products that work at the file-system level, but they are fewer in number.

There are two ways to perform raw access, one is to open the block device directly, like AIDA64 does for Device\Harddisk0\DR0 and perform generic reads and writes. The other is to open a file with the FILE_FLAG_NO_BUFFERING flag and perform raw access through a file.

The difference is that opening the block device directly gives you access to the whole address space of the disk, whereas opening a file limits you to the file size limits. Keeping that in mind, it's much safer to perform writes to a file than to the whole block device, because you are bound to corrupt any file-systems residing in any volumes in the disk. More hardcore benchmarks tend to open the whole block device.

Now, about the Device\Harddisk0\DR0 block device, it seems that it is the virtual disk that the Intel Software RAID driver created over multiple physical disks, and this would explain why you don't see any speedup.

The stackable nature of block-level drivers allows for combinations like the following:
2 SSDs + 1 HDD(3 block devices)
RAID-0 (combine the above 2 SSD block devices into 1 new RAID block device)
cache (combine the RAID-0 block device with the HDD block device into 1 new cache device)