SSD Write Endurance 25nm Vs 34nm

[bluestang]

m4 update:
Here is the last screenshot before the avg restarted the rig and I lost contact with it.
538.0406 TiB
1759 hours
Avg speed 91.11 MiB/s.
AD gone from 46 to 42.
P/E 9430.
MD5 OK.
Still no reallocated sectors

Creeping up on 600TB and 10k P/E cycle and still no reallocated sectors...amazing

[Christopher]

Mushkin Chronos Deluxe 60
05 0
Retired Block Count

B1 17
Wear Range Delta

F1 47754
Host Writes

E9 36770
NAND Writes

E6 100
Life Curve

E7 83
Life Left

Average 124.87MBs.
118 Hours Work Time

12GiB Minimum Free Space

SSDlife expects 21 days to 0 MWI

[Christopher]

Creeping up on 600TB and 10k P/E cycle and still no reallocated sectors...amazing

With that new firmware, the M4 is really the best thing going at 64 and 128 capacities, but the fact than not a single a sector has been reallocated is maybe more impressive. I hope the Mushkin keeps up (still holding steady at 0, but it's real early in the game...). But doesn't the Force 3 have the exact same NAND in it? It's already got two reallocations.

EDIT
I called Mushkin to try and order another drive and they told me they're completely sold out and that they won't have any more drives out there for another couple weeks. I guess it isn't just me out here singing their praises. Of course, Mushkin/Patriot/OWC/FutureStorageUK/EdgeTech are using the same American assembly facilities making the same drives, so it might be hard to fill all the demand.

[johnw]

With that new firmware, the M4 is really the best thing going at 64 and 128 capacities, but the fact than not a single a sector has been reallocated is maybe more impressive. I hope the Mushkin keeps up (still holding steady at 0, but it's real early in the game...). But doesn't the Force 3 have the exact same NAND in it? It's already got two reallocations.

My guess is it has to do with burn-in procedures. It is possible to run some tests on the flash after the circuit board of the SSD is assembled, identify marginal blocks, and mark them failed. I'm pretty sure Samsung does something like this on the 470 SSDs, since SMART attribute 178 started at 72 (instead of 99 or 100) and then held steady at 72 until near the end of the SSD's lifetime (when it began rapidly decreasing). I think this indicates that a number of flash blocks equal to about 28% of the reserve count were failed before the SSD was shipped, with the result that all the other flash blocks were tested to be very robust.

Judging from the behavior of the m4, I'd guess that Micron did something similar with a burn-in test.

But maybe some of the other SSD brands do not fail the marginal flash blocks during burn-in. So some other models may have reallocated "sectors" sooner than SSDs that do fail the marginal blocks during burn-in.

[Christopher]

Maybe the Micron *AAA and AAB flash (sync vs async) are just graded and binned in such a way that all of the premium flash is just 50% more awesome. That, or SMART doesn't reflect some reallocations, or initial bad blocks get zero'd out. If it turns out that the M4 really just doesn't have any bad blocks after all these writes, then Crucial deserves some sort of official award -- I know my perception of 25nm flash has certainly changed based on it's performance.

[SynbiosVyse]

Christopher, have you been able to figure out why your system is having BSOD?

Does your drive have the latest firmware? Try to figure out what version number of SandForce's firmware equates to that version of Mushkin's firmware.

[Christopher]

Christopher, have you been able to figure out why your system is having BSOD?

Does your drive have the latest firmware? Try to figure out what version number of SandForce's firmware equates to that version of Mushkin's firmware.

It's 3.20 FW, which should be the latest SandForce standard FW revision.

To be fair, I've not actually "seen" a BSOD. I just walk away for a while, come back, and the system has restarted... but not back to Windows, as the OS can't be found by the BIOS. I'm not sure whether it would actually cause a BSOD or the system would just spontaneously restart. I'm confident that it has nothing do with anything but some kind of massive TRIM induced lock up. Maybe I'll actually be sitting in front of the system the next time it happens, but I've upped the Min GiB free to 12, so we'll see if it makes a difference.

Another thing to consider is that sometimes the drive feels quite warm... so if it feels warm outside, it might be sizzling hot inside. Maybe the controller is overheating?

Based on what I was able to gather from the first time this happened, from looking at the numbers, it seemed that it happened just at the end of the loop. Unfortunately, the ASU running totals don't seem to update during the loops, but only after you quit ASU, so if it hangs you'll lose the totals back to the program launch. If the numbers updated durning the loop it might help to pin down when it occurs.

[Ao1]

Factory shipped defects in NAND are perfectly normal and are not an issue as long as they are within certain parameters. With IMF NAND I believe an invalid block is one that contains one or more bad bits. Out of 4,096 blocks at least 3,936 must be available throughout the endurance life of the product. [Speculation; maybe that is why the MWI appears so conservative] Invalid blocks are identified following worst case condition testing in the factory and are marked 00h, which enables a bad block table to be created so that the controller can avoid using them.

[Christopher]

Factory shipped defects in NAND are perfectly normal and are not an issue as long as they are within certain parameters. With IMF NAND I believe an invalid block is one that contains one or more bad bits. Out of 4,096 blocks at least 3,936 must be available throughout the endurance life of the product. [Speculation; maybe that is why the MWI appears so conservative] Invalid blocks are identified following worst case condition testing in the factory and are marked 00h, which enables a bad block table to be created so that the controller can avoid using them.

I understand that it's normal, which is why I'm wondering whether Intel and Micron (possibly others) either have 1) some process to zero out factory identified bad blocks in SMART data OR 2) really good NAND processes that just generate 100% good blocks (or a process to effectively bin NAND). Only my Indilinx drives have bad blocks now, and that's because they came from the factory like that, and so I have to wonder which scenario it is.

