SSD Write Endurance 25nm Vs 34nm

Quote:

---

Originally Posted by Ao1

SF drives cannot sustain performance levels without burning up the NAND, despite the compression advantage, hence the drives are life time throttled. LOL.. you've been swallowing the propoganda that Tony has been feeding over at OCZ fourms haven't you? Hook.. line.. and sinker. Do you actually seriously believe that compression provides absolutley no additional lifespan increases?

Intel drives provide consistent write speeds throughout the life of the product and regardless of xfer size. SF drives can't do this. Then you obviously haven't tried a secure erase to wipe Durwrite's mapping requirement to keep it actively implemented.

Yes you might get short term performance boosts before throttling kicks in, but once it has kicked in you are stuffed. Takes me all of 10 minutes(no bull) to SE/reimage all 6 of my drives and be back to "un-stuffed" full speed states. They should call it "map-life throttle".. NOT.. "life-time throttle" since an SE wipes the map quite easily and therefore eliminates any throttling altogether until the map is fully reformed when all space has been written at least once. This is where capacity is worth it's weight in gold for a Sandforce controlled drive.

---

Another thing to consider is the lack of throttling and ability of the newer SF2281 controllers to lift throttles MUCH more quickly than the first gen 1xxx series controller. If the above assumptions are true than they just killed the lifespan of these drives by cutting back on the throttling on these new controllers. Then it also begs the question of how/why would they do that(adjust throttling) especially considering they just cut PE/c from the original 34nm/5000k to 25nm/3000k on the new drives?

I've said it many times already.. they simply used the "lifetime throttle to promote lifespan" crap for a smokescreen as to hide the weakness/limitation of the original recycling engines performance on the first gen SF controllers. I also said that if SF could have made the drive avoid/limit throttles on the first gens?.. many mfgrs would have jockeyed for sales dominance by making custom firmware adjustments to one-up the other guys(even possibly reducing warranties on specialized EXTREME models to do it). Never happened because that's all the drive could effectively maintain once it was completely dirty and doing things on the fly(read-write-modify). Recycling engine was too small to make it sustainable, is all. New recycling engine is larger and much improved(TRIM marked blocks are also more effectively/immediately used I suspect) which is why throttling is able to be modified nowadays.

So,.. the new one's throttling was adjusted... because?.. it could be. Simple as that.

Have to read through all the advertising and bulls*it to really piece these things together sometimes. Lifetime throttles are just a big smokescreen to lead those away from the limitations of the first gen drives and it surely worked on most people who asked the question. I also HIGHLY doubt that "too many SE's/Durawrite map bypassing" will kill these drives prematurley as well. Not that I beleive smart data on these drives any further than I can throw it.. but mine actually appear to be in better shape than most of the "just use it throttled" users out there. With 5TB written to EACH 1 of my 6 drives?.. they are not even showing any reallocation counts yet. But with more than 100 SE's on each of my drives now.. who knows?.. maybe I'll trash the charge pumps on my drives and eventually be unable to SE anymore. Hardly think it will matter by that point though as I will have upgraded 2 times over by then and they will be overpriced USB storage solutions or sitting in the kids game machine/netbook. Time will tell the true story. :up:

After all that.. I just want to say that I really appreciate these guys "taking one for the team" by doing this write endurance testing. Much appreciated and you can't be thanked enough for doing it. Anxious to see how far beyond rated PE/c we can go here. Even makes me wonder if you guys can sustain the time and willpower to stay on course if they continue on for too long after 0% lifespans are hit. Will the counters just reset again? Again with the.. "screw SMART and only time will tell". lol

If a SF drive is throttled or not depends on the settings the vendor selects. That is equally true for the SF-2281.

According to Mushkin:

"DuraClass management functionality is still active. “Unthrottled” in this context refers to write IOPS bursting up to 90,000+ but being governed down to 20,000 after a few seconds which is typical behavior with standard firmware with SF-2281. The firmware we have on the Chronos and Chronos Deluxe drives will not have that governor activated."

Excluding the burst speed throttling there is also a different type of throttling implementation that brings the drive to its knees if you write "excessively" for a sustained period.

The only way of alleviating that is idle time, which is completely retarded, as it has no relevance to the date on the receipt.

SE will not clear this. That data is held in a secure area of the drive. You can SE your drive once or a hundred times. It won't clear it.

I would suggest that if you are able to restore performance via a SE the drive was most likely in a degraded (not throttled) state.

Quote:

---

Originally Posted by Computurd

Much like Google uses consumer HDD in all of its servers, instead of enterprise SAS drives. At the end of the day, its cheaper per transaction to run the damn consumer drives.

---

Comp have you read this white paper that Google commisioned?

Quote:

---

Originally Posted by Ao1

If a SF drive is throttled or not depends on the settings the vendor selects. That is equally true for the SF-2281.

According to Mushkin:

"DuraClass management functionality is still active. “Unthrottled” in this context refers to write IOPS bursting up to 90,000+ but being governed down to 20,000 after a few seconds which is typical behavior with standard firmware with SF-2281. The firmware we have on the Chronos and Chronos Deluxe drives will not have that governor activated."
the term "unthrottled" in that context has only to do with short burst rates. NOT anything at all to do with sustained incompressible write speeds which is one of the only true ways to really see throttles on Sandforce controlled drives. For example.. you can test a drive with ATTO before and during throttling and the posted speeds will rarely change more than about 5%. Use incompressible data and the picture changes dramatically as the drive cannot leverage it's internal compression algorithms to falsify/fudge the numbers.

For simplicities sake.. there are 3 distinct stages to Sandforce's speeds.

1'st is "unthrottled state"/fresh speed and is maintained until a map of the entire physical space is formed(all available physical space written to at least once).

2'nd is called a "settled state" and will only write incompressible data at about 70% of its original fresh speeds(this is the "lifetime throttle" and will in fact be stopped immediately with secure erasure as the Durawrite process requires an actively mapped state of the entire physical space for it to be implemented. You can idle for days straight and this throttle will never be lifted(hence the term.. "Lifetime Throttle"). Get rid of the map with an SE?.. and Durawrite has no way of knowing that the drive should be throttled without it.

3'rd is called a "hammered state" and is implemented when the drive is written too hard and all fresh blocks have been completely depleted. At this phase of operation the controller will ony maintain about 50% of it's original fresh speeds when writing incompressible data. This is where the idle time comes into play as the controller rebuilds its fresh block reserve and que's the controller to allow the throttle to eventually lift. This is the ONLY state(although there is some grey area in here) that idle "speed recovery"(NOT talking about block recovery) is possible. And trust me here... with a 6 drive array?.. I know when I lose 110MB/s incompressible write speeds with my vid work not to mention that I immediately notice the small lags that stem from the increased latency of this algorithm(especially with heavy multitasking).


Excluding the burst speed throttling there is also a different type of throttling implementation that brings the drive to its knees if you write "excessively" for a sustained period. Yeah.. see above. Is called a "Hammered State".

The only way of alleviating that is idle time, which is completely retarded, as it has no relevance to the date on the receipt. Correct.. idle time can recover speed ONLY back to a top mark "settled state" and the lifetime throttle remains in effect.

SE will not clear this. That data is held in a secure area of the drive. You can SE your drive once or a hundred times. It won't clear it. Completely incorrect. I've purposely hammered my drives by filling them many, many times beyond capacity(once even wrote over 1TB per a single degradation test.. yeah I know.. I've heard it all before) and I know the internal algorithms/throttled stages of these drive better than most and have schooled many "experts" by now.

I would suggest that if you are able to restore performance via a SE the drive was most likely in a degraded (not throttled) state. As mentioned above there are various stages of throttles with these controllers. You can recover form ALL throttles with an SE.

---

Not to toot my own horn here.. BUT.. I actually tested these drives more than many others combined(conservative estimate of 10 Petabytes worth of data written for highly specific degradation/recovery testing)) and there are fully formed current maintenance protocols based on what I and others who did extensive testing found in regards to these internal algorithms. All the info was spread from the stickies/threads at OCZ forums and are now in othe mfgrs forums as well.

I know it sounds :banana::banana::banana::banana:y, condescending and "know-it-all" like(I hate that too but in the end?.. I listen to the one's "in the know" as this stuff is about learning and not about pride or ego), and I don't actually really mean for it to be that way since after all.. I'm sharing here, but you would be pretty hard pressed to tell me anything about the sandforce controllers inner working that I don't already know. Is one of the main reason s that I was chosen to be a beta-tester for them.

groberts101, why has the SF-1200 drive used in this endurance testing reached such a state that after moderate use (proportional to idle time) it returns to just ~7MB/s write speeds? Ao1 has done multiple secure erases and it has not helped at all.

So how do I clear throttling from the V2 I used in his experiment? I have SE's numerous times and its only idling that does anything.

Also I wrote 30TB in one sitting :p:

SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

102,06TB Host writes
MWI 44

Groberts101, have you actually read more than the last few pages of this thread? You seem to be completely unaware of Ao1's testing. And your description of throttled states doesn't sound right at all to me.

As Tony states on the OCZ forums a "fresh" state is mostly irrelevant. You always have to assume garbage collection and possibly TRIM on these drives. It's just part of the process. A direct result of one of the drawbacks of flash NAND. It might make sense to call that a "settled state" since the drive has settled in to where it should stay in the long run. IOW it has to start dealing with garbage collection and TRIM. Your claim that this is the Duraclass "life throttle" seems a bit silly to me. It isn't any kind of throttle. It's just the normal garbage collection process making itself known. What you called a "hammered state" didn't seem to exist in Ao1's testing, although I believe that Tony claimed that there is such a state. It again just sounds to me like inadequate garbage collection needing extra time to catch up. Perhaps this would equate to the TRIM pauses Ao1 noticed. Brief stutters essentially.

Despite what you claim, according to both OCZ and Sandforce there is supposed to be an (optional) genuinely throttled state which exists solely for warranty purposes. If you don't like the term "life throttle" perhaps you could think of it as "warranty throttling" instead. The only reason for this slowing down of writes (to around 6 MB/sec in the case of Ao1's drive) is to make at least some effort to prevent warranty claims for non-consumer uses or 24/7 writing. In Ao1's case it sometimes seemed to slow down reads as well. Did you see that in your testing?

You also claim that secure erase will reset life throttling. I am curious about exactly what data you are basing this on. In Aoi's testing it took about 30 TB of writes before life throttling started to rear its ugly head. Once throttling did appear secure erase had no effect with the tools he was using. What tools did you use for your secure erase and what were your before and after write speeds?

[Note: I find your rather unusual method of trying to quote someone by adding your own red colored text to the quote extremely confusing and difficult to read. I had to check back a couple of times to make sure that Ao1 himself had not actually written what you wrote. There is a quote tag for a reason you know. Even italics would be easier to read than text color changes.]

136.5TB. 29%. Reallocated sectors up to 8.

Quote:

---

Originally Posted by Ao1

SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

---

Would like to see this as well for the sake of transparency !

Dudes, i want to test write endurance on these, but they have *unlimited* writes :) :) but a five year warranty so go figure, i wonder how that works if it stops working? actually it has a five year lifespan of unlimited writes. so you can write to it constantly, non stop for five years and still be covered!
never mind all that rambling, these are freaking awesome :) about to start totally going nuts testing these here shortly...
3.5" EFD (Enterprise Flash Drives)
http://i517.photobucket.com/albums/u...2-13-15857.jpg

Quote:

---

[Note: I find your rather unusual method of trying to quote someone by adding your own red colored text to the quote extremely confusing and difficult to read. I had to check back a couple of times to make sure that Ao1 himself had not actually written what you wrote. There is a quote tag for a reason you know. Even italics would be easier to read than text color changes.]

---

actually i quite like it. and might even steal the method and use it myself :)

@AO1...hey i recall that....seems that we based a good drive temp from that document to be 30-40C , i still set the curve on my fans on my HDD to never allow them to go over 40C because of that document. Even though the conclusion was that it didnt have a huge impact on performance, you can see in figure 4 that the best range for lowest failure is 30-40C. that is still widely held knowledge. google does us a great service releasing data like this!

http://i517.photobucket.com/albums/u...lie1/temps.png

Quote:

---

Originally Posted by Computurd

actually i quite like it. and might even steal the method and use it myself :)

---

I did not even realize he had inserted his reply in that long quote until someone pointed it out.

So feel free to use the technique. I'll probably miss your replies, too!;)

By the way, I'd say the safe range is more like 25-50C from that graph, although the error bars are large over 45C, so it might be better to set the upper limit at 45C, then to make it almost symmetrical, the lower limit would need to be like 30C. So 30-45C.

37-44 actually looks the absolute best to me :) so now i need to reset my curve :)

Can't say I'm too happy about how those comments were inserted. I'm not bothered by what was written, but I am bothered if people think I wrote them. :mad:

Anyway, looks like the MWI does not get to 0.

From the toolbox release note:

" The normalized value declines linearly from 100 to 1 as the average erase cycle count increases from 0 to the maximum rated cycles. Once the normalized value reaches 1, the number does not decrease, although it is likely that significant additional wear can be put on the device. Use the Normalized value for this attribute".

Also for data integrity checking the toolbox can run two types of scan:

7.0 Run Fast Diagnostic Scan
Use this option to perform a quick check on the health of an Intel SSD.
The scan checks 1.5 GB of the SSD for READ errors. The scan then creates 1 GB of random data and then compares it for data integrity. The scan takes approximately three to five minutes to complete and requires a minimum of 5GB of unutilized space to run.


8.0 Run Full Diagnostic Scan
Use this option to perform an overall health evaluation on an Intel SSD.
After checking every logical block address (LBA) for READ errors, the scan uses the free space to write random data and then reads it back to ensure data integrity. This scan can take an hour or more to run, depending on the amount of free space on the drive, and requires a minimum of 5GB of unutilized space to run.

139TB. 28%. Reallocated sectors up to 9. My reallocations are going up quite a lot lately.

104,68TB Host writes
MWI 42

Still at 6 reallocated sectors, been a while since last time it changed.

Quote:

---

Originally Posted by One_Hertz

139TB. 28%. Reallocated sectors up to 9. My reallocations are going up quite a lot lately.

---

I guess the wear leveling is not perfect.

Even if your drive failed right now that would mean over 142,000 GB of writes. I figure I would write no more than 30-40 GB per day to the drive, although I want to figure out a way to do a better estimate of my writes. If I assume 40 then 142,000/40 = 3550 days = 9.7 years which is a long time. And since I'd be buying either a 120 GB or 240 GB drive it should actually last me more like 30 - 60 years, which is nice. I just wish the price/GB would drop. It seems like the 25nm drives haven't dropped in price at all. In fact most of the time they seem to be more expensive than the 34nm version. For instance the 256 GB C300 is actually $10 more than the m4 on Amazon.

I really want to thank you guys for doing this testing. Somehow it has made me more gung ho about SSDs in general. It really does seem like Intel has somehow magically been able to get something like 5000 p/e c. from their 25nm chips, making me a lot less reluctant to get a drive that uses 25nm IMFT. I'm just waiting for the right sale to buy one. Probably either an Intel 510 or a Sandforce drive. Probably an Intel because I hate Sandforce's fascist warranty throttling policies and Intel SSDs will work better on OSes other than Win7 or Linux due to their SSD Optimizer software. That's also an advantage Intel has over those rather nice Crucial drives. Not everyone in the whole world runs either Win7 or Linux with TRIM. The problem is the Intel drives are way overpriced. The Crucial and Sandforce drives are priced much better. So I'll just wait. Maybe the 25nm price will drop when the 20nm IMFT drives are released.

Quote:

---

Originally Posted by gojirasan

I guess the wear leveling is not perfect.

---

Or not all cells are created equal...

Did you mean you will get an Intel 320? The Intel 510 series use 34nm flash.

Also, some of the Intel 320 SSD's are significantly cheaper than the 34nm X25-M. The 160GB X25-M has long been around $400. The 160GB Intel 320 is about $300, and I got one for $280. And the 320 actually has 176GiB of flash on-board, as compared to 160GiB with the X25-M. The 320 uses the extra flash for RAID-4-like XOR parity.

Quote:

---

Originally Posted by Ao1

Can't say I'm too happy about how those comments were inserted. I'm not bothered by what was written, but I am bothered if people think I wrote them

---

sorry... is just a force of habit due to the ease of which it can be done on my end. If you noticed the post above it was worded better as to not mesh so easily into the original post and was obviously a response to each section of the original post. I'll break it down into individual quotes next time so there's no confusion or animosity caused. Will also revist that post of concern to clarify for anyone else reading it in the future.

As for the other questions about my source of info or credibilty on the subject of Sandforce?.. well.. not sure Tony will admit to it or not(he's English you know.. lol) but I do know that all my testing and feedback on the original Sandforce controller(not to mention the new one) has helped to form the basis of overall understanding for these controllers in general on that forum as well as around the web due to the trickle down effect. IMO, that advanced understanding is what earned me the opportunity to beta-test these new SF2281 6G controllers.

Many of the advanced users and one's who lower gaurds and test theories/advice are happy with the info and tweaks that I helped uncover about these drives and most was done simply because of the shroud of secrecy that Sandforce perpetuated(I know/was told they were watching along the way as things were put into the public domain). Tony helped as much as NDA and his personal testing would allow but I seriously pushed hard to get more info(rallied other users into my cause) and testing from my end with posted/quantifiable results was the ONLY way that I could get to the end result. Which ultimately was only the need to understand them to better work around their inherent weaknesses and better implement them into my vid/gfx workstation usage.

Again with the not trying to toot my own horn here.. but many of my "extreme views" have been inplemented into the stickies and are now used as common "extreme usage" protocol to squeek that last bit of performance/stamina out of these controllers. So while I can't take the complete credit for "heavy user implemented OP/unallocated space, logged off idle recovery, and SE/reimages to recover immediate fresh speed"?.. I certainly pushed the envelope and lead the way with MANY TB's worth of test data and result responses over on that forum. Mine aren't generally the little 2 sentence chats either. I speak in great detail and give several iterations to get my points/results/test methodology across. Had to constantly break my posts due to the 5000 word v-bulletin forum limits. lol

So,.. if you guys don't mind me breaking it down and cluttering this thread a bit more than usual?.. I can feed info for those who have actual interest for the facts about these controllers. Most will be more of "what they do" moreso than "why they do" but the end results will be the same. If you want to tear at me and diminish my knowledge to fit into your nice little "this is my Sandforce understanding" bubble?.. I don't have that kind of time and won't be drawn into debates when the guards are up and the mind is closed. Keep the questions broken down and in simpler terms and I'll try my best to tell you what I know so far. If I don't know?.. I'll tell you my opinion or speculate based on others feedback(some of Tony's as well).

Quote:

---

Originally Posted by groberts101

Again with the not trying to toot my own horn here..

---

Think what you could do if you were actually trying! :rolleyes:

Quote:

---

Originally Posted by groberts101

So,.. if you guys don't mind me breaking it down and cluttering this thread a bit more than usual?.. I can feed info for those who have actual interest for the facts about these controllers. Most will be more of "what they do" moreso than "why they do" but the end results will be the same. If you want to tear at me and diminish my knowledge to fit into your nice little "this is my Sandforce understanding" bubble?.. I don't have that kind of time and won't be drawn into debates when the guards are up and the mind is closed. Keep the questions broken down and in simpler terms and I'll try my best to tell you what I know so far. If I don't know?.. I'll tell you my opinion or speculate based on others feedback(some of Tony's as well).

---

Two things:

1) Probably best to start another thread

2) You might try reading what others have written and respond to people. You still have not responded to Ao1's data about how his Sandforce drive was lifetime throttled to 7MB/s sequential write speed, and it stayed throttled despite several secure erases. Clearly, SE does NOT clear a lifetime throttle condition on Ao1's SSD.

Quote:

---

Originally Posted by Ao1

...I have SE's numerous times and its only idling that does anything.
...
SF vendors should come out and make a clear statement on exactly what throttling measures have been applied and what the impact will be.
It should be a clear specification on the product.

---

Okay I qualify here-
Its lifetime/warranty wear leveling,
Can't be cleared by secure erase or even firmware upgrade,
can only be cleared by a base-level manufacturer's firmware load.

Quote:

---

Originally Posted by gojirasan

...
Despite what you claim, according to both OCZ and Sandforce there is supposed to be an (optional) genuinely throttled state which exists solely for warranty purposes. If you don't like the term "life throttle" perhaps you could think of it as "warranty throttling" instead. The only reason for this slowing down of writes (to around 6 MB/sec in the case of Ao1's drive) is to make at least some effort to prevent warranty claims for non-consumer uses or 24/7 writing. In Ao1's case it sometimes seemed to slow down reads as well. Did you see that in your testing?

You also claim that secure erase will reset life throttling. I am curious about exactly what data you are basing this on. In Aoi's testing it took about 30 TB of writes before life throttling started to rear its ugly head. Once throttling did appear secure erase had no effect with the tools he was using. What tools did you use for your secure erase and what were your before and after write speeds?
...

---

Lifetime write throttling should not affect read speeds unless its doing other processes in the background simultaneously (which is likely in this sort of high-load environment).
No type of secure erase will reset life throttling curve. See above response.

Quote:

---

Originally Posted by Computurd

Dudes, i want to test write endurance on these, but they have *unlimited* writes :) :) but a five year warranty so go figure, i wonder how that works if it stops working? actually it has a five year lifespan of unlimited writes. so you can write to it constantly, non stop for five years and still be covered!
never mind all that rambling, these are freaking awesome :) about to start totally going nuts testing these here shortly...
3.5" EFD (Enterprise Flash Drives)
http://i517.photobucket.com/albums/u...2-13-15857.jpg

---

Interesting, where did you get the Pliant drives from?
You work for a company that uses them?
What were you saying about SLC NAND being a dead market? ;)
If only I could say what we're building for the GOOG...

Quote:

---

Originally Posted by gojirasan

...
It seems like the 25nm drives haven't dropped in price at all. In fact most of the time they seem to be more expensive than the 34nm version.
...
It really does seem like Intel has somehow magically been able to get something like 5000 p/e c. from their 25nm chips, making me a lot less reluctant to get a drive that uses 25nm IMFT.

---

NAND shortage in supply (relative to boom in demand)= price drops are stabilizing
The 25nm flash you guys will see is going to be 3k.
The 5k/10k stuff doesn't go into consumer products.

Quote:

---

Originally Posted by Ao1

...
SF drives cannot sustain performance levels without burning up the NAND, despite the compression advantage, hence the drives are life time throttled.

Intel drives provide consistent write speeds throughout the life of the product and regardless of xfer size. SF drives can't do this.
...

---

:rolleyes:
Sandforce does better than Intel in terms of "burning up the NAND", and Intel isn't consistent write speeds throughout the life of the product either.

Quote:

---

Originally Posted by Computurd

i feel it is indicative of their intended path that they are now releasing enterprise SSD "drives" with 25nmMLC and no mention of 25nm slc anywhere.
...
the extrapolation of this point is the comparison of SLC v MLC in the enterprise space. With SLC so cost prohibitive, and MLC gaining rapidly with endurance, it is simply much much smarter to use MLC in the first place, and get it over with. Eat the cost of the reduced endurance, but in the end, you are going to come out way ahead in cost per transaction.
Also, in todays data center, effective tiered caching is going to allow you to further enhance the viability of your MLC drives.
...
but when? and where? no time in the near future.
...

---

Intel is going eMLC for their enterprise class 2.5" because it makes sense for the majority of the market, true- that's who Intel builds their products for!
That certainly doesn't mean SLC is dead/unnecessary/less cost effective in many "enterprise" scenarios..

Please see post #237 & #258. Compressed read speeds are impacted. Non compressed read speeds are not impacted.

Regading Intel drives please see post #482 No slow down that I can see. Also I've never seen more than ~5% change is sequential write xfer speeds, no matter how large the xfer is.

Regarding nand burn out, if compression is so good why is life time throttling required?

The SF-2281 has more throttling options (Compared to the last gen). That can impact burst IO and slow down writes/ reads. There are probably other way the drives are impacted. SF vendors need to come clean and say what options they have selected and give details of the boundaries to keep within to avoid issues.

Quote:

---

nteresting, where did you get the Pliant drives from?
You work for a company that uses them?
What were you saying about SLC NAND being a dead market?
If only I could say what we're building for the GOOG...

---

yeah they are Pliant LS 300S 3.5in 300 GB SLC drives...very cheap so i bought five of them :)
(Just kidding, they cost $34,000 USD for that little pile there, they are on loan for some reviews of them and several raid cards, enclosures, blah blah blah)

Quote:

---

ntel is going eMLC for their enterprise class 2.5" because it makes sense for the majority of the market, true- that's who Intel builds their products for!
That certainly doesn't mean SLC is dead/unnecessary/less cost effective in many "enterprise" scenarios..

---

yes, that is exactly what i am driving at in the first sentence. SLC is a niche market. Yes, it will be out there, but as it falls further and further into the niche market we know what happens, it gets even more and more expensive, thus dying off. it will become increasingly less cost effective as time wears on. that is why Intel abandoning them for SSD "Drives" is met with disdain by many. it heralds the beginning of the end. less mainstream=less investment=less innovation=more expensive
never questioned the performance/reliability of SLC. just hit 440,000 IOPS with five devices a while ago. very impressive.
Is SLC necessary? somewhat right now, as things stand. However, as SLC falls more and more into the niche market MLC will get all of the attention/research/innovation, and will deem SLC unnecessary with future generations/shrinks of nand(that is my speculation of course, but felt by many). think-today eMLC...whats tommorow? eXMLC? lol you get the point.
I do seem to remember though that in the heady fast and furious days of SSD first hitting mainstream how everyone talked about the progress/maturation of MLC would eventually bring SLC and its exorbitant prices out of the equation, and that being a good thing.
now we have almost reached that point and everyone is unhappy. go figure.

Quote:

---

If only I could say what we're building for the GOOG...

---

actually i think i know what it is :)

Quote:

---

Originally Posted by johnw

Think what you could do if you were actually trying! :rolleyes:



Two things:

1) Probably best to start another thread

2) You might try reading what others have written and respond to people. You still have not responded to Ao1's data about how his Sandforce drive was lifetime throttled to 7MB/s sequential write speed, and it stayed throttled despite several secure erases. Clearly, SE does NOT clear a lifetime throttle condition on Ao1's SSD.

---

You have no idea how right you are until you read my posts over at OCZ forums in the mega thread titled "TRIM, OP, and everything else Sandforce". The newer "Sandforce write throttling" sticky also has many to choose from as well. lol Seriously though.. it's pretty tough to just tell someone(especially "jaded experts" like some here) that.. "I just know these things". The main puprose was to add some type of credentials for how I got to where I am at this point with my understanding of Sandfocre. Aside from that, I'm a pretty humble dude and you can take it any way you want which seems to be the downside of any forum posting with huge losses in interpretation and attitude.


1)probably won't happen unless someone PM's me and needs the info. Seems to be just a passing debate and to be perfectly honest?.. I'm fine with guys being wrong and believing what you want to. Seems like too much hassle to "debate" about things that have been proven many, many times over at the OCZ forums on a near daily basis. The info is there. Not being snotty at all and just seems like a waste of time if the minds are closed or the cup is already full. Whatever analogy fits there gets the point across I'm sure.

2)I can certainly do that and will try to shed light on what I'm guessing happened with a few different possibilities there. Seems moot at this point though with the drive out of the running now.

EDIT: Holy friggin' crap! I give up trying to multi-quote bits and pieces of certian posts as I'm just hacking this stuff up trying to get it right. Don't know how you guys do it and don't have the patience to learn something new right now unless someone can lend me a clue or I'll just stay simple and try and make my red responses to be clearly just my own responses to each portion of the original post. If that's not good enough then I'll just go back to spectating again. This back and forth stuff is half the reason I didn't respond when the drive dropped out of the lineup in the first place.

PS. @Ao1.. PM me if you want me to clarify some things a bit better and give some idea's as to what most likely happened there with your drive.

since you don't believe my input here I'll leave you with these quotes from Tony himself.

Quote:

---

During the time there is no GC map...EG all the nand is reset and free to write to duraclass has no real impact on Nand life...its just writes

---

Quote:

---

When you SE the controller writes without Duraclass, it writes faster BUT it also writes indiscriminately...it does not look at what blocks have high erase count and move to ones that have a low count... it just writes to them.

---

Quote:

---

you can see the clean speed (NO GC MAP) which is what you get now with a clean new drive or after SE and then the functional 1 month in speed which is what you all see now

---

Quote:

---

idle time will restore the drive to day to day speed, SE will restore unmapped speed but you will see a transition from that state to day to day. Plus SE to often and you actually start wearing out the drive.

---

So, in the end here?.. Sandforce Lifetime throttle = "settled in state". An SE does in fact reset the drive to fresh out of the box speed. Anyone who find's otherwise has not properly sent the ATA secure erase command for the drive to initiate it at the firmware level?.. or there is an issue with the drive and the firmware is corrupted or an RMA is required. My guess is that Ao1 didn't use the proper tool to send the command to the firmware for the ATA SE to be initiated.

i would be interested to hear what you think can be done to bring his drive back into the testing. maybe he just has a bad drive, that has crossed my mind a few times.

I personally can vouch for Groberts101. i have seen him over @OCZ for, it seems, years, and he is always right in the thick of the testing, technical aspects, and chasing of new info/ideas. We cross paths frequently on several forums, and i consider him a guru. believe me, its a short list of people that i would consider storage gurus. Luckily, most of them are here, and im glad to see groberts here, so lets not beat up the new guy too bad, eh? we will be glad to have him aboard. One doesnt have to know everything to be a guru, they just have to strive to know and learn everything and truly have a passion for this type of stuff, and invest far too much personal time testing and chasing that...well ya know;...stuff. we definitely have a good share of these guys here, thats for sure. so one more, its a party:party:

this truly is a glorious thread, i hope this endurance testing goes on forever :)

I don't understand all this vouching for people stuff. Is this some kind of pissing contest to see who has the most impressive credentials or something? Unless he literally has inside information as in he is a Sandforce employee or at least an OEM customer of Sandforce I don't see how it's relevant. Argument by Authority is a logical fallacy. After all we're not trying to start a religion here. Data is data. Facts are facts. If you've got 'em then I don't care if you are a janitor or Albert Einstein. Just show me the data.

groberts101, if you can't be bothered to post your data that's fine. Ao1's data seems perfectly valid to me and it sounds to me like you have some mistaken ideas about Sandforce controllers. Frankly I don't trust threads on the OCZ forum very much because the moderators there are often pretty busy deleting and trimming information they don't like or don't want to be public. They even tried to hide the whole life/warranty throttling issue at first. I do respect the fact that they eventually admitted to the throttling, but they were quite evasive about it for a while, until Tony decided to spill the beans.

As far as quoting with BBcode, it's kind of like html tags except you use brackets. So you can multi-quote manually by just copying and pasting the text you want. I'll substitute parenthesis for brackets. It's like this: (QUOTE="groberts101")stuff groberts101 wrote(/QUOTE). If you have javascript active you can use a button above the text box to put the quote tags around the text you copied. There may be an easier way, but that's more or less how I do it when I want to reply to just part of someone's post.

Really close now between the Intel 320 and the old Intel X25-V. Well, at least according to the MWI that is !

Quote:

---

Originally Posted by gojirasan

groberts101, if you can't be bothered to post your data that's fine. Ao1's data seems perfectly valid to me and it sounds to me like you have some mistaken ideas about Sandforce controllers.

---

I was just about to post saying something like that, but you beat me to it.

Ao1 described how he did the secure erase, but it seems groberts101 cannot be bothered to read it. He seems too busy listing his credentials and rambling on than in actually reading what other people have done in their own tests. Anway, Ao1's test sounded like a valid secure erase to me.

So the question remains, if groberts101 is so knowledgeable about SF SSDs, why did Ao1's secure erase not reset the lifetime throttling?

Quote:

---

Originally Posted by Computurd

I personally can vouch for Groberts101.

---

groberts101's claim that Ao1 does not know how to secure erase his SSD kind of reminds me of the guy who claimed that you did not know how to properly plug-in a modular PSU cable.

i will say this: that you SE the drive to regain the unthrottled performance seems to be 'common knowledge' @ OCZ forums. whether that is true or not remains to be seen. I do think that A01 might try an alternative method of SE the drive though, just to be sure. preferably a method that delivers a completion dialogue, not sure if he did receive that or not. I do know that the independent version of the utility works very well. I believe that he used the toolbox version.

As to vouching for him, what i am saying is this: he is what he says he is. He does Beta Test for OCZ> i know this for a fact. they did not give him the new drives to beta test because he was a dude who fell off the turnip truck. his work with the previous gen of SF was sure to be a basis of this. very very very few people are given that opportunity over there, probably less than one percent. so * I imagine* they sure thought enough of his knowledge/qualifications to justify that. and his knowledge that got him there was the work with the very drive/controller we are discussing.
I dont see many people here who have been allowed to beta test pre-release SSDs...especially the newer generation of the same :banana::banana::banana::banana:ing device we are talking about....so you would think he would have some idea of what he is talking about.

Quote:

---

why did Ao1's secure erase not reset the lifetime throttling?

---

dunno. could be a bad drive. :banana::banana::banana::banana: if i know LOL

im no fan of SF, i just have never thought much of compression, too much smoke and mirrors for my taste. so i do acquiesce to those who know more than me on that.
doesnt mean they arent good drives, but this whole floating point of performance and some of the problems they've had, just not my cup of tea.

Quote:

---

Originally Posted by Computurd

As to vouching for him, what i am saying is this: he is what he says he is. He does Beta Test for OCZ> i know this for a fact. they did not give him the new drives to beta test because he was a dude who fell off the turnip truck. his work with the previous gen of SF was sure to be a basis of this. very very very few people are given that opportunity over there, probably less than one percent. so * I imagine* they sure thought enough of his knowledge/qualifications to justify that. and his knowledge that got him there was the work with the very drive/controller we are discussing.
I dont see many people here who have been allowed to beta test pre-release SSDs...especially the newer generation of the same :banana::banana::banana::banana:ing device we are talking about....so you would think he would have some idea of what he is talking about.

---

What somebody does off of XS, while sometimes interesting and maybe even important, does not excuse behavior on XS. I hope groberts101 will stop disrupting this thread with discussion about himself and will hopefully be able to contribute with information or direction as to what is going on with Ao1's SF-1200 drive.

Quote:

---

Originally Posted by Computurd

i will say this: that you SE the drive to regain the unthrottled performance seems to be 'common knowledge' @ OCZ forums.

---

More like 'common confusion'. In this very thread, there is one OCZ employee claiming that a SE does reset lifetime throttling, and another OCZ employee claiming that OCZ has never said that SE will reset lifetime throttling. Does anybody really know what time it is?

Quote:

---

Originally Posted by Vapor

What somebody does off of XS, while sometimes interesting and maybe even important, does not excuse behavior on XS. I hope groberts101 will stop disrupting this thread with discussion about himself and will hopefully be able to contribute with information or direction as to what is going on with Ao1's SF-1200 drive.

---

well yes, that would be nice. im not saying anything about behavior or what-not. thats none of my buisness :)
did seem like he was trying to provide some info in post #504 (some will miss it since its in the quote box) and then got sidetracked.

Quote:

---

Originally Posted by johnw

More like 'common confusion'. In this very thread, there is one OCZ employee claiming that a SE does reset lifetime throttling, and another OCZ employee claiming that OCZ has never said that SE will reset lifetime throttling. Does anybody really know what time it is?

---

yea thats why i put 'common knowledge' in those quotation thingys.

EDIT: now ive learned the multi-quote. that helps. never used it before myself just copy/paste. never again. there is a YouTube video on it

Quote:

---

Originally Posted by Vapor

What somebody does off of XS, while sometimes interesting and maybe even important, does not excuse behavior on XS. I hope groberts101 will stop disrupting this thread with discussion about himself and will hopefully be able to contribute with information or direction as to what is going on with Ao1's SF-1200 drive.

---

Thank you Vapor!

The whole point of this thread was to remove speculation and fud. Instead it now seems to have reverted to even more fud, when the facts clearly say something different.

A V2 40GB drive can be picked up for pocket change. If anyone doubts my observations why not pick one up? Ask Anvil for the app and then run it for 7 days. Then we can have a discussion.

If anyone wants to tell me how to clear the throttling on my V2 please post details for the benefit of everyone and I will try whatever is suggested.

@groberts101

First you accuse be of believing fud from Tony, next you quote fud from Tony as being the truth. :rolleyes: I am not making observation on what I read. I am making obsevations on what I found out for myself by testing.

What I don't get is this; The DuraClass feature is working EXACTLY as intended, but you do not want to believe it.

Why not join us and do some testing on a V3?

Run some large xfers and monitor I/O performance during the xfers.

Next ask Anvil if you can use his app and see how long it takes to get to a throttled state that cannot be recovered.

Next come and put facts (not speculation) on the table, as I have tried to do in this thread.

EDIT: If you are beta testing for OCZ maybe the throttling options were not implimented? Do you have a V3 that you purchased? If so it would be great if you could use a retail V3 to contribute to this thread.

Quote:

---

Originally Posted by Computurd

I do think that A01 might try an alternative method of SE the drive though, just to be sure.

---

Comp, I tried a number of SE's using the OCZ Toolbox. I even tried a hdderease in a different PC. After every SE the partition was gone. What elese can I try?

What zads states in post #523 makes perfect sense:

Its lifetime/warranty wear levelling,
Can't be cleared by secure erase or even firmware upgrade, can only be cleared by a base-level manufacturer's firmware load.

Praz implied that in this thread.

Has anyone on the OCZ forum tried to write for 7 days non stop?

well the only suggestion i would have is to try the independent tool. but i do feel that you used the tool correctly, and probably 99 percent chance that it worked correctly. but there is always that one percent chance. not questioning your abilities/knowledge by any means at all!
its just that i have heard people say that they needed to use the actual SE separately to get a good result. but that is probably a corner case on old boards...dunno dont pay much attention to it.

I dont think anyone has done any extended testing on these drives at OCZ, but im not sure. I dont hang out there anymore, i dont even lurk. a personal disagreement led to me leaving those forums pretty much. every week i will check PMs there though, as there is still interest in the 9260 thread over there.

might also be a bad drive. man i would love to see another test, it just seems unconscionable that they would throttle to that extent. amazing.

Zads seems to be very knowledgeable, and claims to be a SF vendor according to this: (post 523)

Quote:

---

Okay I qualify here-
Its lifetime/warranty wear leveling,
Can't be cleared by secure erase or even firmware upgrade,
can only be cleared by a base-level manufacturer's firmware load.

---

so who knows, surely not I.
As i tried to say up above, i know Groberts and hes a stand up guy, but that doesn't necessarily mean that his interpretation of his and others results are correct.
i do consider him to be very knowledgeable though.

i know i am definitely not standing up and claiming a SE will restore anything with duraclass. i have absolutely no idea :)

and i agree with the amount of differing opinions it is really muddy water there.

How do I go about doing a SE with the independent tool? I am willing to try it. I will then restart the endurance test to see what happens.

It would be great if someone else could get a V2 40GB to see if what I found can be duplicated. Then it's not just me saying it.

I can assure everyone on this thread that what I reported is 100% accurate to what I have observed. I have no interest in fabricating what I observed. Why would I report fud and end up looking stupid if (when) I got caught out?

If I observe something that I can't explain I state clearly that I am speculating on anything I put forward as a possible reason.

good god man, no one is questioning your integrity!
i dont think it is publicly available anymore. let me email it to you
other than your maddening assertions about SSD/HDD effect on gaming, ive never questioned you :)

YHPM

Hmmm....

First, Ao1 has tried SEing the drive both using OCZ Toolbox and HDDerase and so there is pretty much 0 possibility that it's not being done the right way.
(as he was able to upgrade the firmware we can pretty much say that the Toolbox was working)

I'm actually surprised that it lasted for a whole week with continuous writing, I do not believe anyone has made such a test using a SF controller, well, not publicly :)

I'm sure groberts can be an asset on the SF drives, I'm pretty sure that this is uncharted territory though and so we need more SF drives in the test.
All other aspects about the SF controller is beyond this test and has to go into a new/separate thread.
I'll make such a thread if no one else will, however the SF controller makes for a lot of speculations and apparently none of the info that we are looking for will be made public and so whatever we do, it will be speculations and by our own trial and error.
SF should demystify some of the stuff we are trying to figure out, it's our drives we shouldn't need to be asking questions like these.

Anvil, I'm waiting for the tool from Comp. When I get it I will restart the endurance test, but I will start a new thread.

@groberts101

Welcome to the forum. I hope you will join me in the new thread. It would be great if you could do some testing on a retail V3, or duplicate what I did on a V2 to see if the same thing occurs. :up:

If I could start over I would have checked I/O performance for various sized xfers to quantify the I/O burst throttling effect.

It would be interesting to establish if MAX IO means this particular method of throttling is disabled when compared to a standard version of the V3.

After that is established it would then be interesting to see how long/ how much has to be written on a V3 before throttling kicks in. Does capacity result in different outcomes? i.e. are smaller sized drives throttled more than larger capacity equivalents?

Quote:

---

Originally Posted by Ao1

Anvil, I'm waiting for the tool from Comp. When I get it I will restart the endurance test, but I will start a new thread.

@groberts101

Welcome to the forum. I hope you will join me in the new thread. It would be great if you could do some testing on a retail V3, or duplicate what I did on a V2 to see if the same thing occurs. :up:

If I could start over I would have checked I/O performance for various sized xfers to quantify the I/O burst throttling effect.

It would be interesting to establish if MAX IO means this particular method of throttling is disabled when compared to a standard version of the V3.

After that is established it would then be interesting to see how long/ how much has to be written on a V3 before throttling kicks in. Does capacity result in different outcomes? i.e. are smaller sized drives throttled more than larger capacity equivalents?

---

Indeed the only reason I did not go for a Vertex 3 is the lack of transparency.

Statements like "There is less throttling on the V3 compared to the V2" are just not good enough when we saw a V2 drive hitting a maximum of 7 MB/s in this thread !

We need facts and figures not just opinions without proof. Eg kind of reminds me of statements like "bulldozer is competitive with 2600k" etc. how competitive and how much less throttling etc.

142TB. 27%. Reallocated sectors up to 11 from 9!

107,36TB Host writes
MWI 41

Still no changes for reallocated sectors.

So, 107TB, that is more than 3x the warranted 35TB.

Do we actually have a p/e spec on the Kingston SSDNow or the Intel X25-V? I know that 5000 p/e cycles is assumed for 34nm, but that is just a general industry assumption. I am wondering what Intel has to say on the matter. That warranty is truly pathetic. Is that the Kingston warranty, the Intel version, or both? Were they really expecting no more than 900 p/e cycles from their 34nm drive? That's a lot of write amplification. IIRC, Intel publishes the same amount of lifetime writes for all of the drive sizes in a model line which of course makes no sense at all.

"Up to 20GB Host writes per day for a minimum of 5 years"

So, 35TB is the spec for Intel on the X25-V.

Link to Datasheet

edit:

I have drives that have been used for about one year and they still haven't written 1TB, so, 20GB per day is actually quite a bit.
In this case, 20GB per day is 50% of the total capacity :)

Thanks, Anvil. So it's just as I thought. They don't even bother putting a p/e spec in their data sheet. That seems typical of Intel unfortunately. In this case it's not so bad because they are not selling the flash memory separately. I do find it annoying that IMFT doesn't seem to want to make their p/e specs public though. Based on their warranty it seems Intel has a very low opinion of the write endurance of their drives. It seems unlikely they would assume less than 5000 p/e c. for a 34nm chip so it looks like they are assuming a write amplification of about 5.5. Either that or they are, um, bending the truth for some reason. Some people, including IMFT IIRC, say that FUD about write endurance may be reducing the adoption of SSDs, but here we see Intel themselves implying that their drives will only write about 35 TB before suffering a premature death. Bullet, meet Foot.

Quote:

---

Originally Posted by Anvil

So, 107TB, that is more than 3x the warranted 35TB.

---

interesting to me that they would only warranty 35TB, yet the smart data still tells us there is plenty of endurance left. you would imagine they would have adjusted the smart data accordingly, matching the data with their projected endurance.

either way, i am just floored. So impressed with the performance of these intels.
would love to see a C300 done. seeing the strong relationship they have with intel through IMFT, and the fact that they are using the same nand, i wouldn't be surprised if the performance mirrored that of intel.

Quote:

---

Originally Posted by Computurd

would love to see a C300 done. seeing the strong relationship they have with intel through IMFT, and the fact that they are using the same nand, i wouldn't be surprised if the performance mirrored that of intel.

---

A 64GB Crucial m4 should be able to wear out its flash memory in fewer hours with Anvil's program than an Intel 320, since the m4 can write at about 100 MB/s, as compared to the 40GB Intel 320 which is limited to about 45 MB/s. So a factor of 2.2 faster writes, but only a factor of 1.6 more flash memory.

A 64GB Samsung 470 would be interesting to test, also, but I do not know how Samsung flash compares to IMFT flash. The interesting thing is that a 64GB Samsung 470 can write at 170 - 200 MB/s.

Quote:

---

Originally Posted by gojirasan

Either that or they are, um, bending the truth for some reason. Some people, including IMFT IIRC, say that FUD about write endurance may be reducing the adoption of SSDs, but here we see Intel themselves implying that their drives will only write about 35 TB before suffering a premature death.

---

No, what Intel is saying is that they guarantee the SSDs to work for 20GB/day for five years. Intel never said that the drives aren't good for more than that. It is called being cautious, or under-promising and over delivering. Which is a good thing to do in consumer electronics.

Come on guys this thread is BEGGING for a C300. Crucial might wanna rise up to the challenge and give someone here one to test with etc. !!!

I've kind of resorted to skimming this thread now because of the clutter..
I will say that the lifetime throttling period can be set at manufacturer firmware download time, for either unthrottled, or throttling to last for 1,2,3,4,5 years.

The setting on the drive likely matches what the manufacturer offers as their warranty period, but you never know with some dumb :banana::banana::banana::banana: engineers who might set drive manufacturing files wrong.. (I've met quite a few)

Only drive idle time will restore write speed in a lifetime-throttling mode, any Secure Erase that restores performance means that the drive has some other hinderance to its performance (not enough free space, uncompressible random data, etc etc) OR the drive was set to 'unthrottled' option.

One easy way to tell if drive throttling might be kicking in (and what your warranty period is set to):
What's your current SMART power on hours for the drive, and what's your current Write Wear indicator say?

Also, an unthrottled SF-2582 (or 60 of them) is ridiculous to play with. 90k IOPS. enough said.

109.36TB Host writes
MWI 40

--

@zads
I think you are spot on on the throttling, will do some checks on my SF drives.

@bulanula
I'd rather test the m4, I expect it to complete the test in a shorter time as it's about 30% faster on writes vs C300.

146TB. 25%. Reallocated sectors up by 1 to 12.

It looks like we'll be getting a new contestant :)

If all goes well, a colleague from the Norwegian forum will be joining with the Crucial m4 64GB, probably by the end of this month. (sometime next weekend)


--

110,66TB Host writes
MWI 39

Reallocated sectors still at 6. (it's been a long time since this changed)

updated the chart...

Can somebody please now get a C300 so that I can prove that C300 > M4 in terms of endurance etc. ?

Is it just me or is the X25 catching up to the 320 slowly but steadily etc. ?

The MWI values don't mean ANYTHING for now. The real winner in the 25 vs 34 nm race will be revealed after MWI goes past zero!

Did you folks add the read/md5sum verification in the mix? It is possible that the drives are dead already as far as the usefulness of them is concerned. I mean in real world, you would likely RMA the drive on signs of corruptions, not continue to write.

And I am sick of this Sandforce crap! I hope they learn to not cheat and take the customers for fools like they do at this time. Talk of making a quick buck off of gullible customers! I mean 500MB/s writes? Yeah riiiiggggghhhht! More like 200MB/s. And then, of course throttle down to single digit MBs. Yeah awesomenessss!

^ Post #467

Attachment 116767

148.5tb. 23%.

112.98TB Host writes
MWI 38

updated chart

Quote:

---

Originally Posted by devsk

And I am sick of this Sandforce crap! I hope they learn to not cheat and take the customers for fools like they do at this time. Talk of making a quick buck off of gullible customers! I mean 500MB/s writes? Yeah riiiiggggghhhht! More like 200MB/s. And then, of course throttle down to single digit MBs. Yeah awesomenessss!

---

I agree that throttling is crap, more an unnecesary sollution, but I see Sandforce as a state of the art controller. For example, let's say you are a programmer and you are working with databases or large java heap dumps. These kind of files are compressing to a level around 3-10% with 7zip. With a Sandforce based SSD you will be able to write and read these files at about 500MB/s and still use probably less than one fifth of the wear any other SSD would endure. You could achieve probably the same thing with Windows if you activate archiving, but this would be a software solution that would use your CPU power. Once I used my SSD at work in heavy database tasks. I successfully wrote around 150GB (host writes) in 8 hours yet I had not seen any change in flash writes counter, which is increasing 64GB increments. I personally do not imagine any "normal" usage that would create a sustained high write speed which would activate a severe throttling. Even if it would be used as a cache for some slower HDDs, it would probably still have plenty of idle time with only reads.

Quote:

---

Originally Posted by sergiu

I agree that throttling is crap, more an unnecesary sollution, but I see Sandforce as a state of the art controller. For example, let's say you are a programmer and you are working with databases or large java heap dumps. These kind of files are compressing to a level around 3-10% with 7zip. With a Sandforce based SSD you will be able to write and read these files at about 500MB/s and still use probably less than one fifth of the wear any other SSD would endure. You could achieve probably the same thing with Windows if you activate archiving, but this would be a software solution that would use your CPU power. Once I used my SSD at work in heavy database tasks. I successfully wrote around 150GB (host writes) in 8 hours yet I had not seen any change in flash writes counter, which is increasing 64GB increments. I personally do not imagine any "normal" usage that would create a sustained high write speed which would activate a severe throttling. Even if it would be used as a cache for some slower HDDs, it would probably still have plenty of idle time with only reads.

---

Agreed! It is state of the art controller for sure. The concept is good but the way it is marketed by vendors is awful AND bordering on cheating! And the throttling is not even needed, as has been proven by the experiments in this thread. Rate it for lifetime writes of XYZ TB and don't throttle!

@devsk.. Throttling hits when ALL the nand have been written at least once and the Durawrite's GC map has been fully formed once more. While Sandforce/OCZ will often force feed most to believe that it's a lifespan saving algorithm?.. it just more of a limitation as to what the controller will do once it must differentiate between all it's interanl algorithms being introduced.

Think of it(lifetime throttle) as kind of like an "overhead loss".. rather than jsut a lifespan saving algorithm since the controller must TRIM, recover on the fly(if no fresh blocks remain), wear level and rotate data all at the same time. The "hammered state throttle" would definately be considered a lifesaving algorithm.

Far too much dramatization going on here. If you don't like it?.. don't use it. Simple as that and no one needs another consumer advocate posting claims of false advertising around here. Plenty of threads about that crap over at Anandtech if you're into that sort of thing. It just is.. what it is.

Quote:

---

Originally Posted by groberts101

@devsk.. Throttling hits when ALL the nand have been written at least once and the Durawrite's GC map has been fully formed once more. While Sandforce/OCZ will often force feed most to believe that it's a lifespan saving algorithm?.. it just more of a limitation as to what the controller will do once it must differentiate between all it's interanl algorithms being introduced.

Think of it(lifetime throttle) as kind of like an "overhead loss".. rather than jsut a lifespan saving algorithm since the controller must TRIM, recover on the fly(if no fresh blocks remain), wear level and rotate data all at the same time. The "hammered state throttle" would definately be considered a lifesaving algorithm.

Far too much dramatization going on here. If you don't like it?.. don't use it. Simple as that and no one needs another consumer advocate posting claims of false advertising around here. Plenty of threads about that crap over at Anandtech if you're into that sort of thing. It just is.. what it is.

---

Are you saying I don't have the right to make my opinions known on a public forum? And everyone should agree with you? I don't care how you spin it. If the drive starts writing at 6MB/s before 3 years of use (and I define the use within some TB of data and how quickly I want to write, and not Sandforce), I would complain about it.

Guys, write throttling, as I have experienced is highly unlikely to occur to anyone using their SSD normally.

The only thing that is infuriating is the lack of official info, hence why I have explored this.

If people want to work within parameters that enables the excellent performance of a SF drive to be fully utilised, without the fear of inducing throttling they should be entitled to the info.

IF published specs are based on short burst speeds before they are throttled, it should be stated clearly.

your theory makes no sense here. the drive is "lifetime throttled"?.. yet only with sustained data loads? IOW, this heavily assumed "lifetime throttle" is only imposed after a short burst of data? LOL

You have other issues with that drive and you're just chasing your tail here. I would RMA the drive(obvoiusly don't want to make mention of this testing) and get another to test. Lifetime throttling is not used at ANY stage of the lifespan of these controllers in any real literal sense of the word. If an SE isn't clearing the maps to allow full factory fresh speed?.. you have other issues. Go ask Tony again and be more clear about your specific question for the actual long term effect of "lifetime throttle".

Quote:

---

Originally Posted by devsk

Did you folks add the read/md5sum verification in the mix? It is possible that the drives are dead already as far as the usefulness of them is concerned. I mean in real world, you would likely RMA the drive on signs of corruptions, not continue to write.

---

The drives are fully operational, One_Hertz has done a full pattern test on his drive and I've still got the OS on mine so I'm going to boot on it and run the test on the original pc where it all started.
I've implemented the MD5 stuff, I just need to make some options for it.

Quote:

---

Originally Posted by sergiu

I agree that throttling is crap, more an unnecesary sollution, but I see Sandforce as a state of the art controller. For example, let's say you are a programmer and you are working with databases or large java heap dumps. These kind of files are compressing to a level around 3-10% with 7zip.
...

---

This is almost exactly how I'm using my SF drives, they are just perfect for this kind of setup.

Well, it seems there is no point on doing endurance tests on the consumer SF drives, we'd have to get to a drive without the warranty option set. (throttling disabled)
Link to "Configuring SSD Warranty period" not sure about the authenticity of this document.

Quote:

---

Originally Posted by Anvil

Well, it seems there is no point on doing endurance tests on the consumer SF drives, we'd have to get to a drive without the warranty option set. (throttling disabled)

---

Or, find someone who has a V2 that has been powered on continuously for a year or more, but very little writes. In that case, the warranty throttle will have built up a large gap between the current writes and the warranty-throttle line. In the case of an SSD like Ao1's, it should accumulate about 630TB per year (72GB/hour). So even 6 months of idle time may be enough if the SSD is similar to Ao1's.

One of GR's V2's with about 8000 hours would be ideal. :D

8000 hours with just a few TB's worh of writes would be just perfect :)

Seriously though, I don't think any of my drives are candidates, I've got a bunch of 60GB drives but I don't think they have nearly that many hours, just the TB's :)
I'll do a check on the most likely candidates.

I have two 50GB V2s with over 7000 hours and roughly 1.7TB of host writes each (roughly 1.6TB of NAND writes each). Unfortunately, they're in R0 as my boot drives in my primary system, so basically untouchable :(

114.88TB Host writes
MWI 37

--

I'm sure we'll find someone with a suitable V2, that 8000hour drive would have been perfect though.

Seeing how the SF controller has evolved I'm pretty sure that the SF2 would be the preferred one to get for this test. (although the Warranty period is the crucial factor for this test)
The downside is that there won't be any SF2 drives with 1000s of hours on them, yet.

152TB. 21%. Reallocated sectors up to 13.

Seems like groberts got banned.

Anyway, anyone want to volunteer a C300 so I can prove that 34nm NAND >>> 25nm NAND ??? Eg there is no major controller difference between the M4 and the C300 so this would be perfect seeing that Anvil already has a M4 drive etc. !

Or perhaps some of the better known people might want to take this up with Crucial ???

Don't know but I think we really need a 25nm vs 34nm debate between the M4 and the C300.

The only reason the Intel 320 seems to be better than the X25-V drive here is because of its improved controller etc.

We have a new contestant in the endurance test: 64GB Samsung 470. It uses 32nm Samsung toggle DDR NAND flash, which tech-report has this to say about:

http://techreport.com/articles.x/20087

Quote:

---

According to Samsung, the 470 Series' flash chips have a write-erase endurance of only 3,000 cycles

---

It seems that Samsung only cares about sequential write speed. The 64GB Samsung 470 has the fastest incompressible-data sequential write speed, by far, of any MLC SSD below 100GB. I can see the engineers sitting around developing this SSD: "Let's get the highest sequential write we possibly can" "Yeah!" "Okay" "But what about 4KB performance? And what about SMART attributes for monitoring health?" "Shut up, you! Get with the program!"

Anyway, the SMART attributes on this SSD are anemic. Only 6 of them, and none of them appear to be host-writes or media-wear-out-indicator. They are also poorly documented. smartmontools labels one of them as supercapacitor health, but I don't think this SSD even has a supercapacitor. Anyway, I will be monitoring the SMART attributes as the test proceeds, so maybe we can deduce what they all are.

In the meantime, I will be sure to write down the TB-written from Anvil's program every day, since I cannot currently read it from the SMART attributes, and if Anvil's program gets restarted the TB-written will be cleared.

I also put a 40GB static data file on the SSD, with a known MD5 checksum. So that should help test the wear-leveling for static data, and also see if any data corruption develops.

Attachment 116842

smartmontools (I don't think this SSD has a supercapacitor, so I guess smartmon got that attribute name wrong):
Attachment 116844

endurance test started:
Attachment 116843

Nice :D This will be interesting.

Very nice johnw :)

Wish we could get a pair of drives with identical controllers but with 34nm vs. 25nm NAND....like a Force 60GB vs. Force 55GB, but lifetime throttle basically precludes Sandforce from this and no one else has been so...loose...with NAND selection :eh: Maybe some Indilinx drives?

Anvil, I'm curious about the various compressibility levels, are they a combination of 0-fill and incompressible or are they more 'advanced' than that (for lack of a better term)?

Quote:

---

Originally Posted by Vapor

Wish we could get a pair of drives with identical controllers but with 34nm vs. 25nm NAND....like a Force 60GB vs. Force 55GB, but lifetime throttle basically precludes Sandforce from this and no one else has been so...loose...with NAND selection :eh: Maybe some Indilinx drives?

---

While it would still be an interesting test don't we already know that, all other things being equal, 34nm NAND lasts longer than 25nm NAND?

I'm more interested in seeing how they compensate for that, things like improved controllers, improved redundancy, extra over provisioning, etc.

Quote:

---

