Samsung 840 Pro SSD benchmarks

[frief]

Originally Posted by jwilliams4200

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

My drive had an attribute 177 value of 24 within the first 1-2 hours!!!

Having written only about 128 GByte to it


S.M.A.R.T. attributes now are at:

smartctl 6.1 2013-01-02 r3742 [x86_64-linux-3.4.11-2.16-desktop] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 840 PRO Series
Serial Number:    S12PNEACB15543Y
LU WWN Device Id: 5 002538 55003fd17
Firmware Version: DXM04B0Q
User Capacity:    128.035.676.160 bytes [128 GB]

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       21
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       16
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       24
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   076   072   000    Old_age   Always       -       24
195 ECC_Rate                0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       1
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       292183437

Is anyone else seeing such a high wear leveling count on a freshly purchased drive?

[jwilliams4200]

I've have noticed that there is a wide variation in the raw value of attribute 177 on the new 840 Pros. Obviously my previous speculation about it being some sort of burn-in test is wrong, since that would be expected to create about the same count on every SSD. I don't know how to explain the variation.

But note that even 24 is not a large fraction of the total life of 3000 erase cycles -- it is less than 1%

[frief]

Originally Posted by jwilliams4200

I've have noticed that there is a wide variation in the raw value of attribute 177 on the new 840 Pros. Obviously my previous speculation about it being some sort of burn-in test is wrong, since that would be expected to create about the same count on every SSD. I don't know how to explain the variation.

Would it be possible that attribute 177 (at delivery) is used as a bit mask? So on my drive 24 = 16 + 8 = 2^4 + 2^3 the bits 4 and 3 would have been set?

But note that even 24 is not a large fraction of the total life of 3000 erase cycles -- it is less than 1%

Feels a little like finding out that a car that you bought as new had already been driven 2000km and the odometer had been reset to zero again.


There must be some reason for a non-zero value. An optimal drive would be expected to show zero, so any deviation from zero is likely to be an indication for something less than optimal.

Can you post a examples of attribute 177 together with attribute 241 and User Capacity?

[garikfox]

(removed)

[garikfox]

frief: Are you sure you got that new ?

My calculations say about 3TB have already been written to the drive

[frief]

Originally Posted by garikfox

frief: Are you sure you got that new ?

Yes. Package was pristine and Power_On_Hours started at zero.

I submitted the smartctl output of the drive when it still showed Power_On_Hours of 1 and already had attribute 177 of 24 to the smartmontools-database list: http://sourceforge.net/mailarchive/f...tools-database)

My calculations say about 3TB have already been written to the drive

Definitely not by me!

From attribute 241:
292183437 * 512 Byte = 149.6 GByte (which is plausible)

From attribute 177:
24 * 128GByte = 3.07 TByte
(which would require about 10000s of continuous writing at 300MByte/s)



Maybe I should add that I posted on a german speaking forum about a week before I posted here. (No solution there.) http://www.hardwareluxx.de/community...l#post19943660

[garikfox]

Lets see a CrystalDiskInfo screenshot, lets see how many Host writes it says, Im very curious to see this

http://release.crystaldew.info/redir...iskInfoShizuku

[frief]

Originally Posted by garikfox

Lets see a CrystalDiskInfo screenshot, lets see how many Host writes it says, Im very curious to see this

Sorry, the forum software doesn't seem to let me. "Insert Image" does not insert an image (instead only an URL to an image) and the instructions at http://forums.anandtech.com/faq.php?...b3_attachments do not work for me because the button labelled 'Manage Attachments' does not show up.

Apart from that CrystalDiskInfo shows the same number that smartctl reports (0x000011e784e5 = 300385509)

[garikfox]

What does CrystalDiskInfo say for host writes at the top ?

[Hellhammer]

When I tested the endurance of SSD 840, I had to refrain from using the SMART value for calculation because it was not accurate. At one point it stopped increasing and was basically changing between 3-4 for values, which made absolutely no sense.

[jwilliams4200]

