SSD Write Endurance 25nm Vs 34nm

[Anvil]

121,33TB Host writes
MWI 33

--

I've done some checking and I do think we'll have to leave things as is, I'll change the labels to MiB, GiB, TiB and I'll put a "Hint" on TiB so that when the mouse is hovering on TiB written it will display TB written in the "Hint".

I've been through the source code and have adjusted for one event that wasn't recorded, the initial creation of the file used for random writes.

So, the GiB counter did not count the bytes written for when that file was created, essentially that means every time the app is started.

Having said that, this counter was never meant to be the only counter but we'll make it work for that as well. (as close as possible)
There is another source of writes and it is the internal database used for recording the loops, for every loop the stats are recorded so there is a 4KB blocksize update/write + the update of the Index. I'll check if I can get to those writes and add them to the running totals. (they don't amount to much but they are definitely producing writes)

Vapor, you can check the number of bytes written by the app by using the Task Manager->Processes
From the View->Select columns... menu option Enable I/O Read Bytes and I/O Write Bytes.

[johnw]

I guess there is a bug in either the Sandforce firmware or Anvil's app.

To narrow this down, we should compare with another SSD that tracks host writes.

Anvil, One_Hertz: How closely does Anvil's app GB/GiB written match up with the host writes attribute on the Intel SSDs?

[Vapor]

So that is a total of A = 271.9788 GB written by Anvil's app in four trials, in which (I think you mean) the SMART attribute increased by 256.

271.9788 / 256 = 1.0624172

(1024/1000)^1 = 1.024000
(1024/1000)^2 = 1.048576
(1024/1000)^3 = 1.073742
(1024/1000)^4 = 1.099512

So the units of the SMART attribute are hard to explain. They are closest to GiB, but still about 1% off from GiB.

I guess there is a bug in either the Sandforce firmware or Anvil's app.

Yeah, A = 272GB or 253.3GiB for an increase of 256 in the SMART attribute. Each 64 increase was very consistently 63.2-63.4GiB too. Until more data says otherwise, I'm going to take SMART attribute readings for SF-1200 to equal GiB.

Just ran 135.95GiB of writes to my X25-M 80GB G1 and it showed up as 136.72GB in SMART (and damn my G1 is slow and stuttery with this...35MB/s and a stall once every 5-10 seconds). It would be good if someone could double-check this with more writes--my G1 just doesn't want to take part in the party.

Started it back up on my Vertex 2s with Task Manager running, will let it run for awhile and see what differences there are, if any.

[Vapor]

Started it back up on my Vertex 2s with Task Manager running, will let it run for awhile and see what differences there are, if any.

354.69GiB written and reported by Anvil app vs. 354.6975GiB reported by Task Manager. Looks like any discrepancy is at the disk level or not there at all and just showing up due to the way I was measuring.

Going forward, it looks like A) it's totally fine to use Anvil's reported writes and B) SMART values are most likely in GiB.

[One_Hertz]

Anvil, One_Hertz: How closely does Anvil's app GB/GiB written match up with the host writes attribute on the Intel SSDs?

It is flawless. Anvil's app goes up by 0.23TB and the SMART data goes up by 0.23TB. I checked this back when I started also.

161TB. 17%. 15 reallocated sectors.

[johnw]

Going forward, it looks like A) it's totally fine to use Anvil's reported writes and B) SMART values are most likely in GiB.

I agree with A. But not B. From your data, it seems like the Sandforce SMART attribute has a bug. The attribute reports 256 of SOMETHING when Anvil's app reports 253.3GiB = 271.9788GB. The SMART attribute may be INTENDING to be in GiB, but what it is actually reporting is a unit that is about 98.9% of a GiB (about 1,062,000,000 Bytes). As you said, it is consistent -- consistently short of a GiB, meaning the firmware is recording 1% more writes than actually occurred if it is intending to be GiB. Alternatively, for all we know, it could be INTENDING to be in GB, but somehow it is missing some writes -- about 6%.

[bulanula]

Any update on the C300 vs M4 debate?

[B.A.T]

We will start as soon as Vapor gets his C300 in the mail today.

[gojirasan]

As far as Sandforce on-the-fly compression goes I think it would be very interesting to compare that to a different brand of SSD using NTFS compression. Then you'd basically have on-the-fly hardware compression vs. on-the-fly software compression. Sandforce is basically just using Stacker on a chip. It would be nice to estimate what if any performance hit you would take by just running your Crucial or Intel drive compressed. Even if it does reduce performance slightly it might be worth it if it increases the write endurance of the drive to match Sandforce for compressible data. It also might be interesting to try to use NTFS file compression with a Sandforce drive. I wonder what would happen. Would it reduce the size of the files even more? Make them bigger?

