SSD roundup: Vertex 3 vs M4 vs C300 vs 510 vs 320 vs x25-M vs F120 vs Falcon II

[Ao1]

To be totally honest, I'm 13 weeks into trying to nail down the problem, and I'm no closer to doing so now than I was 13 weeks ago.

So what you report is pure supposition. I appreciate that the extensive amount of people reporting problems with SF2xxx SSD's may not always be due to SF. Conversely if someone reports a problem with another brand SSD that does not mean the SSD is at fault, or that it has the same issues related to SF drives.

I checked Intel's forum and there is not a single report of a 510 with stuttering issues. I looked into the threads on the 320 8MB bug and found that 20 people had reported the problem. Out of the 20 people 5 people reported multiple failures. 4 people report problems after the f/w update. 1 problem was resolved by removing the SSD and then reconnecting it and 1 problem was reported by someone that had experienced the problem before the f/w update.

So 20, people out of however many SSD's that Intel have sold. Out of those 20 people 25% reported more than one failed 320, which is either real bad luck or an indication that something else might be wrong.


sogersortep 4 failures before f/w update
Jtress - failure after f/w update
NoBackUp - 2 failures one before an done after f/w update
Watercool - failure after f/w update (Mac OS)
TheGreenErik - failure after f/w update
Mars79 - problem after updating f/w resolved by removing and then reattaching SSD
simpleas123 - failure before f/w update
ssdfrustration - failure before f/w update
Jay - failure before f/w update
Vit - failure before f/w update
Bach - 2 failures before f/w update
nibs - failure before f/w update (Mac OS)
Martin J - 7 failures before f/w update
Marc - failure before f/w update
Wolf - failure before f/w update
josif - failure before f/w update (Mac OS)
Thomas - failure before f/w update
Yuhki - failure before f/w update
Rich - 2 failures before f/w update
hermit - failure before f/w update

[Computurd]

yes, the Intel bug itself was so small that it was damn near inconsequential imo.

if they have sold 50,000 devices *only* that makes your chance of getting it .0004%!!!!
yes, thats .0004 of ONE PERCENT.

my money says they've sold more than 100,000.

the people with multiple device failures points to other issues. PSU, mobos, inexperience, etc. they might not even be diagnosing the problem correctly.

the 8 MB bug was totally blown out of the water.

[johnw]

No matter how many times you repeat that ridiculous computation, it does not make it any less absurd.

You cannot look at the number of posts to Intel's forum and divide that by the number of 320 SSDs sold. You need to multiply the number of posts about the problem you find by X and by Y, which are unknown:

X : reciprocal of the fraction of SSDs that are known to have the 8MB bug that actually generate a post about it

Y : reciprocal of the fraction of SSDs that have the problem and are recognized to have the 8MB bug

I have no idea how to get the data needed to estimate X and Y, but it would not suprise me at all if X*Y is greater than 1000. Perhaps greater than 10,000.

[Computurd]

i can agree that there is a bit of an unknown there, but of course I will not agree that it is as large as you think. Merely extrapolation. It can go either way.

two part question. the first i know the answer to. This will be a great chance for you to show your mathematical prowess though, so here ya go:

1. lets say that it is 1000 for instance (it isnt), what does that bring the failure rate up to?

2. (fuzzy question here) how do you think this 8mb issue compares to the SF bug? how many orders of magnitude difference between the two values?

there is an acceptable level of failure, within ALL devices. from the zipper on your pants, to the button on your shirt, to the engine in your vehicle. Nothing can be absolutely perfect every single time. We wouldn't be able to afford it if that were the case.
The intel issue falls within the acceptable level of failure imo, even if it were many times more prevalent than it is now, which is not very prevalent at ALL

[johnw]

i can agree that there is a bit of an unknown there,

Being off by a factor that could be larger than 1000 is not "a bit of an unknown" -- that is a huge error. And I did not even mention other problems with your computation, which is that some of the posts report multiple failures, and you are only guessing at the number of 320 SSDs sold. It is just a ridiculous estimate, when you cannot even be confident of being within a factor of 10,000 of the true number.

The best guess I have is that the probability P of a 320 SSD experiencing the 8MB bug is between 1% and 0.01% for each "unsafe" shutdown of the SSD. This guess is based on the observation of the first post I saw about the bug, where the poster reports that he can duplicate it by cycling the power for two or three hours. That assumes between 100 and 10,000 "unsafe" power cycles in two or three hours, and a probability M=2/3 of getting bitten by the 8MB bug before N power cycles. The formula for P is

P = 1 - Exp[ Log[1 - M] / N ]

This can be converted to an annual failure rate by assuming a number U of unsafe shutdowns per year:

AFR = 1 - ( Exp[ Log[1 - M] / N ] ) ^ U

So, if P is betwen 0.01% and 1%, and we consider an SSD that gets an "unsafe" shutdown five days a week (every time it hibernates, say) so that U = 260, then AFR is between 2.5% and 93%, with the most likely value being 23% AFR (corresponding to P=0.1%). This estimate is reasonable for computers that cut the power to the SSD too quickly. For an SSD in a computer without that problem, the AFR would be much lower.

An unsafe shutdown of the SSD means that the SSD does not receive the ATA shutdown command in enough time before the power is cut to the SSD for the SSD to perform its normal shutdown procedure. That can happen if the power to the computer is lost, but it can also happen with some motherboards and OSs without a power loss (for example, it seems some computers may not send the command in enough time or at all before going into hibernation).

One of the bug reports posted to the Intel forums said that they had 7 failures in 3 months out of 600 drives in operation. That comes to an AFR of about 5%.

Since the biggest selling point of Intel 3Gbps SSDs is that the AFR is well under 1%, the 8MB bug basically eliminated the main reason to buy 320 SSDs. But the firmware update from Intel is said to fix the bug. I have not seen any credible reports posted that clearly explain that they updated the firmware, had an unsafe power down of the SSD, and then got hit by the 8MB bug. The complaints I have seen posted complaining that the new firmware does not fix the problem are garbled and ambiguous. If someone has seen a credible report about the bug still occurring with updated firmware, I would like to read it.

I don't know how prevalent the BSOD issues are with Sandforce SSDs. I haven't done much research on the issues (since I avoid Sandforce SSDs), but what little I have read about it leads me to believe that it is dependent on specific hardware and BIOS interactions with the SSDs. That makes the issues both difficult to fix and difficult to determine the prevalence of. If I had to guess, I'd use my old standby technique of looking at below average review percentage (i.e., one- or two-eggs) on newegg.com. That technique is only good as a relative measure of problems, comparing two or more products. It does NOT give an estimate of AFR.

So, for example, the most reviewed Sandforce 22XX SSD is the 120GB Vertex 3 with 197 reviews, 40 of them one-egg and 15 two-eggs. That comes to 27.9% below average reviews. Here is a table of below-average-review-percentage for several SSD models (whichever model of each type that had the most total reviews):

27.9% of 197...OCZ Vertex 3 120GB
 9.2% of 120...Intel 510 120GB
 5.3% of 57....Samsung 470 64GB
 4.3% of 69....Intel 320 120GB
 2.4% of 164...Crucial m4 64GB

Based on that data, I estimate that a purchaser of a 120GB Vertex 3 is about seven times more likely to have trouble than a purchaser of a 120GB Intel 320.

Be sure not to misuse this technique. One should NOT conclude that 28% of the Vertex 3 SSDs have problems. We cannot compute those types of estimates from this data, since we do not know the relative reporting rates for purchasers who do have problems versus those who do not. This technique should only be used to compare two or more products against each other.

[Computurd]

It is just a ridiculous estimate, when you cannot even be confident of being within a factor of 10,000 of the true number.

you cant, either.

This guess is based on the observation of the first post I saw about the bug, where the poster reports that he can duplicate it by cycling the power for two or three hours....

