SSD Write Endurance 25nm Vs 34nm

Yesterdays update:
Kingston V+100
And it dropped out again.....

Intel X25-M G1 80GB
359,6176 TiB
21097 hours
Reallocated sectors : 00
MWI=103 to 102
MD5 =OK
43.62 MiB/s on avg
http://www.diskusjon.no/index.php?ap...tach_id=480137http://www.diskusjon.no/index.php?ap...tach_id=480141

m4
446.3624 TiB
1761 hours
Avg speed 72.43 MiB/s.
AD gone from 106 to 100.
P/E 7699.
MD5 OK.
Reallocated sectors : 00
http://www.diskusjon.no/index.php?ap...tach_id=480142http://www.diskusjon.no/index.php?ap...tach_id=480136

MTRON 7000 PRO 16GB SLC, Day 14

GiB : 59720.72
TiB : 58.3210
MBs : 55.84

187 95/94/96438169
Attachment 124202

I honestly don't know why I even bother. One update per lunar cycle is probably sufficient.

Kingston SSDNow 40GB (X25-V)

732.83TB Host writes
Reallocated sectors : 05 23
Available Reserved Space : E8 99
POH 6591
MD5 OK

33.53MiB/s on avg (~143 hours)

Quite interested as to how that C300 256 GB died, UrbanSmooth.

Yeah, I saw the bleak NAND news. I have been saying this all along. You can only scale NAND to a certain level but we need a different storage technology to replace it pretty soon in the next few years, I think.

TLC NAND ? No, thank you !

People get too worried about a SSD wear.

Even with only 1000 write cycles (some mythical smaller NAND MLC, say 12nm, 2 generations ahead of current tech), a 1TB SSD would still be fairly midrangish and still handle almost 1 PB of writes before reaching end of NAND life.

Anvil,

How important is the composition of the static data? Should we try to standardize the amount of static data per capacity? Could ASU be modified to generate the static files automatically based on a scale?

That's not a bad idea.

#1 should always be OS files as in a copying i.e windows files as using real files is more fair vs compressing controllers
#2 could be generated to a fixed % of the total capacity and can be a mix of "compression levels"

Quote:

---

Originally Posted by Anvil

That's not a bad idea.

#1 should always be OS files as in a copying i.e windows files as using real files is more fair vs compressing controllers
#2 could be generated to a fixed % of the total capacity and can be a mix of "compression levels"

---

Well, I was thinking OS files could be simulated with ASU in the endurance or settings tabs... it could just fill x amount of capacity with "OS like" files in terms of size, number, and compressibility with the press of a button. And it would just do a standard percentage (by default, other % options too, maybe) of the drive's capacity. For example, the 16GB MTRON would have 1/4 the simulated OS files of the 64GB Samsung. Since ASU can already generate files of various compression levels and sizes, I was thinking it might not be that difficult to implement... but I'm not really qualified to answer that.

In that way, all new drives could get on a standard static data regimen.

Drive hours: 173
GB written: 9488.36 (9.2662 TB)
Avg MB/s: 16.42

Bad blocks: 83
Wear cycle counter: 0/596/911

Nice read here for anyone that is interested : http://www.anandtech.com/show/5067/u...nding-tlc-nand

I’ve got some specs for Samsung TLC over in the SSD NAND data base. 8K page/ 1.5MB block. Random read = 300. Page programme = 2,700 and erase = 1.5ms. Both the random read and page programme times are well in excess or 2xn/ 3xn NAND.

The price of NAND sucks.

Quote:

---

Originally Posted by Ao1

I’ve got some specs for Samsung TLC over in the SSD NAND data base. 8K page/ 1.5MB block. Random read = 300. Page programme = 2,700 and erase = 1.5ms. Both the random read and page programme times are well in excess or 2xn/ 3xn NAND.

The price of NAND sucks.

---

You know, I actually think cheaper NAND is going to be destructive. I'm sure companies like Intel can always charge more, but the margins will get so low [for everyone else] that people are just going to be making junk just to survive. Maybe not this year or next, but someday... but sooner than you'd hope. When the price gets much lower/GB, they're gonna become commodities. So be careful what you wish for. By the time they're dirt-cheap as you'd like, you're not gonna want one anymore.

Quote:

---

Originally Posted by Christopher

You know, I actually think cheaper NAND is going to be destructive. I'm sure companies like Intel can always charge more, but the margins will get so low [for everyone else] that people are just going to be making junk just to survive. Maybe not this year or next, but someday... but sooner than you'd hope. When the price gets much lower/GB, they're gonna become commodities. So be careful what you wish for. By the time they're dirt-cheap as you'd like, you're not gonna want one anymore.

---

well, it was kinda obvious with 34nm to 25nm move :)

MTRON 7000 PRO 16GB SLC, Day 15

GiB : 65215.26
TiB : 63.6874
MBs : 56.45

187 94/93/105544458

The little MTRON just keeps getting faster. I'm actually quite impressed by it's performance (and that of the 3.5" 7035, which is now the system drive in the Endurance Rig)

Hmmm, my torqx is going to take a very long time to kill (if write amplification isn't terrible). To fill the time, I'll also be endurance testing an Intel 520 - 60gig SSD.

I'm interested in:

a) The failure mode. A lot of the previous Sandforce drives failed very suddenly and unexpectedly ... like wheel bearings in a car failing and the car veering off the road and crashing into a tree (then bursting into flames) ... I'm curious if Intel's QA has improved that at all.

b) The overall number of writes the drive can handle. Given intel are using 5000 cycle NAND rather then the more common 3000 cycle NAND, it will be interesting to see how long it can hold out. However, apparently intel's NAND is exactly the same as the Micron 3000 cycle NAND, so it might not make any difference at all.

c) Interested in long term steady state performance. It should be pretty good, but maybe a touch below the Toggle NAND drives.

Anyway, benchmarks and stuff a little bit later after I compile them!

^ great, I'm looking forward to this one :)

@canthearu -- are you familiar with the 60GB Mushkin Chronos Deluxe I tested?


I think the big difference with the the 520 will actually be the lack of RAISE and added overprovisioning. It's still going to act like the other SF drives in other respects, but I do believe Intel when they say that their drives have the good stuff inside. Someone has to get all the schwag IMFT stuff left over, and I'd guess that stuff goes inside SF drives frequently.

In terms of testing drives, right now the cupboard is kinda bare. I'm still not giving up on running a 64GB Vertex Turbo -- I'm gonna find one that doesn't suck. The MTRON should be sticking around for a while, and I have a "mystery drive" I hope to start testing shortly.

@Christopher -- yep, I have read at least most of this entire thread! I was refering to your Mushkin Chronos Deluxe when talking about the toggle NAND drives being slightly faster.

To be honest, I'm a bit of a fan of the sandforce drives .... I like their approach to reducing write amplification and the ability to run without a DRAM cache. Now, that isn't to say that other drives are bad, or that there is nothing to fault sandforce with. (as the crucial m4 and intel 320 drives are quite excellent, and the sandforce drives have certainly had their fair share of problems) I guess the main attraction was that they were the first company outside of intel to really work on a drive design that didn't suck (like the jmicron and barefoot based drives did)

Quote:

---

Originally Posted by canthearu

@Christopher -- yep, I have read at least most of this entire thread! I was refering to your Mushkin Chronos Deluxe when talking about the toggle NAND drives being slightly faster.

To be honest, I'm a bit of a fan of the sandforce drives .... I like their approach to reducing write amplification and the ability to run without a DRAM cache. Now, that isn't to say that other drives are bad, or that there is nothing to fault sandforce with. (as the crucial m4 and intel 320 drives are quite excellent, and the sandforce drives have certainly had their fair share of problems) I guess the main attraction was that they were the first company outside of intel to really work on a drive design that didn't suck (like the jmicron and barefoot based drives did)

---

I had never owned a SF drive until I got the Chronos Deluxe 60 for testing. Since then, I've picked up a couple to play with and I do quite like them (despite their flaws and some of my skepticism of SF's claims concerning performance and longevity).

The 120GB Chronos Deluxe is pretty excellent, and I also like the SF1500 Vertex LE 100 too, but I've hardly used either to date. I just began using the 120 ChDx full time only two weeks ago, on hardware that was problematic with the original 60GB testing drive. I've not yet had any issues, but I can't rule out the odd future BSoD. Also in the Mushkin's favor, the 240GB version was selling for insanely low prices recently (less than a 240GB Agility 3, around $278), but I missed out on the deal.

The OWCs, Patiots, and Mushkins are all assembled in America, which is a nice bonus. But the Wildfire and OWC Mercury Extreme 6g are substantially more expensive than the Deluxe.

Quote:

---

Originally Posted by Christopher

I'm still not giving up on running a 64GB Vertex Turbo -- I'm gonna find one that doesn't suck.

---

Then you better get a Crucial M225 and do what I did ;)

Quote:

---

Originally Posted by bluestang

Then you better get a Crucial M225 and do what I did ;)

---

Zing!

Check back on Monday and see the next great hope for humanity... another new 64GB Vertex Turbo. Cross your fingers, say a prayer, and sacrifice a chicken -- then hope for the best.

For the 520 NAND writes (249) = 1iGB increments. For host writes (241) a value of 1 = 32GiB, so in the example below 2,656 = 83GiB for host writes vs 80GiB nand writes.

The threshold for the media wear out indicator is 0, unlike non Intel SF drives, which have a threshold of 10.

Attachment 124224

For the SF2xxx NAND writes (233) = 1GiB increments. For host writes (241) a value of 1 = 1GiB

Attachment 124223

For the SF1xxx NAND writes (233) = 1GiB increments. For host writes (241) a value of 1 = 1GiB

Attachment 124222

For the X25-M NAND writes are unknown

Attachment 124220

For the Samsung 830 host writes (241) 1 raw increment = ( 1 * 512 ) / 1073741824 = GiB.

Medial Wear Out Indictor =
Wear Levelling Count (177)
Raw value /5,000 *100 = x ( 100- x) = % remaining life
10/5000*100 = 0.2 (100-0.2) = 99.8%


Attachment 124221

Quote:

---

Originally Posted by Ao1

For the 530 NAND writes (249) = 1GB increments. For host writes (241) a value of 1 = 32GB, so in the example below 2,656 = 83GB for host writes vs 80GB nand writes.

---

If I'm honest, 530 sounds much more awesome than 520.

The fact that two different reporting standards are used for host and raw writes is irritating. It would actually be handy if both were in 32MiB increments, but anything is better than 64GB chunks.

Hah well spotted and the values for the Intel drives are GiB (even though the Intel manual reports them as GB). Better change that before John gives me a bollocking :D

Anyway with your 830 did you record 199 when your read/ write speeds were messed up?

(199) UltraDMA CRC Error Count
This is generally the literal count of how many times the controller encountered an error while processing an ATA command in UDMA mode. It also counts how many times a CRC checksum has mismatched during operations. Usually, this indicates a problem with the cabling or drive electronics. These errors can also be triggered by incorrect IDE device chaining or simply a faulty IDE or SATA cable, or when device firmware bug match some chipset detection problem (SATA II at 3.0Gb/s drive misdetecting SATA I at 1.5Gb/s bus controller).

Quote:

---

Originally Posted by Ao1

Hah well spotted and the values for the Intel drives are GiB (even though the Intel manual reports them as GB). Better change that before John gives me a bollocking :D

---

:D I saw it already, but I did not complain because it is Intel's mistake, not yours!