Archive for the ‘SSD’ Category

Price per GB for SSD – why its not always the best yardstick

October 12, 2013 Leave a comment

Price per GB, performance and endurance are the yardsticks used to decide which solid state drive (SSD) to buy for use in a corporate data center or to use in a server or flash based storage array.

Are endurance numbers really comparable? Especially when you consider that one vendor might use consumer grade cMLC NAND while another might use enterprise grade eMLC NAND with vastly different program erase (P/E) cycles?  What was the write amplification factor (WAF) – the ratio of SSD controller writes versus the host writes –  that was used for the calculation?  One vendor might quote endurance in TB or PB written while another might use Drive Writes Per Day (DWPD).

One vendor might state fresh-out-of-the-box (FOB) performance numbers in IOPS on their datasheet while another might display steady state numbers.  One might use a synthetic benchmark tool like IOMETER which focuses on queue depth (number of outstanding I/Os), block size and transfer rates instead of an application based benchmark like SysMark which ignores all these criteria and focuses on testing how a real-world application might drive the SSD.  Even with tools like IOMETER whether IOMETER  2006, 2008 or 2010 is used will cause the results to vary.  To add further complexity, the performance numbers will vary widely depending on whether they were measured with aWoman Eating Fruit Outdoors queue depth (number of outstanding I/Os) of 3, 32, 64, 128 or 256.  To compound it one vendor might be looking at compressible data (Word docs, spreadsheets) while another might be quoting numbers for incompressible data (.zip files or .jpeg), some might be using SandForce (now LSI) controllers which compress data before writing it to NAND while others might not.  So what is an SSD buyer to do?  Get a drive from a vendor you trust and run your own benchmarks whether they are synthetic or application based and derive your own conclusions.

Now why do I find $ per GB as a yardstick amusing?  Consider this analogy – could we convince a Japanese consumer that the cantaloupe we buy from a local store for $2.99 here in California is equivalent to a musk melon purchased in Japan for $16,000 yen?  From a $ per melon point of view, the price differences are difficult for us to fathom but to a buyer of the $16,000 melon it is apparently a premium worth paying for.

Categories: DRAM, SSD

High frequency trading and SAS SSD

June 3, 2013 1 comment
High Frequency Trading

High Frequency Trading

Considering that more than half of all the stock market trades in the USA come from high frequency trading let us consider how the emergence of Serial Attached SCSI (SAS) SSDs helps this particular segment.

High Frequency Trading (HFT) involves looking for obscure signals in the market (including spikes in interest rates) using very high end servers, making trading decisions and conveying orders to the exchanges in microseconds (millionth of a second).  Sophisticated HFT algorithms on servers placed close to the trading exchanges, combined with technologies like wireless microwave instead of fiber optics, help ensure that trading decisions occur in micro-seconds. Such HFT applications typically use high end servers with multi-core processors along with hardware and firmware optimized for the lowest possible latencies.  This is where solid state drives come in.  With no moving parts, no noise, very low power consumption, 500x improvement in IOPS (100,000 IOPS  for SSD versus 200 IOPS from a 15000 rpm SAS HDD), what’s not to like about SSDs?  In terms of workloads, SSDs outperform HDDs when it comes to random small block (8KB or 4KB block size) workloads as found in apps like OLTP.

In enterprise SSDs you have a choice: Serial ATA (SATA) or Serial Attached SCSI (SAS).  Servers used in HFT would benefit from SAS over SATA SSDs.  Why is that you ask?

  • Multi-path: SAS SSDs offer dual-porting (for high availability – if one path to the data on the SSD goes down there is another path to access the same data)
  • Longer cable lengths (25 feet versus 3 feet for SATA) due to the use of higher signaling voltages by SAS.
  • Greater transfer rates or throughput: Between 6 Gb/s and 12 Gb/s for SAS.
  • Support for wide ports:  Multiple paths between the server and the SSD device.
  • Data integrity end-to-end:  Achieved using cyclic redundancy checks (CRC) from the time data leaves the server travels to the SSD and returns back to the server.

To understand the need for SAS SSDs we must first understand what an SSD is all about.  An SSD comprises a device controller (made by Marvell, SandForce, Indilinx, PMC Sierra etc.,) behind which is NAND flash memory (made by Micron, Samsung, Toshiba etc.,) managed by a mgmt. system within the enclosure of the SSD.

NAND flash memory refers to non-volatile memory (contents are retained even when power to the circuit is shut off) using a logical circuit called a NAND gate.  The SSDs interface to the server could be SATA, SAS (6 Gb/s or 12 Gb/s) or PCIe.

SSDs write information in a sequential manner into NAND flash in contiguous blocks (each block has multiple pages each of which is ~ 8K in size).  Unlike mechanical HDDs which can merrily overwrite information, SSDs have a quirk in that to reclaim a page the SSD has to erase an entire block where the page resides.  (A human analogy might be where you and your significant other are enjoying a candle-lit dinner in a restaurant when the maître d’hôtel walks over to request that you move to another location in the restaurant as a celebrity party needs to be seated in a contiguous set of tables within the same section of the restaurant).  In SSD terminology the flash controller (maître d’hôtel in our human example) would be doing “garbage collection” by re-allocating data in pages within a block to a new block prior to overwriting the first block

Enterprise class SSDs are usually described in terms of:

  • Endurance or Program/Erase cycles (the more you write to a NAND flash cell the weaker it becomes eventually getting marked as a bad cell).  Wear leveling usually done by the flash controller refers to a way to prolong the life of the NAND flash blocks by distributing writes across blocks.
  • Write amplification factor (refers to the amount of data the SAS controller in the server has to write in relation to the amount of data the flash controller in the SAS SSD has to write)
  • Drive writes per day – DW/D (10 to 25 DW/D) over a period of many years (3 to 5 years).

When comparing SAS SSDs you’d look at features like:

  • Type of NAND (Usually MLC, eMLC or cMLC) used.
  • Performance at “steady state” not just out-of-the-box.
  • Mean time between failure (MTBF) and mean time to data loss.
  • Sustained read/write throughput in MB/s.
  • Read/write IOPS with 4 KB random operations
  • IOPS with a mixed workload of read and writes.
  • Encryption (128 bit or 256 bit AES compliant)
  • Unrecoverable bit error rates
  • Protection for any in-flight data in the event of a sudden power loss to the SSD
  • Extent to which SMART (Self-Monitoring, Analysis and Reporting Technology) attributes are supported

SAS SSDs are a good choice wherever you have enterprise class servers with workloads that have write-once read-many characteristics.  In conclusion, if you have high end applications like HFT running on enterprise class servers you need enterprise class SAS SSDs.  This is not to imply that only the HFT segment benefits from SAS SSDs, the same benefits can also be experienced across other verticals like Web 2.0 and  cloud computing.

Categories: Big Data and Hadoop, SSD