SSD Write Endurance 25nm Vs 34nm

[johnw]

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.

[bulanula]

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. !!!

[zads]

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 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.

[Anvil]

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.

[One_Hertz]

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

[Anvil]

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...

[bulanula]

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!

[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.

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!

[Ao1]

^ Post #467

[One_Hertz]

148.5tb. 23%.

[Anvil]

112.98TB Host writes
MWI 38

updated chart

[sergiu]

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.

[devsk]

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!

[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.

[devsk]

@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.

[Ao1]

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.

[groberts101]

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".

[Anvil]

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.

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.

[johnw]

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.

[Anvil]

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.

[Vapor]

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

[Anvil]

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.

[One_Hertz]

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

[bulanula]

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.

[johnw]

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

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.



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


endurance test started: