On Sun, Dec 08, 2013 at 06:58:07PM -0600, Stan Hoeppner wrote:
> On 12/8/2013 9:03 AM, Emmanuel Florac wrote:
> > Le Sat, 07 Dec 2013 23:22:07 -0600 vous écriviez:
> >>> Thanks for the great advice, I think you are on to something
> >>> there. I will
> >> You're welcome. Full disclosure: I should have mentioned that I
> >> haven't used CacheCade yet myself. My statements WRT performance are
> >> based on available literature and understanding of the technology.
> > I didn't test thoroughly cachecade though I have a license code
> > somewhere, however I've used the equivalent Adaptec feature and one SSD
> > roughly double the IOPS of a RAID-6 array of 15k RPM SAS drives from
> > about 4200 IOPS to 7500 IOPS.
> Emmanuel do you recall which SSD you used here? 7500 IOPS is very low
> by today's standards. What I'm wondering is if you had an older low
> IOPS SSD, or, a modern high IOPS rated SSD that performed way below its
> specs in this application.
It's most likely limited by the RAID firmware implementation, not
> The Samsung 840 Pro I recommended is rated at 90K 4K write IOPS and
> actually hits that mark in IOmeter testing at a queue depth of 7 and
Most RAID controllers can't saturate the IOPS capability of a single
modern SSD - the LSI 2208 in my largest test box can't sustain much
more than 30k write IOPS with the 1GB FBWC set to writeback mode,
even though the writes are spread across 4 SSDs that can do about
200k IOPS between them.
> Its processor is a 3 core ARM Cortex R4 so it should excel in this RAID
> cache application, which will likely have gobs of concurrency, and thus
> a high queue depth.
That is probably 2x more powerful as the RAID controller's CPU...
> Found a review of CacheCade 2.0. Their testing shows near actual SSD
> throughput. The Micron P300 has 44K/16K read/write IOPS and their
> testing hits 30K. So you should be able to hit close to ~90K read/write
> IOPS with the Samsung 840s.
Like all benchmarks, take them with a grain of salt. There's nothing
there about the machine that it was actually tested on, and the data
sets used for most of the tests were a small fraction of the size of
the SSD (i.e. all the storagemark tests used a dataset smaller than
10GB, and the rest were sequential IO).
IOW, it was testing SSD resident performance only, not the
performance you'd see when the cache is full and having to page
random data in and out of the SSD cache to/from spinning disks.