# Thread: SSD Write Endurance 25nm Vs 34nm

1. So, m4's WA is really close to 1.0 or is it just showing that number 341 based on an assumed WA of 1.0?

2. 64GiB of NAND * 341 P/E cycles = 21.313TiB of NAND writes.

Compared to 20.0572TiB of Host writes, it does look like a very nice and low WA.

21.313 / 20.057 = 1.063x WA, makes me think it isn't assuming a WA of 1.00x.

3. Originally Posted by Ao1
SMART attribute 181 is interesting. Looking at the literature that John posted: "This attribute tracks the number of use data accesses (both reads & writes) where LBAs are not 4KB aligned or where size is not modulus 4KB, assuming logical block size = 512B."
2379446943762 = 0x22A02170012

So that is 0x217 * 60,000 = 32,100,000 non-aligned sectors written

Which, at 512B per sector, comes to 0.0149 TiB.

0.0149 / 20.0572 = 0.0745%

Or about 1 in 1342 bytes written is not 4K aligned. I wonder where that ratio comes from. Is that the ratio of random bytes written to total bytes written by Anvil's app?

4. Originally Posted by johnw
48.927 TiB, 141 hours, sa177: 18/18/4140
53.426 TiB, 153 hours, sa177: 11/11/4491

At this rate, the normalized 177 attribute should reach zero sometime after my next update, tonight.

By the way, at 53.426 TiB written, the Samsung 470 could write half its total available capacity, 32GB, every day for five years. So no matter what happens from here on out, I think the Samsung 470 has proven itself as having sufficient endurance to be able to tolerate most conceivable real usage scenarios.

5. Originally Posted by johnw
2379446943762 = 0x22A02170012

So that is 0x217 * 60,000 = 32,100,000 non-aligned sectors written

Which, at 512B per sector, comes to 0.0149 TiB.

0.0149 / 20.0572 = 0.0745%

Or about 1 in 1342 bytes written is not 4K aligned. I wonder where that ratio comes from. Is that the ratio of random bytes written to total bytes written by Anvil's app?
I think the M4 uses 8K pages with 256 pages per block.

Looking at Anvil's test file sizes they are a lot of entries that are not divisible by 4.

The new gen drives have lower PE and larger erase blocks, yet they still outlast 34nm drives.

EDIT:

Assuming a sector is 8k/ 8,192 bytes
32,100,000 non aligned pages * 8,192 = 262,963,200,000/ ~0.47TiB/ ~245GiB

6. guys is there any recommondation yet? I plan to buy a new storage ssd. I am off for long reliability, I totally don't care about insane high sata 3 performance.

7. Originally Posted by johnw
53.426 TiB, 153 hours, sa177: 11/11/4491

At this rate, the normalized 177 attribute should reach zero sometime after my next update, tonight.
John I'm really curious to see what is going to happen to your Samsung. If the static data has not been rotated a sizable portion of NAND will only have been written to once. I can't imagine the SSD would allow that to happen. If the data is rotated does it occur in idle mode or as a background task parallel to host activity? Maybe there is a critical threshold that will force the static data to be relocated to extend life?

Originally Posted by johnw

By the way, at 53.426 TiB written, the Samsung 470 could write half its total available capacity, 32GB, every day for five years. So no matter what happens from here on out, I think the Samsung 470 has proven itself as having sufficient endurance to be able to tolerate most conceivable real usage scenarios.
For fast sequential xfers this SSD is great.

8. Get the Intel 320 if you need most mature and reliable ssd because it has good endurance as shown here and also reliable controller with power capacitors etc.

9. Once the PE cycles have expired will data retention then be monitored? (i.e. how long will it remain read only) Maybe check the data integrity every 24hours?

10. Originally Posted by bulanula
Get the Intel 320 if you need most mature and reliable ssd because it has good endurance as shown here and also reliable controller with power capacitors etc.
I'm actually a bit down on Intel and the 320 SSD recently. A bug has shown up in the Intel 320 SSDs. It is somewhat random, but seems to be related to power-cycling, perhaps unsafe power cycles, perhaps sleep or hibernation. As far as I can tell, on any given power cycle the bug is unlikely to appear (at least I haven't had it happen to me yet), but given enough power cycles (and perhaps some random unknown factors), the bug seems more likely to appear. The bug is that the SSD becomes mostly unresponsive to most ATA commands, and shows as having 8MB (not GB) capacity. It is called the "8MB bug".

It seems people have reported this to Intel in May, perhaps earlier. So Intel knows about it. But they haven't issued any statements or warnings about it, and have not recalled the drives nor have they issued updated firmware. Rumor is that a fix is forthcoming in about a month, but no official word even on that. So I used to think a great deal of Intel on reliability and customer support, but my opinion of them has gone down quite a bit after this. If Intel issues a fix soon, they will partially redeem themselves, but not completely, since I do not like the way they have handled the situation at all.