[johnw]

I understand that it's normal, which is why I'm wondering whether Intel and Micron (possibly others) either have 1) some process to zero out factory identified bad blocks in SMART data OR 2) really good NAND processes that just generate 100% good blocks (or a process to effectively bin NAND). Only my Indilinx drives have bad blocks now, and that's because they came from the factory like that, and so I have to wonder which scenario it is.

I'm pretty sure it is (1), as I explained previously (except I don't think Intel does it, at least not the the extent that Samsung and Micron do). Assuming you are talking about the SSD level, and not the bare flash level. As I said in my previous post, I think it is done after the SSD circuit board has been assembled.

I guess Ao1 didn't see my post.

[Christopher]

I'm pretty sure it is (1), as I explained previously (except I don't think Intel does it, at least not the the extent that Samsung and Micron do). Assuming you are talking about the SSD level, and not the bare flash level. As I said in my previous post, I think it is done after the SSD circuit board has been assembled.

I guess Ao1 didn't see my post.

Yes, but the Samsung's factory reallocation was evident in the SMART data. The M4 doesn't have any, so that's still impressive whether factory bad block invalidations are invisible to smart data or not... its still awesome.

[johnw]

Yes, but the Samsung's factory reallocation was evident in the SMART data. The M4 doesn't have any, so that's still impressive whether factory bad block invalidations are invisible to smart data or not... its still awesome.

It is a rather arbitrary choice whether to include factory failed/reallocated blocks in the initial SMART attribute values. Samsung apparently chose to include it. Perhaps Micron chose not to.

I don't think it is necessarily "awesome" compared to the other SSDs. It is likely they have similar quality of flash, but some have just chosen to fail the marginal blocks early, and others have chosen to let the marginal blocks be used until they fail, which they tend to do earlier than the other blocks. Either way, the longevity of the SSD is primarily determined by the longevity of the vast majority of the flash blocks, not by a small number of marginal blocks that may or may not be counted as reallocated sectors during the early part of the SSD's lifetime.

[Vapor]

Micron does have it as a SMART value. "Factory Bad Block Count" is present in the C300 and m4. It's a seemingly static number.

[johnw]

Micron does have it as a SMART value. "Factory Bad Block Count" is present in the C300 and m4. It's a seemingly static number.

Aha! I see it, attribute 189. Thanks for pointing that out!

[Christopher]

Micron does have it as a SMART value. "Factory Bad Block Count" is present in the C300 and m4. It's a seemingly static number.

Cool.

I was looking for some CDI posts for the Microns. I gave away my M4 to a family member, so I don't have one to look at anymore.

So how many factory bad blocks did the Microns have? I don't remember seeing the full smart info, but I'm going to look back and see if it was posted.


Just for the record, is it irrelevant that a drive hasn't reallocated any flash after 1/2 a PB?
I don't think so, but I guess it's a matter of opinion. I just take that to mean that whatever flash wasn't factory flagged bad is really consistent.

[johnw]

I just take that to mean that whatever flash wasn't factory flagged bad is really consistent.

Yes, so do I. The problem comes in when you say that the m4 is awesome because it has no reallocated sectors, while some other SSD is not so good because it does have reallocated sectors. That is a conclusion drawn from insufficient information. Most likely, the m4 had all of the marginal blocks failed at the factory, while the other SSD may not have gone through as stringent a test for bad blocks at the factory (or any test at all). Without knowing that, you are comparing apples and oranges.

[Christopher]

Yes, so do I. The problem comes in when you say that the m4 is awesome because it has no reallocated sectors, while some other SSD is not so good because it does have reallocated sectors. That is a conclusion drawn from insufficient information. Most likely, the m4 had all of the marginal blocks failed at the factory, while the other SSD may not have gone through as stringent a test for bad blocks at the factory (or any test at all). Without knowing that, you are comparing apples and oranges.

I wasn't saying that the M4 is better because it has no reallocations, just that it has no reallocations and Micron rates the nand at 3000PEs (and I think that's pretty interesting, if not -- dare I say it -- awesome). You'd assume that some of the flash would die after a few thousand PEs and some would die after a few hundred, but that on balance most flash would be pretty resilient. I don't think a drive is inferior because it has some reallocated blocks after many, many GB worth of writes. That would be silly - that's what it's supposed to do. I do think the M4 is impressive just because you would expect it to[have many reallocations], and it doesn't, which in this sample size of one doesn't mean much, but would still tend to indicate that either it's going to last a long time or will start having a rash of reassignments all at once. The controller doesn't know when a block is getting close to failure, so it must be the flash right?


EDIT
I went back to the beginning and found the initial M4 CDI sceen cap. It looks like it had 58 factory bad blocks.

[Computurd]

sounds like the crashing of the drive is a typical SF crash. Your description of the restarts is about on par with everything that i have read on the ongoing SF issues.

[Christopher]

sounds like the crashing of the drive is a typical SF crash. Your description of the restarts is about on par with everything that i have read on the ongoing SF issues.

I poked around the interwebs, but I mostly saw descriptions of hard freezes/BSODing and not spontaneous resets, where the drive shows in the BIOS, but the UEFI can't find the OS (until a full manual power cycle). It just won't happen while I'm sitting in front of it. I feel pretty confident that under my typical desktop and laptop usage, I'd not encounter the issue. I made a post about it in the Mushkin forums, but that's probably not the place to go. Unsurprisingly, no one else there is encountering issues while writing 10+ TB a day

The Mushkin is my sole experience with Sandforce, so I did some looking around while I was waiting on it, and found that most users on the OCZ forums were getting freezes and then BSODs. I'm looking around now -- but I'm thinking I should probably use another drive as the OS drive like Anvil is. Anvil said a few posts back that he was having a similar problem, but his drive is secondary. I'm using the Mushkin as the system drive while pounding it, which is probably just asking for trouble.

[Ao1]

My post was based on an Intel NAND spec sheet. The raw NAND is subject to onerous testing at the factory. If a bad bit is detected the block is marked as bad. When the NAND is assembled into a SSD the controller maps out the bad blocks. It is possible for a SSD vendor to remove the defect value that the factory sets if it detects a bad bit. In addition a read disturb event might flip the value over time, however the defect map should prevent the SSD from using it, so in theory this should not be an issue.

When the SSD is assembled the bad blocks need to be mapped out. Maybe additional NAND testing is carried out, but I suspect only the functionality of the SSD as an assembled unit is checked. The defect list will of course grow over time. The controller picks this up and adds any defects to map.
I’ll check out the Samsumg/ Toshiba spec sheets later, but I believe it will be the same procedure. The ONFI specifications set out some of the above.

[Anvil]

Christopher, have you been able to figure out why your system is having BSOD?

Does your drive have the latest firmware? Try to figure out what version number of SandForce's firmware equates to that version of Mushkin's firmware.

I'm 100% sure that this is the SF bug that leads to BSOD if the drive is a boot drive, if it's not the boot drive then it will not BSOD, it does need to be power cycled though.
The drive is powered off or it goes into a state where it stops counting hours, I noticed that the other day when my drive disconnected. It should have counted 4-5 hours but it stopped accumulation when it disconnected, about 1 hour after restarting the test.

..
Another thing to consider is that sometimes the drive feels quite warm... so if it feels warm outside, it might be sizzling hot inside. Maybe the controller is overheating?

Based on what I was able to gather from the first time this happened, from looking at the numbers, it seemed that it happened just at the end of the loop. Unfortunately, the ASU running totals don't seem to update during the loops, but only after you quit ASU, so if it hangs you'll lose the totals back to the program launch. If the numbers updated durning the loop it might help to pin down when it occurs.

It continues to accumulate writes, it's just that there are separate counters, one detailed and one with the summary.
The summary needs to be updated that's all, I can do that for you or you can wait for an update where you can do it yourself.

...
-- but I'm thinking I should probably use another drive as the OS drive like Anvil is. Anvil said a few posts back that he was having a similar problem, but his drive is secondary. I'm using the Mushkin as the system drive while pounding it, which is probably just asking for trouble.

It's not an issue for other drives but it's very handy keeping the SF2 based drive as a secondary drive, until the issue is resolved that is.

[Anvil]

Kingston SSDNow 40GB (X25-V)

348.03TB Host writes
Reallocated sectors : 8
MD5 OK

32.22MiB/s on avg (~25 hours)

--

Corsair Force 3 120GB

01 90/50 (Raw read error rate)
05 2 (Retired Block count)
B1 36 (Wear range delta)
E6 100 (Life curve status)
E7 86 (SSD Life left)
E9 61910 (Raw writes)
F1 82510 (Host writes)

104.73MiB/s on avg (~18 hours)
Uptime 237 hours. (power on hours)

SSDLife estimates lifetime to be 1 month 17 days. (November 14th)

[Christopher]

Anvil,

Regarding the disconnect, it's basically just like the drive gets turned off -- vaguely like unplugging the power to the drive while it's operating. I'm going to get it set up today as a secondary.

I've been watching it like a hawk since the last crash, hoping to catch it in the act. I'm not sure what else to try aside from dumping the Intel RST drivers.

Anvil, is there anyway to extrapolate more detailed time information from the smart data? Like power on minutes and seconds in addition to hours?

[bulanula]

After the crash early last night, it looks like it crashed again probably somewhere around 4am or 5am. The really annoying thing is, the system crashes and reboots, but the BIOS can't find the OS, so it just sits at a black screen with the error message until I get there to to physically turn it off/on again. After a soft reboot it still can't find the OS, so I have to physically turn the system off.

I was running it with 5 min GiB free space, so maybe it's hanging on the delete section. I was kinda trying to get that to happen, but only while I was sitting in front of the system.

The last time I checked before the overnight crash it had crept up to a little over 124MBs. I'm still really liking this drive. OWC makes a 240GB version of this drive but it uses the 2282 SF controller, and is probably the fastest drive out there at the moment.

Typical SandForce controller behaviour. Just disappears out of the blue. That is why I choose to avoid SF controllers. Why no major vendor took on SF ? Only small rebranders like Corsair, OCZ, Mushkin etc. Because it is too untested etc. At least that is my opinion.

Everybody trying to make a quick buck with untested Sandforce controllers. Only controllers like Intel or Samsung are really tested properly by big companies. SF cannot afford that. With SF, the vendors ( OCZ mostly etc. ) and the customers test the drives so the profit is bigger. You are basically opting in to be guinea pigs with SF.

[bluestang]

Typical SandForce controller behaviour. Just disappears out of the blue. That is why I choose to avoid SF controllers. Why no major vendor took on SF ? Only small rebranders like Corsair, OCZ, Mushkin etc. Because it is too untested etc. At least that is my opinion.

Everybody trying to make a quick buck with untested Sandforce controllers. Only controllers like Intel or Samsung are really tested properly by big companies. SF cannot afford that. With SF, the vendors ( OCZ, Crucial etc. ) and the customers test the drives so the profit is bigger. You are basically opting in to be guinea pigs with SF.

WTF, since when has Crucial used SF?