Home > Big Data and Hadoop, SSD > High frequency trading and SAS SSD

High frequency trading and SAS SSD

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
  1. Nitin
    June 16, 2013 at 8:30 pm

    Excellent article, explaining about why SSD, but somehow i felt article doesn’t pin-point, how ‘SAS’ and not ‘PCIe’ is better for HFT.
    (Note: doesn t SATA supports speeds of 6 ~ 12 GBPS ?)
    In my opinion, PCIe has zero protocol overhead, whereas SAS & SATA based SSD’s have it, Therefore, PCIe based SSD’s should be more suited for such high end usage

  1. No trackbacks yet.

Leave a comment