I thought they looked like Tallboys. If they're on display then hopefully someone checked that they aren't full of explosives, unlike the Grand Slam used as a gate guardian at RAF Scampton.
The Fort Lauderdale boys have struck again, with a record-breaking run of 5 million IOPS, and maybe killed off every other SPC-1 benchmark contender's hopes for a year or more. DataCore Software, head-quartered in Fort Lauderdale, Florida, has scored 5,120,098.98 SPC-1 IOPS [PDF] with a simple 2-node Lenovo server set-up, …
Thursday 16th June 2016 13:23 GMT ByteMe
Is SPC-1 still relevent with massive cache systems?
I agree that the question shouldn't be, "Is this just running out of cache?" The real question should be, "Is SPC-1 still a relevant benchmark test when storage and HCI systems are now much different and all can use massive amounts of DRAM cache?" SPC-1 was designed back when traditional arrays were entirely spinning-disk based and DRAM for cache was limited due to its high price. Most all of today's storage platforms leverage "YUUGE!" amounts of cheap and fast DRAM as well as multiple, if not all, SSDs. Somebody needs to start thinking-up a new benchmark test.
Thursday 16th June 2016 14:58 GMT Anonymous Coward
Re: Is SPC-1 still relevent with massive cache systems?
There is nothing wrong with the benchmark, it is as relevant today as it was yesterday. What we need to wrap our heads around as an industry, is that storage architecture has changed, as have the results. What DataCore has proven here is that the storage market today has to be a blend of compute & storage in order to maximize IO and performance in general. Secondly, what they have proven, is that the days of the high dollar, stand alone, monolithic storage array, with custom asic's, etc etc, is very clearly not necessary in order to achieve performance, availability, value, or feature functionality. The game has changed, the benchmark is fine.
Thursday 16th June 2016 17:39 GMT DeepStorage
No huge RAM cache with HCI
HCI systems most definitely don't have huge RAM caches for two reasons:
1 - RAM is expensive in HCI. The Nutanix storage VM runs in 16-32GB of RAM. If they demanded 128GB for a big cache it would mean they could run fewer VMs on each host. Most VMware environments run out of RAM before CPU. Since VMware and Windows DataCenter Edition (to license Windows guests) cost $15K per host or so MSRP fewer VMs per host makes the whole solution much more expensive.
2 - Power outages. If an HCI system had even 4GB of write cache per node when power failed to the system, and yes I've seen several data center wide power failures generators don't always start like they're supposed to, then all that data would be lost making all the remaining data corrupt. After all if you've written 100GB of data but haven't updated the file system metadata when the system comes back the 100GB of data will be inaccessible.
Storage appliances address this by using NVRAM that detects the power loss and flushes the data to flash using a little battery or capacitor power embedded in the system. If VMware had a UPS monitoring service an external UPS could tell the HCI system that power was failing and have it flush the write cache like an XtremIO does. Unfortunately, unlike Windows or Linux, vSphere has no way to do this.
Friday 17th June 2016 01:25 GMT Anonymous Coward
Wrong. Re: No huge RAM cache with HCI
Re: "If VMware had a UPS monitoring service an external UPS could tell the HCI system that power was failing and have it flush the write cache like an XtremIO does. Unfortunately, unlike Windows or Linux, vSphere has no way to do this."
Wrong. Click here. https://www.google.com/?gws_rd=ssl#q=vmware+ups+monitoring
DeepStorage...in over your head?
Thursday 16th June 2016 18:48 GMT Anonymous Coward
ByteMe, you're forgetting something Re: Is SPC-1 still relevent with massive cache systems?
You've made is a fundamental mistake that is frequently made -- you have lots of company.
All storage uses DRAM cache and the amount of cache that is useful is a function of the workload.
If you go back in time and look at all the SPC-1s ever published, you would see that the average amount of DRAM cache used in a top-ten SPC-1 result has increased along a >>linear progression<< that is proportional to the IOPS delivered and the capacity of the storage. Some vendors go a little cache heavy (like the previous #1 Huawei) and some use less.
Have you looked at the amount of L1, L2, L3 cache in processors, and how rapidly that has grown as processors are getting faster? I suspect you haven't (otherwise you wouldn't have posted this).
When you do, you'll start getting the idea.
If not...then remember that all HDDs and SSDs have a DRAM cache built on to the disk. A long time ago, a typical 15K spinner might have 8MB or 16MB of DRAM. Today, a Samsung EVO-850 SSD has up to FOUR GIGABYTES of DRAM cache.
To save readers time, you'll find the following on page three:
Samsung EVO-850 LPDDR3 DRAM Cache Memory
1GB - (1TB model)
2GB - (2TB model)
4GB - (4TB model)
So...contrary to your argument, what this trend toward larger DRAM caches shows is that SPC-1 is working exactly, perfectly and predictably -- just as it should.
The thing I find amusing here is that the previous "Hardware Defined Storage" #1 (Huawei) used 4TBytes of DRAM cache to deliver 3 million IOPS -- but nobody even NOTICED that, much less COMPLAIN.
Now DataCore delivers 5.1 million IOPS using 2.5TBytes of Cache, and all of a sudden the benchmark becomes suspect.
ByteMe...maybe you should bone up a little before trashing the SPC-1 benchmark. A lot of the smartest storage people in the world have worked very hard over the last eighteen years to make sure it works and works right. I for one don't appreciate your bashing it when it's clear you haven't given it more than a few minutes thought.
Thursday 16th June 2016 21:05 GMT Flammi
Friday 17th June 2016 01:25 GMT Anonymous Coward
Then pray tell Flammi, what do you think SAP, Microsoft, Oracle and IBM are selling you when they sell you an IN-MEMORY DATABASE (for bloody millions of dollars)?
Google keywords are:
Oracle Times Ten
IBM DB2 BLU
Hint...the trick is to put the WHOLE DATABASE IN MEMORY. That's why they call it an in-memory database. I hear they're all the rage. You should check it out...
Or, maybe DataCore can do IO so fast that you don't need to spend millions on IMDB and perhaps just make your IO-constrained applications go 100x faster for a tiny fraction of the cost of IMDB?
Saturday 18th June 2016 09:54 GMT dikrek
Re: ByteMe, you're forgetting something Is SPC-1 still relevent with massive cache systems?
Huawei had a 68TB data set and 4TB cache, or a 17:1 dataset:cache ratio.
Datacore about 11TB and 2.5TB cache, or a 4.4:1 dataset:cache ratio.
Not even close.
You probably work for datacore and are understandably excited. It's a good number and does show that the engine can provide a lot of IOPS when unencumbered by back-end disk.
BTW: Here's why not all data in SPC-1 is hot.
In the spec here: http://www.storageperformance.org/specs/SPC-1_SPC-1E_v1.14.pdf
Look at page 32. Notice there's an "intensity multiplier" AND a "transfer address".
ASUs 1 and 2 do reads and writes, and are 90% of the data.
If you look at that page you'll see that there are 3 hotspot zones with clearly identified multipliers and limited transfer address ranges:
- ASU1 stream 2
- ASU1 stream 4
- ASU2 stream 2
For example, ASU1 stream 2 has a multiplier of .281 (28.1%) and an address range of .15-.2 (merely 5% of the total data in the ASU).
If you do the math you'll see that of the total capacity, 6.75% across those 3 streams is significantly hotter than the rest of the data. So if that 6.75% comfortably fits in cache in any of the systems in the SPC-1 results, there will be a performance boost.
Not all the systems measured in SPC fit that percentage in cache, but many do.
Datacore went a step further and made cache so large that the entire test dataset is only 4.4x the size of the cache, which is unheard of in any enterprise deployment. How many of you will have just 11TB of data and 2.5TB RAM? Really? :)
And, last but not least, something anecdotal - all I will say is we had Datacore fronting some of our systems and the overall performance to the client was overall less than native.
The servers used weren't the behemoths used in the SPC-1 test of course. But this may mean something to some of you.
Friday 17th June 2016 19:49 GMT Anonymous Coward
Given that this is basically software on commodity gear, and honestly not all that impressive gear. I think this could actually go much higher using off the shelf latest and greatest. I'd be very curious if they did a swap of the xeons to the broadwell equivalent how much this would jump keeping the same drives. As well as how swapping to NVMe SSDs would ramp up the performance.
Tuesday 21st June 2016 13:49 GMT Flammi
Yes, latest and greatest server hardware will most likely improve those results.
But I guess you didn't read D's previous post. He explained in detail what I also said.
The test is entirely in DRAM. There's no IO on backend disks or SSDs. So moving to NVMe won't change anything. The only thing they proved with this test is: Datacore had bloody fast DRAM. Wow... that's unique!
It's a useless test, that's as far from reality as it gets.