well all of that is based on a guess. that is terrible to hear. seriously though for all of the projections that you make to come out with 23 percent is well, unbelievable! wow, all that speculation and to be that far off is crazy. seeing as there are twenty reported users experiencing this!

That assumes between 100 and 10,000 "unsafe" power cycles in two or three hours

thats a helluva range there to be making estimates with, between 100 and 10,000?

we consider an SSD that gets an "unsafe" shutdown five days a week (every time it hibernates, say)

i havent heard of hibernation being considered an unsafe shutdown. i feel this is 'padding' your speculative numbers.

One of the bug reports posted to the Intel forums said that they had 7 failures in 3 months out of 600 drives in operation. That comes to an AFR of about 5%.

is this the guy who said that he had them idling on a desk 90 percent of the time? i always found that post suspect. why in the world would you have 600 drives setting around idling on desktops for 90 percent of the time? makes no sense. he also never answered anyone asking questions of him. i would have to chalk that one up to BS personally.

I don't know how prevalent the BSOD issues are with Sandforce SSDs

unfortunately it seems to be a very persistent issue. SF has done great things for SSDs with their research and development, and it sucks to see this come off like this. hopefully they find the bugs and fix them.

I'd use my old standby technique of looking at below average review percentage (i.e., one- or two-eggs) on newegg.com.

you scare me when you say things like that John LOL
seriously though i view all 'user' reviews with disdain, for reasons that we both know. (cant gauge the experience/knowledge of users being one of many factors.)
i can see using them as one tool in a toolbox of informed buying decisions, but i totally agree with your disclaimer that it is basically conjecture.

This technique should only be used to compare two or more products against each other.

This technique should *NOT* be used to compare two or more products against each other. for conversations sake i would see the 'value' of newegg comparisons, but other than that i would totally disregard most of it.


here is the thing though that you can put through your mathematical paces, the crux of my argument:

You state that basically the 'best case scenario' (if i interpret it correctly) is five percent, but more likely 23 percent.
So lets reverse engineer your numbers, and by this, calculate how many SSDs would have been sold to attain these numbers.

Use the only actual solid data that we do have, the reported number of failures. take the time the Intels have been available, then figure your failure rates (one at 5 percent, and one at 23 percent) and then lets see how many SSDs you would speculate were sold based upon those numbers. so lets figure how many SSDs were sold by your rough calculations of failure rates

[johnw]

No, virtually everything in that post is incorrect or makes no sense.

I just spent quite a while writing up a detailed analysis with sound reasoning. You would do well to read it carefully and try to understand it. You might learn something. But I do not want to waste my time correcting all of the mistakes and misconceptions and logical problems in your most recent post.

I might be tempted to pretend to know what I was talking about when I did not, if it was important to create an image so that similarly clueless people would send me hardware to review or pay for my admission to trade shows. But I think I would resist the temptation and instead refrain from commenting on things I do not understand until I had taken the time to learn about them.

[Computurd]

No, virtually everything in that post is incorrect or makes no sense.

I just spent quite a while writing up a detailed analysis with sound reasoning. You would do well to read it carefully and try to understand it. You might learn something. But I do not want to waste my time correcting all of the mistakes and misconceptions and logical problems in your most recent post.

I might be tempted to pretend to know what I was talking about when I did not, if it was important to create an image so that similarly clueless people would send me hardware to review or pay for my admission to trade shows. But I think I would resist the temptation and instead refrain from commenting on things I do not understand until I had taken the time to learn about them.

Why John that isn't a very nice thing to say!
The purpose of this exercise was not to give you the carrot. I wanted you to work through your own reasoning and find that it is flawed. Work for the carrot, so that you understand the carrot!

there is no way that you can realistically proclaim that your proposed failure rate is correct. If you work your own math backwards, you will see that it would be a ridiculously low amount of SSDs projected to be sold. if there are only 20 failures, or even a hundred, then your scenario and projected failure rates simply do not work out.
By reverse engineering your own mathematics, you were to see that the failure rate simply wouldn't work. I believe you did realize this, and this is how you choose to respond.