http://communities.intel.com/thread/22227?tstart=0
http://www.pcreview.co.uk/forums/do-...-t4035508.html

11. Originally Posted by Ao1
Once the PE cycles have expired will data retention then be monitored? (i.e. how long will it remain read only) Maybe check the data integrity every 24hours?
I have a 42GB static file on the SSD with a known MD5 sum, so I can check that whenever necessary (it takes a while to read and compute the MD5, though). Once Anvil's app can no longer write to the Samsung, if the data can still be read I will check the MD5 sum periodically. Theoretically, the data retention should be at least a year after rated P/E cycles are reached, so I doubt I will check it every day.

Also, Anvil is working on a new feature for his app that will copy a file to the SSD (every X loops of his app) then read it back and check the MD5 sum (then delete the file again). Maybe Anvil can give an ETA on that feature. I hope it is ready soon, or the Samsung 470 might wear out before the feature is ready!

12. Originally Posted by Ao1
Assuming a sector is 8k/ 8,192 bytes
32,100,000 non aligned pages * 8,192 = 262,963,200,000/ ~0.47TiB/ ~245GiB
I don't think so. The spec seems pretty clear to me that they are talking about 512B sectors / LBAs.

13. Originally Posted by johnw
I'm actually a bit down on Intel and the 320 SSD recently. A bug has shown up in the Intel 320 SSDs. It is somewhat random, but seems to be related to power-cycling, perhaps unsafe power cycles, perhaps sleep or hibernation. As far as I can tell, on any given power cycle the bug is unlikely to appear (at least I haven't had it happen to me yet), but given enough power cycles (and perhaps some random unknown factors), the bug seems more likely to appear. The bug is that the SSD becomes mostly unresponsive to most ATA commands, and shows as having 8MB (not GB) capacity. It is called the "8MB bug".

It seems people have reported this to Intel in May, perhaps earlier. So Intel knows about it. But they haven't issued any statements or warnings about it, and have not recalled the drives nor have they issued updated firmware. Rumor is that a fix is forthcoming in about a month, but no official word even on that. So I used to think a great deal of Intel on reliability and customer support, but my opinion of them has gone down quite a bit after this. If Intel issues a fix soon, they will partially redeem themselves, but not completely, since I do not like the way they have handled the situation at all.

http://communities.intel.com/thread/22227?tstart=0
http://www.pcreview.co.uk/forums/do-...-t4035508.html
Doing a quick search, there seems to only be a handful of users with this issue and pcreview got their SSD to this state by power cycling it for 2-3 hours straight, which no user would ever do. This is a completely insignificant problem.

14. Originally Posted by One_Hertz
Doing a quick search, there seems to only be a handful of users with this issue and pcreview got their SSD to this state by power cycling it for 2-3 hours straight, which no user would ever do. This is a completely insignificant problem.
That is not at all clear. It could be that the probability of the bug occurring is constant for each power cycle. So every time you power cycle the SSD, you may be risking the bug. Certainly there are people posting about the bug in the thread I linked who only power cycled a few times.

We also don't know what the return rates are for the 320s. Maybe in a few months we will see how prevalent this bug is. In the meantime, I do not like the way Intel has handled it. That I know for certain.

15. Originally Posted by johnw
...
Or about 1 in 1342 bytes written is not 4K aligned. I wonder where that ratio comes from. Is that the ratio of random bytes written to total bytes written by Anvil's app?
The random writes are always aligned so if there are any they would have to be caused by sequential writes.
Wrt writing, the files should always be aligned but there can be partial writes, one doesn't write 4KB just because the file is say 12bytes.
The 12byte file will still take a full cluster which normally is 4KB, in the end it is handled by the file system.

I'm working on that MD5 routine, should be ready within the next few days. (maybe tomorrow)

--

131.79TB Host writes
MWI 28

Still at 6 reallocated sectors.

I've had a long weekend , meanwhile it's been working through the TB's, MB/s is down to 32.8MB/s on avg for ~44hours. (~4.94TiB)
Will let it run for another 12 hours just to see how the avg changes.

16. Power cycle for three hours?

They are lucky they didn't kill some of the other hardware or cause a permanent Windows crash.
How many blue screens did they get in that 3 hours and have to reimage Windows.

If they were simulating Hot swapping that is say 30 times a minute x 60 min. x 3 hours = 5400 hot swaps.

Way beyond abusive to me either way.

17. 81 hours, 23,0089 TiB, Wear Leveling Count and Percentage of the rated lifetime used has gone from 89 to 87.
Avg speed for all 81 hours is roughly 82,7 MiB

