Samsung 840 Pro SSD benchmarks

[jwilliams4200]

Here is a benchmark thread for Samsung 840 Pro SSDs. Please post your benchmarks.

To get started, here are some for my 256GB Samsung 840 Pro:

 

[hhhd1]

Really nice 4k numbers.

used 12 wear levels cycles and with only a single power cycle count and ZERO power-on time, sounds like an unreasonable amount of data copying and benching, what are you doing with it ..

 

[Remobz]

In summary..................?



http://www.youtube.com/watch?v=Ha1wS6evwl4

 

[jwilliams4200]

used 12 wear levels cycles and with only a single power cycle count and ZERO power-on time, sounds like an unreasonable amount of data copying and benching, what are you doing with it ..

That was not me. I took the SMART data before I wrote anything to the SSD.

It is odd that it is showing an attribute 177 value of 12, but the LBAs written (attribute 241) 497447 x 512B indicate about 255MB of host writes.

So the question is what is attribute 177 counting? I did a full drive sequential write (QD1, 128KiB block size) and attribute 177 increased by 1 while attribute 241 increased by 500118016 x 512B = 256.06GB. So it seems attribute 177 is probably counting average number of erase cycles for the flash (+/- 0.5), and attribute 241 is indeed counting host writes in 512B increments.

So, it looks like Samsung may have done about 255MB of host writes as a burn-in test. But I don't understand the 12 x 256 GB = 3TB of block erases that attribute 177 seems to indicate. No way is the write amplification 12,000. My best guess is that Samsung has a special way to do a lot (about 12) of block erases to the flash without actually writing to the LBAs, and that Samsung does this as a burn-in test and/or to determine the faulty flash cells so that they can be marked bad. Or maybe the flash chips are tested separately before being soldered to the circuit board, and they all get erased 12 times, so Samsung just initializes attribute 177 to 12 on all the SSDs.

I tried a secure erase but attribute 177 did not increment, so that cannot explain it.

 

[Coup27]

Those 4k's are insane. I'm definately going to get one of these and work can have my 830 in exchange

 

[jwilliams4200]

I benchmarked my 256GB Samsung 840Pro again after upgrading the firmware to DXM04B0Q.

In another thread, I mentioned a difference I noticed in ATTO on the 128GB Samsung 840Pro between firmware -3B0Q and -4B0Q. I did not notice a significant difference in ATTO between firmwares on the 256GB model.

