Posts by Barry Whyte

Apples and Oranges

Disclaimer: I work for IBM and was involved with the V7000 all SSD publish.

1. V7000 like 3Par is clusterable.

V7000 publish used a single system, but can linearly scale to 4 control enclosures

So 4x the 120K published number.

3Par used essentially equivalent to 2 control enclosures, hence double the performance.

2. V7000 = 18 drives

3Par - 32 drives

3. SPC-1 tests benefit from cache to usable capacity of storage ratio. Hence with the 1TB usable and 64GB cache in 3Par - much higher cache hit chance than V7000 with 3TB usable and 16GB cache...

If done apples to apples, I thnk you'd find they are both limited by the SSD performance and not the controllers.

As with all things performance - devil is in the detail.!

One more for the Sun fan-boy masses...

Oracles Z stuff used :

8x 512GB SSD

8x 73GB SSD

and 280x 15K RPM disks

Total SSD capacity = 4680GB

Total HDD IOPS = 280x 300 = 84,000 IOPs just from the HDD

So the SSD only contributed : 137,000 - 84,000 = 53,000 IOPs

Which based on 4860GB is 10.9 IOPs/GB

V7000 used 18x200GB = 3600GB

120,000 IOPs

So is 33.33 IOPs/GB

Maths speaks for itself

sustained iops after 6-9 months

what do they sustain after they have been around the block a few times... consumer grade flash devices will fail and will degrade... there is a reason enterprise "class" ssd cost so much

makes sense

Interesting... V7000 released 4Q20120, and saw a MASSIVE increase in sales in 4Q2011... with V7000 Unified... maybe its all making sens (on the IBM numbers anyway)

Re: IO-IO

To IO-IO Hmm... I was trying to work out which vendor you work for. Initial thoughts were an EMC or NetApp employee, but looking through your recent replys on el Reg, you've not only slagged off IBM but EMC, NetApp and also HP...

The only thing you have commented positively, and with some technical know how about is 3Par - which leads me to believe the large chip on your shoulder is something to do with the recent aquisition...

Now clearly you don't understand SVC, nor the advantage to moving virtualization OUTSIDE the array - and virtualizaing heterogenous environments with a "no distruption when that array has to be replaced" approach.

You make comments as to "why IBM developed SVC" when you have no factual knowledge of why we did it - also that SVC is designed as enterprise by a team who have worked on enterprise storage for over 20 years, and has reliability levels that rival the mainframe itself.

You also claim IBM has no storage portfolio, sighting un-competitive products etc - where have you been sleeping the last 24 months... XIV and V7000? The most innovative gender disruptive storage products for some time...

Suggest you work out why that chip on your shoulder has grown so large and work on reducing it rather than swiping at everyone on here.

devil in the detail

Chris, as always the devil is in the detail.

Pillar = 292x 15K RPM drives

V7000 = 240x 10K RPM drives

The difference in response curves will be down the the relative rotational latency (and throughput) of the drives.

Clarifications :)

Good to catch up yesterday Chris, and nice article - my quote re virtualizing external storage was "we are happy for people to run external virtualized storage with production workloads, not just archive data like some other vendors"

At present there is no dedupe built into the V7000.

The GUI is "XIV style" but has been completely re-written to run browser side, rather than a java application.

I don't think we clarified yesterday, but the SATA drives, area actually Nearline SAS - so a SATA spindle but dual ported SAS interface.

On page 3 you mention XIV 3 times, when I think you mean SVC.

snoop snoop dog

With the AMD snooping overhead - like over 50% performance when 4-way - a dual hex core... thats one hell of an overhead on snoops

what about Z

If HP bought up 3PAR and hence probably butcher their relationship with HDS, then they'd lose Z attach - therefore I don't see it happening.

Re: Strange?

Not strange at all.

The FusionIO card is a great card for high speed direct attached storage. If you have an application that needs non-shared storage, then we offer the ioDrive on our System X hardware.

If you want SAN based SSD storage, then we are using STEC due to the form factor as I mentioned.

Hey for that matter, we support TMS RAMSAN behind SVC if you want one of them (but check out the performance compared with SVC+SSD internally)

Its better to have all the bases covered. We can replace HDD with SSD in our DS range of products, we can provide you an SSD optimised controller like SVC or we can supply you some local high MB/s SSD in your servers... covering most of the bases wouldn't you say?

PS. Just to clarify, the 800,000 read iops is from the SSD's alone. (I've actually measured closer to 900,000) but this is not an SVC limit, SVC itself will happily sustain over 1,500,000 read MISS iops (4KB) so the SSD alone is only a fraction of what the new CF8 nodes can handle.

