« 3.015: mmphmy hlmmphums, emphmgmy! | Main | 3.017: vmax 2011 edition - powerful. trusted. smartest. »

January 16, 2011

3.016: commodity vs. custom, hu cares?

imageNigel Poulton has written a fair and insightful post over on his blog comparing EMC’s VMAX to Hitachi’s VSP. In it, he notes Hitachi’s use of not one but FIVE custom ASICs, as compared to VMAX’s single custom chip. He also (rightfully, IMHO) points out that it is likely these custom ASICs that caused Hitachi Japan to deliver VSP to market nearly 18 months later than VMAX, even though both use the same generation of Intel processor (quad-core Harperton) and the same first generation PCIe.

Even for a vertically-integrated company like Hitachi, ASICs take time – a LOT of time – to get right. Mess up one little thing, and you face months to respin the design and recast the die. And if you are doing low-latency memory I/O management, you face another respin each time the architecture changes; chips built for the PCIe gen 1 interface won’t work for PCIe gen 2 or 3, for example.

Hitachi’s Japanese engineering teams have invested heavily in the “hybrid” ASIC/Intel design for this “first generation” VSP. Maybe they had no choice – the USPV architecture doesn’t adapt well into Intel’s chip designs, where memory and CPU are tightly coupled, and not separated by a crossbar switch as is the foundation of the USP/USPV/VSP. By the way, I don’t think Hitachi’s architecture can survive long-term – in fact, I suspect that Hitachi Japan is hard at work right now re-architecting future VSP follow-ons to eliminate all the ASICs from their design. Looking at the designs of Intel’s next generation processors (Sandy Bridge/Ivy Bridge), they really have no other option.

This leaves Hitachi Data Systems’ marketing with no choice but to try to position the (temporary) use of ASICs as an advantage – even though it has already proven a significant time-to-market disadvantage. Japan has sent lemons, HDS has to make lemonade while they wait for the elves to finish redesigning their flagship enterprise array.

But back to Nigel’s post…

hu cares?

I was thus only mildly surprised to see Hu Yoshida’s comment response to Nigel’s comparison post. Hu has historically refrained from commenting on anyone else’s blog, but HDS’ SoMe team must be trying to get him more visibility. Hu’s comments read like a VSP brochure (it’s even nicely formatted, with section headings and everything!) – I wouldn’t be surprised if they were actually cut-and-paste from a data sheet.

As we should expect, sandwiched in between two inarguable truths, Hu’s comments assert that the VSP’s customization give it the advantage.

Hu starts out with this:

Custom or Commodity
With all due respect, this is irrelevant since the proof is in the end product’s feature, function, and competitive price.


He then goes on to make assertions that I cannot let go unanswered. For example, Hu claims that Hitachi’s version of automated tiering (Hitachi Dynamic Tiering) runs on cores OTHER than the ones that handle I/O, RAID and replication, and that these cores have their own separate metadata from the other metadata in the system. He (rightfully) suspects that VMAX FAST VP runs on the same cores as the ones that handle the I/O,

And he then claims VSP superiority because its approach doesn’t add overhead to the cores handling I/O workload.


Done right, automated tiering doesn’t add measurable overhead to the I/O workload. Done right, metadata management for tiering is a separate set of threads, running asynchronously to the I/O processing. Done right, metadata updates are infinitesimally small, touching bits only on cache-misses, where the delay of retrieving the data dwarfs the time it takes to complete metadata updates. Done right, the BEST place to handle tiering automation is in the cores that handle retrieving the data – this minimizes the complexity and overhead of coordinating between two separate processors (or cores).

Done right, managing tiering metadata doesn’t require separation from I/O metadata nor from the actual data cache. Done right, the memory architecture doesn’t add overhead to every access to the 3 different types of data. Done right, many of the memory access operations occur locally, directly over the memory bus, rather than having to reach out across the (slower) PCIe interface every time.

Done right, you adapt your architecture to leverage everything that Intel is putting into its chips, minimize your customization and, beat your competition to market by at least 18 months (I say this because many announced VSP features still aren’t shipping, months after its announcement).

VMAX: Done right.

Hu goes on with more of the usual HDS kool-aid, but while I can (and will) challenge a lot of what he tries to assert, I have to agree with his concluding remark:

It really doesn’t matter whether the insides are custom or commodity. The market place will decide, so let’s continue the conversation and ask customers what they think.

I firmly believe that Intel’s engineers give VMAX a competitive advantage, and that commodity gave VMAX an 18 month head start over custom.

I also believe that the marketplace has already decided. The votes have already been cast.

According to IDC Storage Tracker, if you compare the revenues of the IBM DS8K (all generations), Hitachi’s Lightning+USP+USPV+VSP (through all sources), and Symmetrix DMX+VMAX arrays (including those sold with Celerra gateways) for the past several years, you will find that Symmetrix gained about 10 percent market share through the first 3 quarters of 2010 (IDC won’t publish Q4’10 data until later this quarter). 10 points of share gain is huge, and it has almost all come at the expense of Hitachi.

Now, we can argue whether it is the VMAX hardware or software that’s driving its advantage. I personally think it’s really all about timing – having the right product, at the right price, with the right features, at the right time.

VMAX: Done right.

On Tuesday, January 18th, 2011, EMC will announce new record-breaking products in several areas – including VMAX. While Hitachi struggles to deliver functionality it has already announced (has anyone actually found the green eggs and HHAM?), VMAX is bringing new features, new performance and better efficiency to its installed base and new customers.

It should be an interesting year, to say the least.




TrackBack URL for this entry:

Listed below are links to weblogs that reference 3.016: commodity vs. custom, hu cares?:


Feed You can follow this conversation by subscribing to the comment feed for this post.


Disclaimer (I'm ex-EMC) and agree with most of what Barry has written. However, I do think customers find the following of interest with the VSP:

1. Density found via the use of 2.5" SAS drives.

2. The use of standard 19" racks.

3. The ability to buy a diskless VSP.

Looking forward to NYC on the 17th / 18th and would be happy to chat about our Symmetrix / VPLEX business and trends we are seeing in the Tier 1 marketplace.


The comments to this entry are closed.

anarchy cannot be moderated

the storage anarchist

View Barry Burke's profile on LinkedIn Digg Facebook FriendFeed LinkedIn Ning Other... Other... Other... Pandora Technorati Twitter Typepad YouTube


I am unabashedly an employee of EMC, but the opinions expressed here are entirely my own. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.

search & follow

search blogs by many emc employees:

search this blog only:

 posts feed
      Subscribe by Email
 comments feed

 visit the anarchist @home
follow me on twitter follow me on twitter

TwitterCounter for @storageanarchy

recommended reads

privacy policy

This blog uses Google Ads to serve relevant ads with posts & comments. Google may use DoubleClick cookies to collect information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide ads about goods and services of interest to you. If you would like more information about this practice and your options for not having this information used by Google, please visit the Google Privacy Center.

All comments and trackbacks are moderated. Courteous comments always welcomed.

Email addresses are requested for validation of comment submitters only, and will not be shared or sold.

Use OpenDNS