Investigating the issue

** Edit ** (24 Sep)

We have updated this story with temperature effects on the read speed of old data. Additional info on page 3.

** End edit **

** Edit 2 ** (26 Sep)

New quote from Samsung:

"We acknowledge the recent issue associated with the Samsung 840 EVO SSDs and are qualifying a firmware update to address the issue.  While this issue only affects a small subset of all 840 EVO users, we regret any inconvenience experienced by our customers.  A firmware update that resolves the issue will be available on the Samsung SSD website soon.  We appreciate our customer’s support and patience as we work diligently to resolve this issue."

** End edit 2 **

** Edit 3 **

The firmware update and performance restoration tool has been tested. Results are found here.

** End edit 3 **

Over the past week or two, there have been growing rumblings from owners of Samsung 840 and 840 EVO SSDs. A few reports scattered across internet forums gradually snowballed into lengthy threads as more and more people took a longer look at their own TLC-based Samsung SSD's performance. I've spent the past week following these threads, and the past few days evaluating this issue on the 840 and 840 EVO samples we have here at PC Perspective. This post is meant to inform you of our current 'best guess' as to just what is happening with these drives, and just what you should do about it.

The issue at hand is an apparent slow down in the reading of 'stale' data on TLC-based Samsung SSDs. Allow me to demonstrate:

840-evo-512-test-hdtach-2.png

You might have seen what looks like similar issues before, but after much research and testing, I can say with some confidence that this is a completely different and unique issue. The old X25-M bug was the result of random writes to the drive over time, but the above result is from a drive that only ever saw a single large file write to a clean drive. The above drive was the very same 500GB 840 EVO sample used in our prior review. It did just fine in that review, and at afterwards I needed a quick temporary place to put a HDD image file and just happened to grab that EVO. The file was written to the drive in December of 2013, and if it wasn't already apparent from the above HDTach pass, it was 442GB in size. This brings on some questions:

  • If random writes (i.e. flash fragmentation) are not causing the slow down, then what is?
  • How long does it take for this slow down to manifest after a file is written?

Just to double check myself, and to try and disturb our 'stale data' sample as little as possible, I added a small 10GB test file and repeated the test:

840-evo-512-test-hdtach-3.png

Two important things here:

  • An additional HDTach read pass did not impact the slow read speeds in any way. This means that if there is some sort of error process occurring, nothing is being done to correct it from pass to pass.
  • The 10GB file appears at the end of the drive. For those curious, the saturation speed (nice flat line at the max SATA speed) is simply how Samsung controllers return requests for unallocated (i.e TRIMmed) data. Since the SSD has zero work to do for those requests, it can instantly return zeroed out data for those requests.

Now to verify actual file reads within Windows. Simplest way shown here:

New 10GB file:

10gb-test-read.png

'Old' image file:

test-file-read-5.png

The above copies (especially the large older file) are nearly identical speed profiles to what was seen in HDTach. It's important to do this double check when using HDTach as a test, since it uses a QD=1 access pattern that doesn't play well with some SSD controllers. Not the case here, as despite the slow downs, the EVO's controller itself is snappy, but appears to be dealing with something else slowing down the process of data retrieval.

Let's dig further, with some help from the community:

« PreviousNext »