Software vs ASIC

Chris, re your assertions about "software solutions" and "most mature thin provisioning" - I'd question the 'advantage' of having to develop an ASIC to perform a function that is basically performing memory compares. The Intel SSE hardware that does direct memory compare functions at 64bit word size with almost no impact to other standard CPU processing is a much more sustainable and cost effective way of doing zero detection. It took us 20 lines of assembly what 3Par need an ASIC macro for. Given the speed of Nehelam Xeons, with 20+ GB/s memory bandwidth per die... Similarily, since 3Par are, as I've said before the "grand-daddy" of thin provisioning, what have they been doing for the last 5 years... SVC got "Space-efficient" this time last year, and now we can migrate thick to thin, inline strip out zeros... and lots more on the horizon... I really don't think ASIC based, offload hardware is the future of our industry, commodity CPU with offload software is much faster to develop and generally agile

Re: Not just Intel... look at STEC BS

Disclaimer : I work for IBM, not STEC.

Before casting aspersions, maybe the "anon coward" here should do some homework. The limit in the SPC-1 pSeries SPC is not the STEC drive, but the SAS HBA and ESM units used to connect to the SSD. If you benchmark an STEC drive in the right enclosure / fabric you can SUSTAIN around 45,000 IOPs (read) and 17,000 IOPs (write) from a device when doing 4KB blocks.

SPC-1 uses between 8KB and 16KB blocks, and as we all know, SSD IOPs half as you double the block size, therefore at say 12KB this would bring the number down to around 6,000 IOPs for SPD-1

Go do the maths before you start mud-slinging.

only 2x?

Not sure why everyone gets so worked up about MB/s - this is only 2x or maybe 2.5x a fast HDD... what are the IOPs numbers, then we can see if these really make a difference.

RE: Even less endurance?

@anon

A couple of generations back, SLC was at over 1,000,000 raw writes per cell. Now we are at 100,000 - so yes there is a direct correspondance with the number of electrons per bit and how stable these are over time.

Maybe its not down to 1,000 but it will be lower than 10,000. With MLC drives today, performance is a lot lower than SLC - thus the number of writes you can do in 5 years reduces - however, the only reason that 'effective' lifetime can be 5 years is because of the over provisioning of the raw capacities - hence my comment re the need to over provision more. Look at some of the latest MLC devices - these have 50% effective capacity - vs much higher effective capacity on SLC devices.

I think we are in agreement however, SLC will become the standard requirement as dies shrink for the SSDs used to replace HDD, but MLC will continue to be driven by the consumer (mobile) requirements.

Apples and Oranges

So how many 8K IO/s does it do?

What I've found with all flash devices is that the IOPs halve as you double the transfer size.

200K at 2K, says 50K as 8K etc...

This is a fairly fundamental aspect of all flash devices. Which is why they only can do about 5 or 6x a traditional HDD in MB/s.

The ultimate question is mixed performance however, everyone can do amazing read only performance, but what happens when the workload is a much more typical 70/30 or 50/50 mix of reads and writes... that separates the men from the boys...

As for the question of RAID'ing Fusion, sure they appear to a system as a block device, so you can run software RAID in a core on the OS and get as much performance as your core can give you...

Devil is in the detail

While I knew this box was coming from Woody and co at TMS, and in principle the concept is similar at a high level to what we demo'd as Quicksilver, in this case the 1M comparison is not apples for apples.

Our 1M IOPs was run with a mixed 70/30 ratio of reads and writes at 4K blocks. We all know that writes are the problem child for flash, and in some cases mixed workloads are even worse.

The TMS spec sheets don't give anything other than 100% read numbers, and doesn;t qualify at what transfer size.

If we take this at face value, and assume its small blocks 512byte or 1K, then the real number to compare this against Quicksilver would be 4.7Million IOPs. That is, if we had quote pure read numbers for Quicksilver. That would however have needed more SVC nodes, and several more fully populated Power Systems 595 hosts...

I'd like to see the 'details' - as I'm interested what the RamSan can do with a more realistic real-life workload.

LMAO

CX4 considered tier 0/1 - yeah in your dreams. A windows box running your top tier storage... hehe

Seriously though, not sure how many CX customers will be paying the $30K per SSD to put in a mid-range box. Maybe its an admission that a big box like DMX isn't needed anymore?

Anyway, Chris's tone here is 'very register' and I counter some of his points over here :

http://www.ibm.com/developerworks/blogs/page/storagevirtualization?entry=some_people_are_hard_to