18. Originally Posted by One_Hertz
Doing a quick search, there seems to only be a handful of users with this issue and pcreview got their SSD to this state by power cycling it for 2-3 hours straight, which no user would ever do. This is a completely insignificant problem.
The 8MB BAD CONTEXT bug is rare, I've actually been bitten by that on a G2, the issue can be googled.
(some were able to just secure erase the drive but mine had to be sent back, it was in this state when it arrived)

Anyways, Why would one wan't to power cycle for hours?
Wonder what would have happened to other SSDs if they were treated like this.

19. Originally Posted by Hopalong X
Power cycle for three hours?

They are lucky they didn't kill some of the other hardware or cause a permanent Windows crash.
How many blue screens did they get in that 3 hours and have to reimage Windows.

If they were simulating Hot swapping that is say 30 times a minute x 60 min. x 3 hours = 5400 hot swaps.

Way beyond abusive to me either way.
There is nothing abnormal about it. I see a perfect parallel between this thread and the power cycle issue reported above. In both cases, we are trying to induce failure quicker than the normal use of the drive will do.

I hope Intel does write endurance testing and continuous power recycling test in a lab 24x7. Both are needed to claim reliability and life expectancy. With super capacitor added in 320, if Intel didn't do this power recycling test during QA in house, they made a huge mistake!

One more thing: Intel is lucky that it only takes 2-3 hours to reproduce the power issue. Intermittent issues are bane of the software world! Hard to reproduce and very difficult to fix! Any developer will tell you how frustrated they feel with intermittent issues!

20. Originally Posted by Hopalong X
Power cycle for three hours?

They are lucky they didn't kill some of the other hardware or cause a permanent Windows crash.
How many blue screens did they get in that 3 hours and have to reimage Windows.

If they were simulating Hot swapping that is say 30 times a minute x 60 min. x 3 hours = 5400 hot swaps.

Way beyond abusive to me either way.
No, just thorough testing. If the proability of the bug occurring on any given power cycle is, say, 1 in 1000 (and constant), then there is about a 36.8% chance that you could power-cycle 1000 times and not see the bug. 13.5% for 2000. 0.67% for 5000. So, in order to test for that possibility, you'd want to power cycle many times. 5000 times is not unreasonable to test for a 1 in 1000 chance.

And 1 in 1000 would result in significant failures. If 10,000 units were sold in a month, and each unit was power cycled 10 times a month, then you would expect about 100 failures, or 1%, in that month.

Of course, all of these numbers are made up. But I think they are plausible. The problem is that Intel is not saying anything, so we cannot know what the real numbers might be.

21. Originally Posted by devsk
There is nothing abnormal about it. I see a perfect parallel between this thread and the power cycle issue reported above. In both cases, we are trying to induce failure quicker than the normal use of the drive will do.
Finally someone who understands simple testing and failure analysis!

22. Originally Posted by Anvil
Wrt writing, the files should always be aligned but there can be partial writes, one doesn't write 4KB just because the file is say 12bytes.
The 12byte file will still take a full cluster which normally is 4KB, in the end it is handled by the file system.
Good point. Do you know what NTFS does if a program requests a write of, say, 1KiB? We know the cluster it is stored in will be 4KiB, but does NTFS actually pad the 1KiB with zeros so it can write 8 LBAs? Or does it just write the two LBAs that are required, and ignore the other 6 LBAs in the cluster?

If NTFS does the latter, I think the Micron firmware would record that as a non-aligned 4K write, even though it was aligned, since it was less than 4KiB in length.

Can you estimate what fraction of your app's random writes would be 7 LBAs (3584 Bytes) or less?

23. The random writes are always 4KB in size and always aligned.

There should be a lot of sequential files less than 4KB in size though, almost impossible to estimate but 50% of the files are 128KB or less in size.
The size of those files is random, so, if it was distributed evenly then 3 in 128 files would be the answer.

edit:
Keep in mind that 50% are totally random in size, none of those can be less than 3KB in size.

--

As for the BAD_CONTEXT issue, Intel specifies 250 insertions of SATA/Power cable, same number as the G2. Link (2.6 reliability)

24. Originally Posted by Anvil
As for the BAD_CONTEXT issue, Intel specifies 250 insertions of SATA/Power cable, same number as the G2. Link (2.6 reliability)
That does not really matter if the issue can be triggered randomly by a power cycle when a computer power is cut or the computer goes into sleep or hibernation. An SSD in a laptop could be power cycled like that several times a day in normal usage.

25. The spec state :
Power On/Off Cycles 50,000 (suspend/ hibernate/ system shutdown)
Insertion Cycles 250 (insertion/removal cycles)

+ Reply to Thread

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts