Samsung Rapid with varying RAM speeds?

[Sushisamurai]

So I'd like to think I've searched far and wide in the vast sea we call the Internet for any performance metrics on Samsung's RAPID RAM cache and the impact varying RAM speeds and timings would have.

I obviously couldn't find anything on the matter, so I'm turning to here, my favorite website/forum! Yes, I understand that RAPID benchmarks are essentially a benchmark of my system RAM. What I'm actually more interested in, is the impact of faster DRAM frequency and timings on my Disk IO's (that matters more to me) - and by extension, the difference a 850 Pro with RAPID enabled vs a SanDisk Extreme Pro with varying RAM; from what I understand, the SanDisk also does some form of DRAM caching (the review wasn't very specific).

Iono, seems like a neat avenue to poke around in if no one has yet. I mean, if my IO could improve by 40% at the expense of 10-20% cost for better RAM it might actually be worth it with a dGPU setup (since faster RAM doesn't scale well with single/dual dGPU's for gaming)

 

[Scarpozzi]

My experience with SAN solutions basically follows a similar methodology. Most of the big solutions like EMC and their competitors are moving more and more to block-level manipulation and tiering the storage into 3-5 different speeds. The disks are SSD, SAS, or SATAII. All of those have a few different models that run at various speeds. You can actually gear different layers more for writing and different ones for reading to tune the SAN to be more efficient for different applications (DB writes vs DB reads or virtualization)


RAPID is basically just throwing a ram cache layer on top of the write cache layer that's already included on the EVO. So you're caching it off the system bus before it ever reaches your SATA controller. A lot of operating systems already do similar operations, so you may be adding a layer of complexity and not seeing much benefit. You really have to look at where the bottlenecks are and decide if you even need the extra layer.

I've run mail servers in the past on journaling file systems that couldn't keep up with the writes. I pulled the data and threw it on a non-journaling system and it didn't break a sweat. File server applications and web/java apps had no problems with the journaling. That's just an example....applications and system scale make all the difference on whether or not you'll ever see any benefit.

Benchmarks are always hypothetical real-world guestimates.

 

[Sushisamurai]

RAPID is basically just throwing a ram cache layer on top of the write cache layer that's already included on the EVO. So you're caching it off the system bus before it ever reaches your SATA controller. A lot of operating systems already do similar operations, so you may be adding a layer of complexity and not seeing much benefit. You really have to look at where the bottlenecks are and decide if you even need the extra layer.

I agree that RAPID does seem like an unnecessary redundancy that an OS would do. However, on the Samsung 850 Pro review at anandtech, RAPID enabled did yield a performance benefit vs disabled (assuming OS caching when enabled and disabled) with both anandtech's storage bench 2011. Assuming Anandtech's storage benches were developed to reflect real world client usage, RAPID, although seemingly redundant, shows an actual benefit to being enabled.

PCMark's results didn't show a benefit, but that was chalked up to program optimization for HDD's and not SSD's. I imagine that as SSD's get more traction, programs will begin to optimize for SSD's and DRAM caching to SSD's will be more relevant (imagine ddr4 now).

"It will be interesting to see what the industry does with the software stack over the next few years. In the enterprise, we have seen several OEMs release their own APIs (like SanDisk’s ZetaScale) so companies can optimise their server software infrastructure for SSDs and take the full advantage of NAND. I do not believe that a similar approach works for the client market as ultimately everything is on the hands of Microsoft. " -Samsung 850 Pro review @Anandtech

Ultimately, I think Samsung (even tho I'm not a fan of Samsung products - performance doesn't lie though )is in a better position to optimize their RAM caching than Microsoft is, in the long run.

 

[Sushisamurai]

I don't want to detract from the original idea in this thread into whether or not RAPID is a redundant software - we can do that in another thread. The way I view it, any free performance benefit is welcomed. The question I'd like answered/investigated is, how much can I milk this free performance benefit (kind of like how much more of an OC could I get if I just spent a few more $$$'s on a better cooling solution, and would it be worth it)

 

[coercitiv]

So I'd like to think I've searched far and wide in the vast sea we call the Internet for any performance metrics on Samsung's RAPID RAM cache and the impact varying RAM speeds and timings would have.

What makes you think the most important factor in RAPID performance is RAM bandwidth? It might be CPU performance and amount of RAM first, with RAM "speed" on a distant second.

My test system uses a quad-core Sandy Bridge, so we're looking at an additional 60 - 70% CPU load on a single core when running an unconstrained IO workload. In real world scenarios I'd expect that impact to be much lower, but there's no getting around the fact that you're spending extra cycles on doing this DRAM caching. RAPID will revert into a pass-through mode if the CPU is already tied up doing other things. The technology is really designed to make use of excess CPU and DRAM in modern day PCs.

 

[Sushisamurai]

What makes you think the most important factor in RAPID performance is RAM bandwidth? It might be CPU performance and amount of RAM first, with RAM "speed" on a distant second.

The reason why I think RAM bandwidth is the most important factor in RAPID performance is from the Samsung 840 EVO 4K random write @QD32, where CPU utilization only goes to ~32%, as well as the next paragraph following the one u quoted:

"The potential performance upside is tremendous. While the EVO is ultimately limited by the performance of 6Gbps SATA, any requests serviced out of main memory are limited by the speed of your DRAM. In practice I never saw more than 4 - 5GB/s out of the cache, but that's still an order of magnitude better than what you'd get from the SSD itself."

 

[coercitiv]

most important factor in RAPID performance is from the Samsung 840 EVO 4K random write @QD32, where CPU utilization only goes to ~32%

I get 40% CPU usage when testing random write @QD32, with a Haswell quad @3.2Ghz and Samsung 850 Pro.

If I had a dual core @3Ghz, I would be CPU bound.

 

[Sushisamurai]

I will have to test my cpu utilization when I go home (traveling atm) on my 840 pro.

 

[Lorne]

As ram speed increases CPU utilization will increase, But will shorten the work time.
This was also noted when SSDs hit the market years back.

Faster ram will benchmark higher scores for RAPID though minute as do most memory benchmarks but the SSD still has the same speed limitations or I should say the SATA port has the same speed limitation.
(Perspective) RAPID is a cache ramdrive (2/98~ RW perf) not a mirrored ramdrive.

(Insight) RAPID will fade as HD (storage) throughput increase but remains more beneficial to slower drives ie. HDD or SSD on SATAII ports.