EMC's DSSD rack flashers snub Fibre Channel for ... PCIe

Disclosure - EMCer here.

What the comments re: latency of FC vs. PCIe miss is parallelism (and system level latency envelope is a combination of latency and parallelism).

FC is quite serialized between initiator and target (as you would expect it to be, having been designed as a extension of SCSI direct connectivity).

This is A-OK for IOps bands that are in "normal" array bands even in good AFA bands (think (100-1M IOps, latencies below 1ms).

PCIe is designed fundamentally parallel, with the ability to issue many, many, many outstanding IOs.

If you had a target which aimed for doing, let's say 10x+ more IOps than even the best AFAs, and doing it with latencies that were, let's say 10x+ lower, and wanted a system bandwidth that was lets say 10x+ higher - you would of course need a lot more parallelism inside the target than you see, even from the best AFAs (XtremIO as an example)....

And remember - this is not designed to compete with AFAs per se, but target entirely new workloads which eschew LUNs and filesystems as persistence targets.

... add it all up, and well, the "FC attached flash" is low latency enough argument doesn't hold up (technically).

"With an all-flash-array you can easily achieve sub-millisecond response times"

Try not to use the word "sub-millisecond" as this is still potentially orders of magnitude slower than microsecond. Sub-millisecond was brought in to marketing to combat Violin who were claiming low microsecond latencies. Sub-millisecond includes 999 microsecond latency, which is 10 times slower than 100 microsecond latency and 100 times slower than 10 microsecond latency. What many people forget while thinking these times are so low it doesn't matter, is that one clock cycle of a modern Xeon is very short indeed - 4 billionths of a second in fact. This means that is your storage could operate at 1 microsecond latency, the CPU still had to wait 4000 cycles for the information to arrive. If you look at a worst case marketing "sub millisecond" latency of 999ms then the CPU will be waiting around 4000000 cycles.

To the average Joe with an average estate and average workloads, this doesn't matter. Most of the time VMware will fill in the blank cycles with other work anyway. For those that need the performance though, this is all critical stuff even if EMC do appear to have photocopied someone else's technology with the anti-patent filter engaged.

Re: Linux Controllers don't add any latency?

"This is why it's such a head scratcher to me when people say its a "bad thing" to acquire"

It's not a bad thing to buy good tech - it's what happens next that counts. The reason tech acquisition is often frowned upon is because tech companies often just change the logo and call it their own rather than taking that technology and merging it into their own over time. One only has to look at the HP stoage line up to see this in action with completely different technology in every product and no attempt to cross pollinate. If the LeftHand network RAID is so great, how come 3Par hasn't added it in? If ASICs are so great, how come LeftHand still uses a Xeon? All they have done is paint the LeftHand yellow, and even then one of the fascias is upside down!

If acquisition leads to conflicting marketing material through your range then yes, it's a bad thing. Dell are surprisingly good with this, they are slowly but surely merging their various acquisitions into all of their products. Microsoft also are usually good with this sort of thing with some notable exceptions.