While my version of figuring the failure rates is intentionally simple, yours is intentionality complicated imo, to try to make your math work. It simply doesnt.

Truly, i figured that you would throw in more fuzzy variables (like the hibernation bit) in an attempt to make the math work out.

resorting to personal attacks merely because someone doesn't agree with your point of view, or the manner in which you figure proposed failure rates, is very childlike, much like a child saying "well your a poo-poo head!"
All of your formulas and conjecture in the post are based on guesses. you even say that you are guessing. so how can you get angry when someone questions your guesswork?
Am i, or others, to believe that your guesses are to be held in the highest regard, and that your guesses are better than anyone elses best guess?

I have no interest in taking flamebait John. And this clearly is.
Hell at least next time try to 'thinly disguise' your out and out insults.

EDIT: just for clarification

pay for my admission to trade shows

they arent paying my admission, i have a press pass

[Ao1]

John, whilst I do not believe (or claim) that 20 people posting on Intel's forum dived by the number of units sold = the extent of the problem, I do believe it provides a reasonable perspective on the issue.

I agree that not everyone will report a problem via a forum. In addition the extent of the risk likelihood of the problem developing is unknown in context that the specific conditions to generate the bug are unknown. If the specific conditions were known it would help establish if Intel were negligent in their validation testing, or if it was a sequence of events, or a specific configuration (or both) that could not have been reasonably foreseen.

Whilst not everyone posts a problem there are also people that post BS claims. If you take the example of the guy that reported 7 failures out of 600 drives, either his configuration created the specific conditions to generate the bug or it is a BS post. It could be either, but anyone that deploys 600 drives, which are then subjected to multiple unsafe power loss events is perhaps in the wrong job. I also ignore any problems reported with Mac's due to the way that Apple specifically design their systems to try and exclude customers from upgrading to anything that is not sold via Apple.

What we do know is that Intel could reproduce the problem and they have developed a fix, which is in stark contrast to the ongoing SF issues. That does not mean however that Intel's SSD's cannot fail and demonstrate similar failure mechanisms in the process to either the bug, or what is occurring with SF drives. Failures cannot be eliminated they can only be mitigated.

Let's look at the bigger picture. I'm going to focus on the X25-M, not to avoid the problem that occurred with the 320, but to look at some statistics that are available that might help put things into perspective.

Figures published by Intel for the X25-M
50,000 drives deployed within Intel - annual failure rate = 0.61%.
100,000 drives deployed by ZT Systems - annual failure rate = 0.26%
800,000 drives sold via distribution channels - annual failure rate = 0.4%

Figures published by hardware.fr for the X25-M
Returns to retailers - 0.59%

Let's take the example of 800,000 drives sold via distribution channels with an annual failure rate of 0.4%. That equates to 3,200 failures. Whilst I haven't counted the failures reported for the X25-M on Intel's forum, reports of failure are rare.

So, for the X25-M an annual failure rate of 0.4% over 800,000 drives = 3,200 failures = significantly less than 1,000 posts.
• Let's assume 100,000 sales of the 320 and 1% failure rate = 1,000 failures. Would that = 20 posts?
• Let's assume 50,000 sales of the 320 and 1% failure rate = 500 failures. Would that = 20 posts?
• Let's assume 10,000 sales of the 320 and 1% failure rate = 100 failures. Would that = 20 posts?
• Let's assume 10,000 sales of the 320 and 23% failure rate = 2,300 failures. Would that = 20 posts?

As an aside SF reported in Feb 2011 that they had shipped more than one million of their SF-1500 and SF-1200 SSD processors since they were released into production in 2010, so you could assume that all SF1xx vendors combined have sold 20% more units than the X25-M. This is still only a very rough perspective as units shipped and units in PC's are two different things, but it provides a perspective if you compare forum posts regarding SF1xxx issues compared to X25-M issues.

BTW, Anantech stated they were inclined to believe OCZ's claim that the "SF2xx problems only affected two thirds of a percent of their customers. They calculated that by looking at the total number of tech support enquiries as well as forum posts about the problem and divided that number by the total number of drives sold through to customers."

I'm not sure how they refer to customers. If it means units sold to distribution channels the credibility of the calculation method is further challenged. (Not that it had much in the first place)

EDIT: My frustration is this: When people like Anantech sensationalise a problem they forget that even if you took the bug into account the overall failure rate is going to be less than a HDD. People only see the sensationalist headlines and then get scared to convert to SSD from HDD. Intel/ Crucial/ Samsung/ Toshiba all supply SSD products that are more reliable than HDD, yet due to stupid headlines people think SSD is less reliable. On the other hand Anatech brushes over SF problems that do actually damage the SSD market.

[Computurd]

for clarification purposes lets read these two posts from the user with the "600 SSDs". the spelling mistakes are his own btw, i didn't do that. here is the copy/paste and a link: the poster is MartinJ
http://communities.intel.com/thread/...art=0&tstart=0

At our company, we order a lot of theese drives for our employees - so far, i'd estimate we have around 600 x Intel 320's (80 gb and 160 gb) + 250-300 drives each month going on from now.
To our big dissapointment, we also see this issue with drives reverting to 8 MB.
out of a current total of approximatly 600 drives in business so far, we have had 7 drives dieing by this error. (all within 3 months of time)
We would really like to hear some kind of information/acknowledgement of this issue from an Intel representative, and an estimate timeline of when this could be fixed.
BR
Martin // Teamlead IT Helpdesk

Hi All. To clarify what I wrote earlier. I must say that 7 SSD's within a (so far) grand total of 600 SSD's failing within 3 months of use, is considered quite unreliable. It doesnt mean the failure rate is 1%, since it can happen at any time. I'd consider it a 1% failure rate if the 7 drives were DOA (Dead On Arrival). How will it look in ½ year from now? We might end up with a lot more than 7 dead SSD's in the long run. Our drives died under these circumstances: During reboot Idling on desktop for 3 days doing abolutely nothing, when i came back next morning, drive was dead. Martin // Teamlead IT Helpdesk

I have added the underline here. now, why in the world would you have 600 SSDs idling at the desktop for three days? i think this is actually one isolated incident, with one group of drives. sounds like hardware to me. If there were big mass failures like this going on at many IT companies, there would be more indicators of this.

[Wendy]

for clarification purposes lets read these two posts from the user with the "600 SSDs". the spelling mistakes are his own btw, i didn't do that. here is the copy/paste and a link: the poster is MartinJ
http://communities.intel.com/thread/...art=0&tstart=0

I'm more interested in post #121 of that thread. Just look at the "unsafe power shutdowns" on those drives.
http://communities.intel.com/message/133751#133751

I have added the underline here. now, why in the world would you have 600 SSDs idling at the desktop for three days? i think this is actually one isolated incident, with one group of drives. sounds like hardware to me. If there were big mass failures like this going on at many IT companies, there would be more indicators of this.

Doesn't IT centers leave their PCs running 24/7, and couldn't a long weekend account for 3 days idle time?
What we don't know is the chipsets that these 320 are running on when they have a problem.

FYI: SF2281 usually BSOD when the PC is left at idle, or at low workload.

@Ao1
Yes, it's supposition, and based on circumstantial evidence.

Let's look at it in another way.
There are 3 popular SSD controllers this year.
Sandforce SF2281
Marvell 88SS9174
Intel 320
All of these have had, or are having problems on P55/P67/Z68

Is it believable that all of these controllers are flawed?
If so, then this really has been a very bad year for SSDs.
I don't believe that for a minute, and I believe there is a problem with the Intel P55/P67/Z68 chipset. This wont cover every single problem, as there is bound to be faulty drives as well.