I did notice something about ATTO and the 840 Pro. With QD of 3 or greater, the sequential write speeds for large blocks (usually 256KiB or larger, the exact behavior is a little erratic, some block sizes don't always drop) drops a bit, from over 500MB/s to about 475MB/s. That does not happen with QD1 or QD2.

First, here are ATTO benchmarks for the old -3B0Q firmware 256GB Samsung 840Pro, for QD1,2,3,4 :

 

[jwilliams4200]

And here are ATTO benchmarks for the new -4B0Q firmware 256GB Samsung 840Pro, for QD1,2,3,4 :

(not significantly different than with the old firmware)

 

[jwilliams4200]

And here are ASU, AS-SSD, and CDM benchmarks for the 256GB Samsung 840Pro with the new -4B0Q firmware:

(not significantly different than earlier benchmarks I posted in this thread with the old firmware)

 

[Burner27]

Jwilliams--Is your system OC'd? I would be curious as to what your BIOS settings are. Perhaps you could list the SPECs of your system as well please?

Thanks!

 

[jwilliams4200]

Jwilliams--Is your system OC'd? I would be curious as to what your BIOS settings are. Perhaps you could list the SPECs of your system as well please?

No OC. What you see on the ASU lower-left corner is accurate. The motherboard is an Intel DH67GD.

I do always run one thread of Prime95 in the background when doing benchmarks like this.

 

[GPz1100]

Jwilliams, same drive here, but somewhat slower benchmarks. Not sure what other drives you have attached to your system, but I have mine maxed out and then some. The board supports 8 sata devices, I have 10. The 2 additional are connected via add in pcie cards (1 drive per card). I suspect the overhead is what's possibly lowering my speeds. Either way, it's still plenty fast.

This is with the new firmware. Not a whole lot of difference between old and new.

 

[JellyRoll]

John, why do you do one thread of Prime in the background? interesting.
Also, on the Atto screeny I am wondering what is that symbol for your drive, looks like a '+' ? or is that just from the compression of the image?

 

[jwilliams4200]

John, why do you do one thread of Prime in the background? interesting.
Also, on the Atto screeny I am wondering what is that symbol for your drive, looks like a '+' ? or is that just from the compression of the image?

You must be looking at a degraded copy of the image (probably your browser downsized it). I uploaded the full-resolution image, which you should be able to download and/or view 1-to-1. Anyway, it is drive i, displayed as [-i-].

With P67/H67 and Z77 chipsets, if the CPU goes into certain power saving modes, it affects the benchmarks, particularly the 4KQD1 reads and writes, but it also has an effect on some other parameters as well.

You can avoid the CPU power-saving penalty by turning off all C-states (Cx for several values of x, depending on the BIOS) in the BIOS, and for some BIOSes it may be necessary to disable EIST as well.

But it is easier just to run 1 thread of a CPU intensive task, which seems to keep the CPU in a state where SSD benchmarks run at optimal speed.

 

[JellyRoll]

Neat trick. I just tend to shut off all power saving features, since I am not concerned about my carbon footprint. We are all goners on the 21st anyway so im not stressing it.

 

[Ao1]

But it is easier just to run 1 thread of a CPU intensive task, which seems to keep the CPU in a state where SSD benchmarks run at optimal speed.

Wow, I can't believe it, although you told me a while ago about this issue.
Prime95 64bit - Torture Test 1 thread

Uploaded with ImageShack.us
No Prime95

Uploaded with ImageShack.us

 

[jwilliams4200]

Wow, I can't believe it, although you told me a while ago about this issue.

It surprised me, too, the first time I saw it. It does not seem like having the CPU periodically idling down should affect SSD speed (I tend to think of CPUs as operating on a nanosecond scale, and SSDs on a microsecond scale, so not even close). But I guess the C-states are operating on a time scale close to that of the SSD latency, so it does make a difference.

 

[christer12]

This it's my benchmarks on Samsung 840 Pro 256GB SSD
Numbers look completely wrong.

I use Gigabyte (X79) G1.Assassin 2 motherboard.

 

[jwilliams4200]

The X79 chipset and the RST drivers and Windows seem to have some weird interactions. I don't have an X79 myself, so I am just speculating based on posts from other people. But you probably need to experiment with the windows cache settings. Try checking "Turn off Windows write-cache buffer flushing on the device" as a first experiment.

Try searching other forums about X79 and cache settings. Others have already written about the issues.

 

[ryderOCZ]

1. disable C1E in the bios
2. receive benchmarking greatness
3. ?
4. Profit.

 

[christer12]

Maybe not so much better D:

Disable C1E in the bios

 

[ryderOCZ]

Not in ATTO, but your numbers in AS-SSD should be quite a bit better.

 

[christer12]

Wow, when it became a little better in AS SSD! :awe:

 

[Ao1]

Asrock Z77 Xtreme11 - Onboard LSI controller (SAS2 2308 Mustang)

840Pro - Power states enabled


Uploaded with ImageShack.us

840Pro - Power states disabled


Uploaded with ImageShack.us

840Pro - Power states disabled with Prime95 running on one core

Uploaded with ImageShack.us

Overall the LSI controller is quite disappointing.

 

[christer12]

This it's 2 Samsung SSD 840 PRO 256GB in RAID, with C600 controller on a X79 motherboard.
The 4K values ​​were poor.

 

[groberts101]

This it's 2 Samsung SSD 840 PRO 256GB in RAID, with C600 controller on a X79 motherboard.
The 4K values ​​were poor.

That's because ALL Intel raids have write-back caching disabled by default even though it shows a false positive. Enable it.. and those 4k writes will nearly double.

2 ways to go about it and ends at the same result.

Go to device mgr>disk drives>choose your arrays volume>policies tab>UNcheck the default setting(top box)>click OK>.. reselect disk drives>choose your arrays volume once again>policies tab>REcheck the default setting(top box)>click OK>..

Then retest the newly activated write-back caching.

OR.. use the IRST raid manager apps "enable write-back caching" and achieve the same thing as the settings are identical to the above method.