A Primer: The Art Of The Platform, SMART, And You
There are a couple of ways we can tell that Adata's SP920 shares more than its controller with Crucial's M550 if you don't want to dismantle your own SSDs.
Before I popped the top on our own samples, I thought to myself, "Oh, it looks like Adata leased Micron's firmware IP for the SP920." On the next page, you'll see that both drives use the same firmware revision, MU01. The M500 is up to MU03 MU05 now, but Crucial's M550 launched on MU01. That the SP920 employs similar nomenclature was the first real indicator of something amiss. And there's more to it than that.
You see, Marvell doesn't sell firmware. It simply sells its controllers. Whether Plextor, Micron, or SanDisk chooses to implement a feature is up to each company. Generally, that also means firmware has to be developed, creating a pretty big barrier to entry before you're able to take a Marvell-powered SSD and start selling it. For Adata to come out with something new from Marvell as it waits on LSI, and to do that quickly, required getting its hands on software that was fully-baked already.
And if the matching firmware versions hadn't tipped me off, there is another surefire way to know that two Marvell-based solutions are identical: SMART data.
Self-Monitoring, Analysis and Reporting Technology data is defined by the firmware architecture. If you want to track host LBAs written or power-on time, the firmware author has to enable that functionality. Since each Marvell-based implementation is unique, we see SanDisk using certain SMART attributes, while Plextor uses others. Sometimes they overlap; sometimes they don't. Micron's own implementation tracks RAIN activity. That is, if some flash fails, RAIN uses parity to recover the information that would have been otherwise unrecoverable. Marvell's newest controllers can use parity to protect against data loss as well, but RAIN is a beast of Micron's own creation.
So, when we see this, we know what's up:
| SMART Attributes (Raw Values, Decimal) | Crucial M500 480 GB | Crucial M550 512 GB | Adata SP920 512 GB |
|---|---|---|---|
| 01 Raw Read Error Rate | 1 | 0 | 0 |
| 05 Reallocated Sector Count | 1 | 0 | 0 |
| 09 Power On Hours | 181 | 247 | 83 |
| 0C Power Cycle Count | 50 | 23 | 16 |
| AB Program Fail Count | 0 | 0 | 0 |
| AC Erase Fail Count | 0 | 0 | 0 |
| AD Average Block Erase Count | 56 | 56 | 40 |
| AE Unexpected Power Loss | 36 | 17 | 12 |
| B4 Unused Reserve NAND Blocks | 8218 | 4403 | 4403 |
| B7 SATA Interface Downshift | 0 | 0 | 0 |
| B8 Error Correction Count | 0 | 0 | 0 |
| BB Reported Uncorrectable Errors | 0 | 0 | 0 |
| C2 Temperature | 171800002583 | 197570068506 | 180390133785 |
| C4 Reallocation Event Count | 17 | 16 | 16 |
| C5 Current Pending Sector Count | 0 | 0 | 0 |
| C6 Smart Offline Uncorrectable Error Count | 0 | 0 | 0 |
| C7 Ultra DMA CRC Error Rate | 0 | 3 | 1 |
| CA Percent Lifetime Used | 1 | 1 | 1 |
| CE Write Error Rate | 0 | 0 | 0 |
| D2 Successful RAIN Recovery Count | 346 | 0 | 0 |
| F6 Total Host Sector Writes | 26638204322 | 20741567941 | 15230511355 |
| F7 Host Program Page Count | 803332972 | 652193216 | 480081235 |
| F8 FTL Program Page Count | 1181515239 | 1240751859 | 724621376 |
I don't have a complete list of Micron's SMART data, but most attributes are carried over from previous models. Adata's SP920 isn't detected as exactly the same drive, so attribute names may vary based on the utility you use to view them. For example, Adata's own toolbox doesn't know the true names of each attribute. CrystalDiskMark has it mostly correct for the M500, and thus the M550 and Adata SP920. The raw values are don't change either way.
Some of these attributes are found in other drives as well. Some aren't. Intel's dalliance with Marvell's 9175 controller in the SSD 510 (a short-lived product that tided the company over until its SandForce-based solution was ready, oddly enough) featured Intel's own SMART attributes from the X25 days. And when the transition to SandForce silicon happened, those attributes followed.
So there it is. Had Adata used its own PCB and enclosure, we might not have stumbled upon this mystery. But we did, dug deeper, and the SMART data doesn't lie.
While we're here, though, let's make some observations. First, we're displaying raw decimal values. D2 is RAIN recovery count. The M550 and Adata SP920 both report values of zero. However, our 480 GB M500 didn't make it through the last year unscathed. I don't know exactly what that field represents. It could be a number of blocks, or actual data in KB or MB. Perhaps part of the flash went belly-up, prompting the drive to recalculate affected area values from parity.
And that's why it's good to have RAID support on Crucial's M550 and Adata's SP920. Micron was aggressive in transitioning to 128 Gb, 20 nm flash. While the process is much more mature today, we still like having a safety mechanism to protect our valuable information. The M500's parity ratio is 1:15, which is where the 480 GB capacity comes from. The M550 platform employs 1:127 parity to storage blocks, tying up a lot less of the drive's capacity. One gigabyte out of every 16 is reserved for RAIN on the M500. That's only one out of every 128 on the M550 and SP920.
I also love that Micron includes thorough write counter metrics. F6 is total host sector writes (think of this as the writes requested by the operating system in 512-byte sectors). Do the math for our 480 GB M500 and you get 12,702.09 GiB, or 26,638,204,322 sectors * 512 bytes each. Most drives expose this counter, and it's useful as a tool for calculating the beating a drive has endured.
Write amplification wears a drive down over time, reducing its performance. It's often a product of internal overhead, for example, shuffling a partially-filled block around during a program/erase cycle. This is normal. But it can greatly reduce the life of a client drive used for high-intensity write workloads, which is why enterprise-oriented SSDs are often substantially over-provisioned. The additional free space helps keep P/E cycles to a minimum.
We can see the result of that additional overhead through the F8 attribute, FTL program page count, which measures the number of 16 KB pages the controller has had to program. Our M500 went through difficult testing; I punished it over and over with long runs of full-span high-queue depth writes. Over its life, I've hit it with 18,028.50 GiB worth of page program operations. Compare that number to the host writes (12,702.09 GiB), and you can calculate that I've subjected the M500 to an extra 5300 GiB of shuffling and churning.