John mentioned the power down command not being sent in good time, or not sent at all. This is one possibility, but there are other factors as well, and that is ACPI power states "partual and slumber". OCZ suspect that this is the problem with the SF2281 based drives, and interestingly Intel have disabled partual and slumber in their latest 510 firmware, and since the 510 doesn't support APM, does this mean that Intel are not allowing any low power states on that SSD, and if so, why?

Crucial just released new firmware for their M4 series, the new firmware improves performance, which is very nice, but what caught my eye with their 009 release is the last 3 in the following list from the change log.

Changes for version 0009 include the following:
• Improved read throughput performance.
• Increase in PCMark Vantage benchmark score, resulting in improved user experience in most operating systems.
• Improved write latency for better performance under heavy write workloads.
• Faster boot up times.
• Improved compatibility with latest chipsets.
• Compensation for SATA speed negotiation issues between some SATA‐II chipsets and the SATA‐III device.
• Improvement for intermittent failures in cold boot up related to some specific host systems.

So while my findings are only based on my own observations, there is mounting evidence to support that something may not be correct in the P55/P67/Z68 chipsets, and this is something that you can all perhaps check for yourselves.

[RealTelstar]

All true wendy, except that SF 2xxx controllers have a lot of issues also with older chipsets.

[Wendy]

All true wendy, except that SF 2xxx controllers have a lot of issues also with older chipsets.

Yes that is true, but most problems are on P67/Z68, which I suppose isn't altogether surprising as SF2281 is quite new, and it is a native SATA 6Gbps device.

[Hopalong X]

I'm using an Intel 320 120GB. Three months no problems.
At least one works properly.

I updated the firmware as a precaution.

P55 Intel chip set. ASUS P7P55D-E PRO with a Intel Core i7-870.

[Computurd]

There very well may be some issues with the chipset and compatibilities, but in the end, the complaints from SF users compared to any other type of SSD seems to be a thousand to one. LOL of course it isnt that high, but there is a huge disparity there. hundred to one or more. the SF are having tons of issues, and there are some emerging reports of significant issues with Revos, as well, blue screening.
seeing as they use the SF, this does not bode well.
If there is in fact some issues with the chipset, this may only be confusing some real underlying issue. because there is a tremendous disparity between the amount of SF and anyone else, maybe there are multiple issues, one clouding the other.
and if the others can fix it so easily, why hasnt SF?

i find the intel power count post interesting as well; but with their bug being addressed, and for all intents and purposes, fixed, i think this isnt the same issue.
The 310 has a cap that is probably the underlying issue there. almost set to hair trigger would be my suspicion. The whole point of that is to flush data in unsafe shutdowns, that is the main selling point. So... if that is their intent, they may just have some tweaking to do with that. I believe the unsafe power count has more to do with that, than any chipset issue.

The big thing here is i think the chipset is a red herring for the SF guys trying to figure this. With so many best and brightest trying to track this down and fix it, it is unnerving that SF is having issues on all chipsets.
I can only imagine their frustration! I truly feel for them, as this has got to be extremely maddening!

But, again, why is everyone else capable of addressing this and fixing it? (if the problem is in fact the chipset?) Intel was able to validate a fix and fix the firmware in less than one week once they acknowledged the bug.

SF has helped make SSDs mainstream, and my only gripe with them is the DuraWrite. Overall they have been a tremendous asset to the SSD community as they are helping to foster widespread adoption more than probably anyone. and my durawrite complaint doesnt effect 95 percent of SF users anyway! It is a mainstream drive, and performs damn well for that application.

I hate to see this as this is hampering the perception of SSDs as 'safe'. On a lot of the more 'vanilla' storage subforums I hang at I am beginning to see an attitude again that I havent seen in years. Average people feel that SSDs are unsafe. Public perception is going backwards. SSDs are at a turning point right now, and unfortunately they seem to be turning the wrong way with these mainstream drives just killing us.
This hurts us all. I want them to fix it more than anyone!