IBM has upgraded its SAN Volume Controller to use Nehalem (Xeon 5500) processors and STEC solid state drives, rather than the Fusion-io cards that were demonstrated in the million IOPS QUicksilver project.
The SAN Volume Controller (SVC) is located in a storage area network (SAN) fabric and virtualises IBM and certain third- …

Re: Strange?

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.

More FlashDancing and STEC-pumping

Barry Whyte didn't say that IBM "dumped" Fusion-IO for STEC. They just chose to highlight STEC for SVC at the present.

Mr. Whyte's superficially plausible technical arguments don't totally pass the smell test however, because he neglects to even acknowledge the economic aspects of the decision for IBM.

There are certainly applications where SSD in a PCIe slot is the best approach, and there are profit-motivated scenarios where it makes more sense to pump STEC vs. Fusion-IO.

What Barry Whyte ignores is this: when IBM (or EMC, or Compellent, or anyone else) sells a STEC, they turn $20,000 in revenue at 50% gross margins. When they sell a Fusion-IO unit they turn $3,000 in revenue at 40% gross margins -- for the same SSD capacity.

But the decision storage vendors face is even bigger than that. For OEMs like IBM (and especially SAN players like EMC, Pillar Data, Compellent, etc.), the SSD game is all about OEM-profit-per-IOPS delivered to the application, and that's where STEC really shines.

Consider that in IBM's STEC benchmark, (SPC-1C/E), the revenue generated by the ZeusIOPS drives is $2-per-IOPS. In SPC-1, 84 STEC units delivered 300,000 IOPS -- about 3,500 IOPS per SSD. (FYI, these results actually show a HIGHER price-per-IOPS than HDD running the same benchmark!!!)

In STARK contrast, for IBM's Quicksilver test, 41 of the Fusion-IO drives delivered 1,000,000 IOPS. That's THREE TIMES as many IOPS from HALF AS MANY SSDs.

Now consider: that amounts to 24,000 IOPS for $3,000 (Fusion-IO) compared to 3,500 IOPS for $20,000 for STEC.

That's about $0.13 per IOPS (Fusion-IO) vs. $2.00 per IOPS (STEC).

Since these devices are both based on SLC Flash, it doesn't require a technical genius to figure out that there is about 100X higher OEM-profit-per-IOPS in selling STEC vs. Fusion-IO.

Now...if YOU were a Storage OEM trying to squeeze maximal profits out of the the SSD hype-cycle (at the very peak of customer confusion), where would YOU invest your BenchMARKETING budget?

It's that old simple rule again...FOLLOW THE MONEY. That's why EMC and IBM and virtually EVERY other SAN vendor is pumping STEC...for now.

That's also why STEC is doomed.

With the Intel/Micron joint-venture now focused on building it's own Fusion-IO clone instead of building a SAS SSD, with Samsung as the new "virtual" owner of Fusion-IO, with Sun's replacing the F5100 with the F20 PCIe card in Oracle's Exadata2, all of the NAND Flash silicon vendors have aligned themselves with the "Flash-on-the-motherboard" approach, because this is the only path to meaningful volume in the Enterprise Flash game.