SSD Write Endurance 25nm Vs 34nm

[Anvil]

WTF, since when has Crucial used SF?

I expect he meant Corsair, not Crucial

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.
...
Anvil, is there anyway to extrapolate more detailed time information from the smart data? Like power on minutes and seconds in addition to hours?

Using it as a secondary drive is much less hassle, just make sure that you have quick/easy access to the drive for physical disconnect, otherwise there is no way but to reboot.

Yes, there is a way to read minutes and seconds, the OCZ Toolbox or smartmontools or maybe both.

[Christopher]

To be fair to SF, I have no idea why this is happening and could have more to do with endurance testing. I've made a few adjustments and hopefully this will stop the crash behavior.

I may pick up another 2281 to use as a normal drive to see what happens -- the 2281 may be uniquely unsuitable for endurance testing in this fashion.

[Christopher]

I decided to try uninstalling the Intel RST drivers... Maybe something will happen (or not). If anything it seems to be running a little faster, but time will tell. At the Mushkin forums it was suggested that disabling trim might stop the behavior, but that's a huge performance penalty... The drive just can't keep up and I lose about 16MBs, so that's a no go.

[bluestang]

M225->Vertex Turbo 64GB Update:

381.21 TiB (419.15 TB) total
1068.49 hours
8046 Raw Wear
117.69 MB/s avg for the last 16.69 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) at 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)

[devsk]

M225->Vertex Turbo 64GB Update:

381.21 TiB (419.15 TB) total
1068.49 hours
8046 Raw Wear
117.69 MB/s avg for the last 16.69 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) at 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)

This is going where no Vertex had gone before.... Will likely meet Samsung 470 or give it a run for its money.

[bulanula]

To be fair to SF, I have no idea why this is happening and could have more to do with endurance testing. I've made a few adjustments and hopefully this will stop the crash behavior.

I may pick up another 2281 to use as a normal drive to see what happens -- the 2281 may be uniquely unsuitable for endurance testing in this fashion.

Come on, this behaviour ( sandforce sudden death syndrome to be precise ) was present all the way from SF1 to SF2 now. It is not related to any endurance test otherwise the other controllers being tested would have done the same. It is a SF specific issue that they just cannot be bothered to fix. SF is the fastest out there ATM but if you want reliability go Intel. This kind of stuff happens with fast SF2 drives. And they even dared to say all was fixed in SF2. What a joke !

Don't get me wrong, I'm not hating SF. After all, it really is the fastest controller out there and one of the most advanced ( easily gets typical 0.6 WA by compression ). The problem is with the vendors ( like OCZ ) messing the SF reputation and trying to shaft consumers making a quick buck. Somebody big like Intel should buy out SF and drop OCZ out the gate. SF + big company resources like Intel's or Samsung = pure win.

[Vapor]

I decided to try uninstalling the Intel RST drivers... Maybe something will happen (or not). If anything it seems to be running a little faster, but time will tell. At the Mushkin forums it was suggested that disabling trim might stop the behavior, but that's a huge performance penalty... The drive just can't keep up and I lose about 16MBs, so that's a no go.

If uninstalling RST doesn't do it, maybe try it on the 3gbps port?

Disabling TRIM is an interesting idea, but for Endurance testing and also using it as your boot drive, IDK if it's so prudent; WA will go up and speeds will go down (and who knows how far down) and things could get really ugly for your system seat-of-your-pants-speed.

[johnw]

This is going where no Vertex had gone before.... Will likely meet Samsung 470 or give it a run for its money.

I expect all the SSDs to outlast the Samsung 470. The Samsung seems to have WA~5, which is a huge handicap for longevity.

[Christopher]

If uninstalling RST doesn't do it, maybe try it on the 3gbps port?

Disabling TRIM is an interesting idea, but for Endurance testing and also using it as your boot drive, IDK if it's so prudent; WA will go up and speeds will go down (and who knows how far down) and things could get really ugly for your system seat-of-your-pants-speed.

Yeah, after1 loop speeds had dropped dramatically. I shudder to think how bad it could get.
EDIT: I tried it on a Sata II port for a while, and speeds didn't go down but by 2 or 3mbs, but only for a few hours on the second day.

Come on, this behaviour ( sandforce sudden death syndrome to be precise ) was present all the way from SF1 to SF2 now. It is not related to any endurance test otherwise the other controllers being tested would have done the same. It is a SF specific issue that they just cannot be bothered to fix. SF is the fastest out there ATM but if you want reliability go Intel. This kind of stuff happens with fast SF2 drives. And they even dared to say all was fixed in SF2. What a joke !

Don't get me wrong, I'm not hating SF. After all, it really is the fastest controller out there and one of the most advanced ( easily gets typical 0.6 WA by compression ). The problem is with the vendors ( like OCZ ) messing the SF reputation and trying to shaft consumers making a quick buck. Somebody big like Intel should buy out SF and drop OCZ out the gate. SF + big company resources like Intel's or Samsung = pure win.

Well, as fate would have it, I had a first row seat to a BSOD not but an hour ago... but a completely different and repeatable cause.

I use my mouse and keyboard connected to the usb hub on my monitor. Last night I decided that I would turn the monitor off, just on the chance that the system would restart and be left sitting at a bios prompt for hours on end, that it wouldn't burn in my screen. So I turned the monitor back on, and while the system was recognizing the usb devices, I got a hang/freeze followed by a BSOD/spontaneous reboot. Unlike my previous reboots, the drive was booted without a full manual power cycle on reboot.

This sounds more like the SF BSODs I've heard about. I'm about to try to replicate it.

[Computurd]

SF + big company resources like Intel's or Samsung = pure win.

i agree in general, except a slight modification of my own:

SF without DuraWrite) + big company resources Intel's or Samsung = pure win.

I expect all the SSDs to outlast the Samsung 470.

I agree, i feel the intel or the M4 will rule them all though

[Computurd]

sorry for doublepost

This sounds more like the SF BSODs I've heard about. I'm about to try to replicate it.

replication would be fantastic! That is the main thing with the SF bug, it usually isnt replicable. Happens spontaneously. SF has stated that if someone can get a replicable BSOD with their drive that they will pay handsomely for the entire computer it happens on.

I have been thinking of late that it seems SF isnt really being totally forthcoming about the issue...all these seperate teams working on it and no one can find what the root cause is? get real!

Wondering if it were an inherent issue with the conroller, would SF be liable for all this mess (as in, mass recall, huge payments to mfrs?)
and if so...would they disclose it if they knew that it was their fault, and expose themselves to liability lawsuits?

[B.A.T]

m4:
546.0762 TiB
2024 hours
Avg speed 90.89 MiB/s.
AD gone from 42 to 38.
P/E 9565.
MD5 OK.
Still no reallocated sectors



Kingston:
I'm going to use the next 2 hours to SE and change controller.

[Christopher]

There it went again...
Hard lock this time, no blue screen.

EDIT:
On the bright side, I've figured out what ASU write errors 0 and 6 are....

Just as an aside, and I swear this it true... not making this up... when my system hard locked, it killed my 802.11N router through ethernet...

[Christopher]

i agree in general, except a slight modification of my own:

SF without DuraWrite) + big company resources Intel's or Samsung = pure win.



I agree, i feel the intel or the M4 will rule them all though

I'm starting to wish I had the M4...

replication would be fantastic! That is the main thing with the SF bug, it usually isnt replicable. Happens spontaneously. SF has stated that if someone can get a replicable BSOD with their drive that they will pay handsomely for the entire computer it happens on.

I have been thinking of late that it seems SF isnt really being totally forthcoming about the issue...all these seperate teams working on it and no one can find what the root cause is? get real!

Wondering if it were an inherent issue with the conroller, would SF be liable for all this mess (as in, mass recall, huge payments to mfrs?)
and if so...would they disclose it if they knew that it was their fault, and expose themselves to liability lawsuits?