Originally Posted by Dragoonseal

While it would still be an interesting test don't we already know that, all other things being equal, 34nm NAND lasts longer than 25nm NAND?

---

We know what we're told, but I'd still like to see it :p: Sample size of 1 each is too small to be significant, but I'd still like to see something like 1.6x the lifespan.

Quote:

---

Originally Posted by Dragoonseal

I'm more interested in seeing how they compensate for that, things like improved controllers, improved redundancy, extra over provisioning, etc.

---

Agreed that the overall product is the most important aspect of testing :)

@johnw

Exceptional sequential write rate on that little thing :)
Looking forward to the next few days, wondering how TRIM is handling the constant writes.

@Vapor
The levels are fine-tuned "functions" that return random data, so there is no combination of 0-Fill and incompressible.

The levels are
0-Fill
8% (Database, a typical compression rate for database files)
25% (doesn't really correspond to anything in particular)
46% (applications, dlls, ...)
67% (same as 25%)
100% Incompressible

The % is the compression rate that 7Zip returns for a that particular datastream, SF compression rates might not correspond at all to 7Zip.
(might be possible to find out using the SF2 controller as 233, 241 reports every GB written and not just every 64GB as is the case with SF1)

A C300 64GB would have been a perfect match for the m4 that is about to start later this week.

Ah, so it is more advanced than just a mixture of 0-fill and incompressible, very nice :)

I still want to get 'in' on the testing myself...was going to do a 2nd SF1200 drive using partially compressible to juxtapose Ao1's with incompressible, but the lifetime throttle showed itself just a couple days before I was going to order.

Am pondering switching to a single 120GB drive and using one my 50GB V2s (with 7000 hours and just 1.7TB of writes) vs. a C300 64GB vs. a SF1200 with no lifetime throttle. I do want to contribute other than being in the peanut gallery :p:

If only we had a C300 now !

We could easily see which 2010 SSD is the best in endurance etc. Keep the expensive ( M4 / SF2 ) stuff for later on!

Quote:

---

Originally Posted by bulanula

If only we had a C300 now !

We could easily see which 2010 SSD is the best in endurance etc. Keep the expensive ( M4 / SF2 ) stuff for later on!

---

You know, you could buy a C300 and run the test yourself. I expect Anvil would be glad to send you a copy of his app.

Now that we are closing in on 0 MWI we should consider other means of creating the chart, maybe start using P/E?

Windows Update rebooted the PC so it's been idling for 9 hours.

116,86TB Host writes
MWI 36

--

@johnw
How is the 470's 177 Wear leveling count evolving, could it be that it works like the Crucials, each count = 1 P/E cycle. (meaning 1= 64GB and so on)

Yeah when we get to 0 we will need a new way of charting this. 155TB. 20%.

Quote:

---

Originally Posted by johnw

You know, you could buy a C300 and run the test yourself. I expect Anvil would be glad to send you a copy of his app.

---

If I wasn't broke I would have done this a long time ago etc. ! Stuff ( normal commodities ) is very expensive here in the UK and electronics are even more expensive.

Maybe somebody in a better financial situation from the US etc. ???

Hate to be in the peanut gallery but that is the way it's going to be unless I inherit some cash overnight :D

And also, I don't have a Windows machine in the house anyway ( yes, I'm THAT cheap LOL ) so maybe Anvil could make a Linux version ?

I agree, we need a new chart indicator.

I would think a simple bar chart for writes (either in write-hours or bytes) would be good :) Writes and writes-after-zeroMWI would probably be the most pertinent categories.

Looks like I'm going to step into the testing with a C300 64GB....and maybe try to rekindle the SF-1200 testing. I'll probably get a 34nm drive SF-1200 and would like to pair my testing up with someone interested/capable testing a 25nm drive. Something like a F60 and F60A...yes, LTT is in the way, we'll figure out a way around it. If you're interested in testing a SF-1200 and coordinating with my testing, please let me know in the next couple of days--it would be easier to do this at the same time.

Quote:

---

Originally Posted by Anvil

@johnw
How is the 470's 177 Wear leveling count evolving, could it be that it works like the Crucials, each count = 1 P/E cycle. (meaning 1= 64GB and so on)

---

177 went from 1 to 485 with about 8.6 TiB (TB?) written. I'm not sure what that means. Smartctl says it is the difference between the most and least worn block in percent, but I think it is wrong about that (it is not percent anyway, at best it would be percent x 1000 or something)

1 day elapsed:
Attachment 116869

original smart:
Attachment 116867

1 day smart:
Attachment 116868

Disclaimer: this post is all just a guess :lol:

Looks kind of like Raw is P/E cycles and Normalized value is MWI. 10% wear (100-90) does correspond to 485 P/E cycles. I'll guess we'll know more when it dies :p:

8800GB / 485 = 18.14GB per count. With a write amp of ~3.5x, 18.14GB works out to 64GB (one P/E cycle).

Quote:

---

Originally Posted by Vapor

Disclaimer: this post is all just a guess :lol:

Looks kind of like Raw is P/E cycles and Normalized value is MWI. 10% wear (100-90) does correspond to 485 P/E cycles. I'll guess we'll know more when it dies :p:

---

Could be! If normalized 177 is MWI, then it looks like I can run it to zero in about 10 days, and 86TiB of writes. The Intel MWI looks like it is going to 0 around 200TiB, IIRC. Samsung is more paranoid than Intel? Or 177 is not MWI. Hmmm.

It's the only thing acting like a MWI...so I guess just roll with it :shrug:

If it is MWI, Samsung could be more conservative than Intel, write amplification could be very different (~90TiB on 64GB vs. 200TiB on 40GB is disturbingly different though), a combination of the two, or something else entirely (different NAND?).

Good news to add to the thread: got a C300 64G and it will be entered into testing around the same time as the M4 64GB :D

Subbed to see results. I got 2x 128Gig M4's coming by the weeks end here and after that I'll be taking my 2x Intel G2 80Gigs out of Raid 0. Curious to how much they have been writen to since I put them in service roughly 21 months ago.

Quote:

---

Originally Posted by deathman20

Subbed to see results. I got 2x 128Gig M4's coming by the weeks end here and after that I'll be taking my 2x Intel G2 80Gigs out of Raid 0. Curious to how much they have been writen to since I put them in service roughly 21 months ago.

---

HD Sentinal can read SMART data through a RAID0 array :)

Quote:

---

Originally Posted by Vapor

HD Sentinal can read SMART data through a RAID0 array :)

---

So can the Intel SSD Toolbox, or at least some of them? I'm not sure how many there actually are, seems to have all the important ones though.

Attachment 116873

Jesus, 15 months of use and a MWI of only 98? These things are going to last longer than I will. And I have all my games, user folders, and page file on them, everything but my media. Makes me curious what will start killing SSDs after the next 10 years or so, surely some other components of theirs will start to fail before the NAND ever wears out. Power surges or dirty power sources maybe?

Ah, didn't know Intel's tool could do it, I don't have Intel SSDs in RAID. Good info to have.

You only had ~4.1TB of host writes (1.36 * 3) in the past 15mo across three drives, makes sense MWI didn't go down much :)

OOoh guess im going to check that out tonight!

Hello everyone! :)

I will be joining you with my M4 like Anvil announced earlier this week.

It's brand new out of the box and below follows some smart info before any benchmarking and testing has started.

CDI
Attachment 116876

GsmartControl
Attachment 116877

I will be testing the M4 from my main rig (look in my signature) and to make sure trim and smart info is working I've installed my os to a single drive (C300 256GB) for the duration of the test. The M4 has also been flashed with the latest firmware(0002).

Some performance numbers (The m4 has been quickformated and trimmed between each benchmark):

AS SSD
Attachment 116878

CDM
Attachment 116879

ATTO
Attachment 116880

I talked to Anvil earlier today and he wants me to wait until the C300 is ready so we can start at the same time.

Is there anything else I should think of?

B.A.T

Quote:

---

Originally Posted by Dragoonseal

Makes me curious what will start killing SSDs after the next 10 years or so, surely some other components of theirs will start to fail before the NAND ever wears out. Power surges or dirty power sources maybe?

---

I had the same question for some time and I also believe power sources will be the major death cause for SSDs. I was even thinking to buy an oscilloscope to check periodically the power supply for signs of failures.

Quote:

---

Originally Posted by B.A.T

Hello everyone! :)

I will be joining you with my M4 like Anvil announced earlier this week.

---

:welcome:

Thank you so much for providing the C300 and the M4 for the testing. I am 90% sure that the C300 will perform much better etc.

This thread is really starting to heat up now :)