• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Samsung 840 Pro SSD benchmarks

J

jwilliams4200

Senior member
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:

s6SV8.png


cKr6d.png


iZGPz.png


tv3bH.png
 
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 ..
 
hhhd1 said:
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 ..
Click to expand...

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.
 
Last edited:
Those 4k's are insane. I'm definately going to get one of these and work can have my 830 in exchange 😛
 
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 :

HQUf4.png

BnQD6.png

XojA7.png

DCImb.png
 
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)

Atdjo.png

0Ytkg.png

L8VUY.png

7InE5.png
 
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)

dqZlY.png

NxXz0.png

DG4zY.png
 
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!
 
Burner27 said:
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?
Click to expand...

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.
 
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.

asssdbenchsamsungssd840.png
 
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?
 
JellyRoll said:
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?
Click to expand...

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.
 
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 said:
Wow, I can't believe it, although you told me a while ago about this issue.
Click to expand...

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.
 
This it's my benchmarks on Samsung 840 Pro 256GB SSD
Numbers look completely wrong. 😱

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

9oJ7M.png


PeZyP.png
 
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.
 
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.
 
This it's 2 Samsung SSD 840 PRO 256GB in RAID, with C600 controller on a X79 motherboard.
The 4K values ​​were poor.

IU3ua.png


OikhZ.png
 
christer12 said:
This it's 2 Samsung SSD 840 PRO 256GB in RAID, with C600 controller on a X79 motherboard.
The 4K values ​​were poor.
Click to expand...

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.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top