I got one whiff of the horsesh*t getting served up over at the OCZ SF2281 forums, and decided there's something rotten in Denmark. My experiences with OCZ's Indilinx forums were good, but the attitude really shifts once you look at the Vertex3 owners getting miffed at the questionable support practices and general lack of information. Seriously, one moderator (who shall remain nameless because he seems to be a decent guy) made a series of statements that blew my mind... Imagine all of these brand new Vertex 3 owners discovering that the shiny new drive they just shelled out for will cause constant BSoDs and prolonged irritation. Then, the one support outlet, a forum moderator, says that he knows 5 scenarios/configurations that will cause BSODing (implying that it's easy to replicate), and that he has a solution for three of them... but he can't tell you. Other statements, like it's probably all Intel's fault so complain to them, and that SF didn't know this was happening, but OCZ was the first to show them what was wrong weeks ago, and that Corsair sucks and wasn't the first to educate SandForce... all sorts of stuff that comes off really badly to (rightfully) concerned customers. Maybe all these other companies would have similar customer perception problems if they had been SFs high-profile, preferred partner. The new FW releases do seem to really help, and Mushkin's forums don't seem to be rife with SF BSOD problems... so maybe it is fairly limited now. At this point, I don't know enough to say whether a normal usage scenario would result in the same problems. I do know enough to understand that it must really, really suck to have to be the one person getting all of the customer complaints, but that doesn't excuse some of what you'll see if you dig in to the support forums.

I'm thinking there is something fundamentally flawed with the SF2281 and that after a few FW revisions it doesn't rear it's ugly head as often, but they'll never be able to solve it completely without a new processor and new firmware. Not to say that SF is acting in bad faith, but it's clear there's something going on.

[Anvil]

I had a hard lock as well, totally unexpected. (20 min ago)

Write error results are standard windows error codes returned by WriteFile or CreateFile.

[bulanula]

Well, I am very happy I chose to avoid SF right now. There have been fundamental problems with SF drives since the first generation. Just look at Newegg reviews. Even if they are not reliable, the failure rate is much higher than other SSDs. Too bad they have not ironed it out by the SF2.

The OCZ forums used to be my daily entertainment until a couple of weeks back when I realised that SF2 had not fixed these issues and the joke was getting old already. Just look at Newegg and other OCZ forum threads and you realise that SF has fundamental problems that are left unfixed. OCZ issues hundreds of FW updates but it still seems like the issues are present. Credit has to be given to some of the forum staff as they are doing all they can but the management should be fired, methinks. OCZ ( Sandforce is the problem here mainly as the Indilinx drives were quite decent after the inclusion of TRIM and lowering the WA ) SSD : free easter egg inside - random crashes and lockups FTW !

[B.A.T]

Kingston V+100 update:
I've done a SE, copied back all the data and set up ASU just as before the last dropout. I've also put the ssd on the Esata controller (Jmicron JBM36X) to make sure they don't interfere with each other. Here are an AS SSD test on that controller:


Here are the last update from Kingston V+100:


Kingston V+100
70.8428 TiB
? hours
Avg speed 74.28 MiB/s.
AD gone from 129 to ?.
P/E ?.


Only problem with the Jmicron controller is the lack of smart values. The Kingston won't show up in SSDLife Pro or CDI

[Christopher]

I got it to crash twice in ten minutes, but can't get it to happen again.

[Christopher]

I had a hard lock as well, totally unexpected. (20 min ago)

Write error results are standard windows error codes returned by WriteFile or CreateFile.

I mean I figured out what conditions will trigger one or the other. Not really important. I thought it might end up being some kind of diagnostic tool after a crash, but not so much.

[Christopher]

Mushkin Chronos Deluxe 60 Update

05 0
Retired Block Count

B1 19
Wear Range Delta

F1 59206
Host Writes

E9 45616
NAND Writes

E6 100
Life Curve

E7 78
Life Left

Average 122.90MBs.
147 Hours Work Time

12GiB Minimum Free Space, 3 crashes today

SSDlife expects 19 days to 0 MWI



I'm going to make some changes to the configuration tonight. Unfortunately, it might not crash for days after this, or it could crash 3 minutes from now, but if I can get 72hrs of uninterrupted activity I feel like I can declare some small victory.

[Vapor]

Updated charts


Host Writes So Far






Normalized Writes So Far
The SSDs are not all the same size, these charts normalize for available NAND capacity.






Write Days So Far
Not all SSDs write at the same speed, these charts factor out write speeds and look at endurance as a function of time.






Host Writes vs. NAND Writes and Write Amplication
Based on reported or calculated NAND cycles from wear SMART values divided by total writes.

[Christopher]

Vapor,

Thanks for updating the charts... it's good to see actual progress .

Are normalized writes (host writes/available nand) using the amount of flash or usable amounts?
The two SF 2281 drives have about 12.8% spare area, while most others are ~7% (is the SF 1200 60GB is ~7%)? I couldn't find it when I looked back, but I remember seeing the information somewhere.

UPDATE:
I set the Mushkin up as a secondary drive about an hour ago, and it just disconnected... this is irritating.

[Vapor]

Normalized writes are based on user available NAND...so for the Sandforces, that's 40/60/120GB.

[Anvil]

Kingston SSDNow 40GB (X25-V)

350.91TB Host writes
Reallocated sectors : 8
MD5 OK

36.61MiB/s on avg (~15 hours)

--

Corsair Force 3 120GB

01 92/50 (Raw read error rate)
05 2 (Retired Block count)
B1 39 (Wear range delta)
E6 100 (Life curve status)
E7 84 (SSD Life left)
E9 68494 (Raw writes)
F1 91286 (Host writes)

105.53MiB/s on avg (~15 hours)
Uptime 261 hours. (power on hours)

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

Let's see how long it lasts before another disconnect, the one last night was very strange as it left the pc totally unresponsive.

[Anvil]

It's still working

What is interesting is that Wear Range Delta has changed from 39 to 38, first time it has decreased.