The shipping firmware had a bug on the 840 where the LBAs written attribute stopped working at some point (I think it was around 2 TiB, but I'm not certain about that). I heard that the firmware update fixed that problem, but since I don't have an 840, I cannot verify that.

My 840 Pro (with latest firmware) seems to be recording LBAs written correctly. It is currently at about 3.5TB.

[frief]

Originally Posted by garikfox

What does CrystalDiskInfo say for host writes at the top ?

Total Host Writes 143 GB

Greetings,

[garikfox]

Wow, thats a mystery then why the Wear Leveling Count says 24, strange indeed

[hurleydood]

Originally Posted by jwilliams4200

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.

The question is what is the minimum amount number of bytes to test one P/E cycle on a 256GB drive?

It's 32MB.

1 byte minimum to write one 8KB page.
The 256GB drive has 32 million programmable pages (256GB / 8KB).
1 byte to each page equals 32MB.

Do this 8 times you should have exhausted 8 P/E cycles with only 256MB of writes. If that were actual data it would be 2TB written of a write amplification of 1x, here it's a write amplification of 8192x.


I have an older Patriot Torqx SSD 128GB drive with only 3.2TB written with average P/E of 4498. With the number of P/E cycles it looks the maximum I could have written is 562TB (4498 x 128GB) in sequential data. The calculation actually shows that I have a write amplification of over 175x (562TB / 3.2TB). Makes perfect sense because every time Windows writes a log file, NTFS journal, or Chrome or Firefox cache writes any number of bytes to disk no matter how small it's going to cause a minimum 8KB page write to the drive. It gets even worse when the drive is dirty as you have to erase an entire 512KB block and reprogram 64 pages to write single 8KB page or group of pages. I think the current marketing going on with write amplification of 10x is very optimistic.

[Hellhammer]

Originally Posted by hurleydood

The question is what is the minimum amount number of bytes to test one P/E cycle on a 256GB drive?

It's 32MB.

1 byte minimum to write one 8KB page.
The 256GB drive has 32 million programmable pages (256GB / 8KB).
1 byte to each page equals 32MB.

Do this 8 times you should have exhausted 8 P/E cycles with only 256MB of writes. If that were actual data it would be 2TB written of a write amplification of 1x, here it's a write amplification of 8192x.


I have an older Patriot Torqx SSD 128GB drive with only 3.2TB written with average P/E of 4498. With the number of P/E cycles it looks the maximum I could have written is 562TB (4498 x 128GB) in sequential data. The calculation actually shows that I have a write amplification of over 175x (562TB / 3.2TB). Makes perfect sense because every time Windows writes a log file, NTFS journal, or Chrome or Firefox cache writes any number of bytes to disk no matter how small it's going to cause a minimum 8KB page write to the drive. It gets even worse when the drive is dirty as you have to erase an entire 512KB block and reprogram 64 pages to write single 8KB page or group of pages. I think the current marketing going on with write amplification of 10x is very optimistic.

SSDs do write combining in order to write as little "useless" data as possible. That means the drive is not going to write a full page because of one byte, it's going to wait for another write request to come in and then combine the writes to be as NAND efficient as possible.

All SSDs report SMART values a bit differently so I don't think the value you're looking at is the number of exhausted P/E cycles. It could be the number of remaining cycles instead (would make more sense since it most likely has NAND with 5000 P/E cycles).

[hurleydood]

The erase counts keep on going higher.

Here is what CrystalDiskInfo says for the drive:

Total Count of Write Sectors 7,037,727,161
Max PE Count Spec 5000
Minimum Erase Count 3444
Maximum Erase Count 5342
Average Erase Count 4498
Remaining Drive Life 11%

Total Bytes Written 3.2TB = 7,037,727,161 x 512 bytes

Sure they will combine all writes for sequential data but it has to flush at some point and it will as the buffer will fill up from other pending writes to the disk. For best wear its probably best to turn off Windows write-cache buffer flushing so Windows can force a nice bulk write to disk. Safer for for laptops since you have a battery. Not so good for a desktop unless you have a battery backup.