Author: Stephen Bates

Latency Variability

In my last post I talked about the transition to Low-Density Parity-Check (LDPC) Error Correction Codes (ECCs) in enterprise SSD controllers. I hinted that this transition has some interesting implications for the latency of next-generation SSD controllers and I wanted to expand on that topic in this post.

The latency associated with LDPC ECC in SSDs comes from three main sources:

1. The LDPC encoding process.
2. The LDPC decoding associated with the first read of the data on the NAND flash.
3. The LDPC decoding associated with subsequent reads of the data on the NAND flash. 

In a high-performance SSD the latency associated with item 1 is negligible and is often hidden from the user using techniques such as a write-back cache. However, the latency associated with items 2 and 3 cannot be hidden from the user.

Let’s break down the latency for items 2 and 3 a little further. The table below shows some of the major latency components associated with a random read on an enterprise SSD. It is interesting to see that only two of these have any variability (t_read and t_ldpc) and that the variability for t_read is much larger than that for t_ldpc (60us versus 19us).

The variability of the flash read time (t_read) is, in part, determined by the page index (some pages are inherently faster to read than others), while the remainder randomly varies from one read of the same page to another. Note that this variability is the same for both LDPC-based and BCH-based SSDs.

The variability of the LDPC decode time is a function of how many iterations it takes to decode the data from the flash. LDPC decoders typically employ an iterative decoding process, and the number of iterations is usually not known at the beginning of the decode. We often bound the number of iterations to some upper limit to constrain t_ldpc in case a decode is unsuccessful.

Things get interesting when we note that the number of iterations in an LDPC decode depends on the parameters of the LDPC code and the number of errors on the section of NAND flash where the read occurs. This implies we can influence t_ldpc by controlling either one or both of these two items.

The diagram below shows how the choice of LDPC parameters impacts t_ldpc across a range of NAND flash error rates.

When the number of NAND flash errors is very low, t_ldpc is the same for ldpc1 and ldpc2. However, as the number of errors increases, ldpc2 starts to exhibit less latency (t_ldpc) than ldpc1. In an SSD there are two ways to take advantage of this:

1. Static LDPC Configuration – If latency minimization is very important, then you might choose to use ldpc2 in your SSD rather than ldpc1.
2. Dynamic LDPC configuration – If your SSD supports dynamic configuration, you might choose to use ldpc1 when NAND error rates are low (i.e., at the beginning of the SSD’s life) and then transition to ldpc2 as the SSD NAND flash ages.

Note that a given SSD controller may have many more than two LDPC codes to choose from, in which case there will be more flexibility in trading between the parameters of the LDPC code and the latency associated with t_read.

Things get even more interesting when the initial LDPC decode fails. In that case, the next step is to return to the NAND flash and start working toward something called a soft-decision LDPC decode. We’ll talk about that more in the next blog post in this series.

Read Part 1 of the LDPC series: Transitioning SSDs to LDPC Error Correction Codes
Read Part 3 of the LDPC series: Soft-Decoding in LDPC based Next-Generation SSD Controllers