I remember back when Stacker was popular. Lots of people ran with fully compressed drives in those days. It would effectively double the size of the drive. In the SSD new world order with 60 GB and 120 GB drives becoming common it would seem to have found a place again. Strangely, I can't find a single third party drive compression program similar to the old Stacker. Is the built in NTFS compression really so good that it can't be improved? I vaguely recall some app that used zip files to implement an automatic compression scheme, but I don't remember much about it. I'm also curious about how such a scheme would work with a large ramdisk.

[johnw]

It is flawless. Anvil's app goes up by 0.23TB and the SMART data goes up by 0.23TB. I checked this back when I started also.

What are you using to read the SMART data?

I noticed that the RAW smart value from all Intel SSDs is in units of 32 MiB. But CrystalDiskInfo displays a field at the top called "Host Writes _____ GB", where it converts the 32 MiB unit field to GiB, but labels it GB.

It is really sad, it seems that almost all Windows programs incorrectly label GiB as GB, but almost all linux programs correctly label the units (and most give you a choice of GiB or GB). Incorrectly labeled units cause a lot of confusion. Besides the problems we are having monitoring TB written to our SSDs, the Windows trend of labeling the units incorrectly has apparently convinced countless newbies that formatting their drive somehow decreases the capacity by 10% or whatever. Arghhh!

[Computurd]

wow one hertz, your getting to the end (possibly) this is where the good stuff starts.... zero percent left

[B.A.T]

At 14:00 GMT+1 (summertime) I startet up the endurance test of my M4.
It's been running for 90 min and is doing well so far. If the speed stays at this level I'll be writing about 200 TiB in July.


How often do you want me to post updates?

[Vapor]

B.A.T, what is the Crucial equiv of MWI? AD, 05, or what? Know it when we see it move?

I think an update of like once a day should be good, maybe a little more often as 8TiB/day is very fast.

Should be running on the C300 within a few hours now

I wonder who will get 0 MWI first, johnw or One_Hertz?

[One_Hertz]

What are you using to read the SMART data?

I have been using the Intel Toolbox from the very beginning. Seemed like the most appropriate option.

163TB. 16%.

[johnw]

I have been using the Intel Toolbox from the very beginning. Seemed like the most appropriate option.

163TB. 16%.

In that case, you are actually reporting TiB, I think. I don't have an Intel SSD that has written more than 999GiB, so I cannot tell for certain what it reports at that level, but my Intel toolbox is definitely reporting in GiB, even though it labels it incorrectly as "GB".

You can double check by looking at the raw value for attribute 225 (0xE1). It is in units of 33,554,432 Bytes = 65,536 sectors = 65536 x 512 = 32 MiB .

Intel SMART attributes:

[johnw]

17.586 TiB written, 54 hours, sa177: 72/72/1392

26.387 TiB , 79 hours, sa177: 56/56/2174

If that 2174 is the average block erase count, and 56 is a number from 100 to 1 that normalizes the block erase count from none (100) to nominal max (1), then Samsung would appear to be specifying about 5000 block erases for their toggle flash (4960 at normalized 1, 5009 at normalized 0 ).

The problem is that if 2174 is the average number of block erases, then the WA is huge. Assuming 64GiB of flash on board, 2174 erases comes to 136TiB, which when compared to the 26.4 TiB written by Anvil's app, results in a ratio of 5.1.

If we take into account the 42GB of static data I have on the SSD, and assume Samsung does NOT do any static data wear leveling (I hope that is not true, but for the sake of argument just go with it), then there is only about 24.9 GiB free for Samsung to erase. 2174 * 24.9 GiB / 1024 = 52.8 TiB , which divided by 26.4 TiB results in a ratio of 2.0. Still seems high for WA.

I cannot make sense of the data. Anyone else have any ideas?

I suppose we will find out if Samsung has terrible write amplification in a few days or weeks -- if the Samsung 470 dies after much lower TiB written than the Intel or Crucial SSDs. Although if that happens, it will be ambiguous whether the early death was a result of high WA, or whether Samsung toggle flash has lower endurance than IMFT flash.

If only I could find a Samsung datasheet for the 470 SSD series SMART attributes. Intel and Micron both document their SMART attributes clearly in a datasheet. But if Samsung has such documentation, I cannot find it (their website is a total catastrophe -- even some of the consumer manual PDF files for the Samsung 470 SSD are broken)

[Vapor]

Got home about an hour ago for the long weekend...UPS attempted delivery of the C300 about 2.5 hours earlier than normal and I missed it.

Called to arrange to pick it up this evening from their warehouse...was hoping it would be there before 6:45ish but won't be there until 8PM and I'm going to be at a July 4th fireworks show then.

Have had over a dozen UPS packages attempted to be delivered and I missed it, only for them to go to the front desk and have someone sign for it there and have it wait for me. First time I've ever had a package not delivered and no special signature is required....grumble, grumble.

Oh well, C300 starts midday Tuesday and I will be home that day to receive it.

[johnw]

At 14:00 GMT+1 (summertime) I startet up the endurance test of my M4.
It's been running for 90 min and is doing well so far. If the speed stays at this level I'll be writing about 200 TiB in July.

How often do you want me to post updates?

I had been posting once a day, but I may post twice a day now, since as Vapor says, things are moving fast for these SSDs.

I notice that Micron does not appear to have a host writes SMART attribute. So are you reporting the TiB written from Anvil's app?

I also notice that your SSD has a threshold of 10 (not 1 or 0) for attribute 0xAD = 173 "average erase count of all good blocks". That "10" seems an odd value for threshold. Your raw value is currently 7. If we assume your SSD has 64,023,257,088 Bytes worth of good erase blocks (from Micron datasheet), then that comes to 417GiB of writes, as compared to your screenshot, 419.79 GiB written. So it seems to be reasonably good agreement.

Maybe we can start graphing the raw value of attribute 173 for the m4 and 177 for the Samsung 470. For the Intels, does attribute 233 (0xE9) have a raw value that we can graph?

Micron (Crucial) SMART attributes:

[B.A.T]

I'll post screenshot of Anvils app two times a day, and from 0xAD.

I had forgotten to turn on High power mode so my computer rested for a couple of hours while I was out. It's back running again and it will stay that way

btw does this look right? My 0xAD shows 11 = 64GiBx11=704GiB but Anvils app shows 1 TiB

[Anvil]

BAT

Change from HEX to DEC in CDI, (function -> Advanced -> raw values)

11h = 17

--

123.49TB Host writes
MWI 32

No other changes.

[Vapor]

Updated charts

Raw data graphs

Writes vs. Wear:


MWI Exhaustion:


Host Writes So Far:

(bars with a border = testing stopped/completed)


Normalized data graphs

Writes vs. Wear:


MWI Exhaustion:

[bulanula]

26.387 TiB , 79 hours, sa177: 56/56/2174

If that 2174 is the average block erase count, and 56 is a number from 100 to 1 that normalizes the block erase count from none (100) to nominal max (1), then Samsung would appear to be specifying about 5000 block erases for their toggle flash (4960 at normalized 1, 5009 at normalized 0 ).

The problem is that if 2174 is the average number of block erases, then the WA is huge. Assuming 64GiB of flash on board, 2174 erases comes to 136TiB, which when compared to the 26.4 TiB written by Anvil's app, results in a ratio of 5.1.

If we take into account the 42GB of static data I have on the SSD, and assume Samsung does NOT do any static data wear leveling (I hope that is not true, but for the sake of argument just go with it), then there is only about 24.9 GiB free for Samsung to erase. 2174 * 24.9 GiB / 1024 = 52.8 TiB , which divided by 26.4 TiB results in a ratio of 2.0. Still seems high for WA.

I cannot make sense of the data. Anyone else have any ideas?

I suppose we will find out if Samsung has terrible write amplification in a few days or weeks -- if the Samsung 470 dies after much lower TiB written than the Intel or Crucial SSDs. Although if that happens, it will be ambiguous whether the early death was a result of high WA, or whether Samsung toggle flash has lower endurance than IMFT flash.

If only I could find a Samsung datasheet for the 470 SSD series SMART attributes. Intel and Micron both document their SMART attributes clearly in a datasheet. But if Samsung has such documentation, I cannot find it (their website is a total catastrophe -- even some of the consumer manual PDF files for the Samsung 470 SSD are broken)

IMHO these are some of the good reasons to stay away from Samsung.

[Ao1]

In defence of the Samsung at the speeds it is writing it probably doesn't have any time to manage WA. Also faster write speeds leave less time for the NAND to "anneal". I'd guess this will become evident when the drive gets to MWI 1 (0 does not exist , at least on Intel drives).

As PE specs are based on minimum levels (not average) it should be possible to write well past MWI 1. I somehow doubt the Samsug will be able to though.

It would be good to see a representation of the writes speeds on the charts to balance things out a bit. One_Hertz for example took 14 days to write data that the Samsung has written in 3.3 days. One_Hertz MWI dropped from 100 to 86 over ~26GB of writes.

Also it would be good to see the relocated sector counts.

[Vapor]

It would be good to see a representation of the writes speeds on the charts to balance things out a bit.

Agreed, this is why I asked for typical write speeds If I had that, I'd make a chart of wear vs. write-days.

Seems just the Intels and Crucials have reallocated sector counts? Or does the Samsung 470 have it as well (SMART value 178 maybe)?

Here's the chart with the reallocated sector counts from the Intels added:

[johnw]

Also it would be good to see the relocated sector counts.

If you can figure out which of the 6 attributes that might be on the Samsung 470, I'd be glad to post it. Well, it could only be 178 or 235 (or none of the above), and neither of those have changed yet. If they change, I will post it!