SSD Write Endurance 25nm Vs 34nm

[Christopher]

Thanks for the help, Anvil.

My estimate was based on erase count numbers, and I was only off by about 300GB.

Actual count: 50,769GiB, 49.58TiB

[Hopalong X]

I really think we should get a C300 in here to complement the existing controllers.

I think that MTRON will last a LONG time. Hehe.

Go for it! Don't forget to post your results daily!

[UrbanSmooth]

Had a Crucial C300 256GB SSD that just died a week ago. Purchased back in March of 2011. Gave me a good 11 months.

Bought a Crucial M4 256GB SSD to take its place. So far, so good.

[Christopher]

Had a Crucial C300 256GB SSD that just died a week ago. Purchased back in March of 2011. Gave me a good 11 months.

Bought a Crucial M4 256GB SSD to take its place. So far, so good.

I assume you're going to RMA the C300?

I've read about some strange, isolated issues with the C300. Did you see any smart data before (within a few days) the drive died?

[canthearu]

New drive being endurance tested. (Patriot Torqx 64gig)

Controller: Phison PS3105-S5
NAND: Toshiba 32nm (probably 5000 cycle rated)
Cache: 128meg DDR

Impressions: Drive has great difficulty maintaining high performance under heavy load. Either I am seeing huge write amplification during the endurance test, or (and probably more likely), the drive simply isn't erasing blocks in a timely manner. This drive may need a lot of idle time to perform decently.

Benchmarks after inital wear in: (4th run of crystaldiskmark or so)



Day 0 SMART values:



I am pretty sure attribute AA represents bad block counts. I will keep people updated when that changes.

I am also fairly sure AD represents wear levelling. I'm not too sure what the numbers mean ... but the 2nd and 3rd raw numbers of this attribute increment individually.

[canthearu]

DAY 3 images:




Drive seems to like that 16meg per second number.

Most future updates will be text-only from now to save time/sanity.

[canthearu]

Drive hours: 126
GB written: 6897.82
Avg MB/s: 16.93

Bad blocks: 83
Wear cycle counters: 0/435/673 (100 normalized)

[Anvil]

@canthearu

A few missing details,

Size of static data
OS and platform
Date started
Over-provisioning?

[Christopher]

I was actually pretty surprised by the performance of the Torqx. The 3016 Phison is probably pretty similar to the 3105 in the Torqx, but I'm 99.4% the firmware of the 3016 uses block level mapping and not page level mapping. If you look at the 512K results in CDM, the 3016, when fully populated, is only gonna do like 12MB/s. The 3105 is just much, much better.

And it somewhat makes sense -- the Phison was surely a CF/SD/etc controller initially, optimized for taking pictures at least 1MB in size.

The Patriot PS-100 I have uses the 3016 with 32nm Toshiba, 32gbit devices. It does get TRIM, but not NCQ. And it sucks. A lot. You can't even complete a run of AS-SSD.

The MyDigitalSSD Bullet 128GB mSATA uses the Phison, and it's quite good. I just don't think it holds up well over time.

[canthearu]

@canthearu

A few missing details,

Size of static data
OS and platform
Date started
Over-provisioning?

Static Data: 15gig
OS/Platform: Core duo 2 - 2160@3.0ghz - Windows 7 x64
Date Started: 16/2/2012
Over-Provisioning: None

[canthearu]

I was actually pretty surprised by the performance of the Torqx. The 3016 Phison is probably pretty similar to the 3105 in the Torqx, but I'm 99.4% the firmware of the 3016 uses block level mapping and not page level mapping. If you look at the 512K results in CDM, the 3016, when fully populated, is only gonna do like 12MB/s. The 3105 is just much, much better.

Well, one thing I do notice with the Philson controller is that there is an enormous gap between factory and steady state performance ... however I'm unsure if the controller would eventually garbage collect and restore decent performance from steady state if left alone for a while. Post Secure-Erase, the drive is quite fast .... but very soon degenerates back to the slow steady state. I might turn off the endurance test for a night soon and see.

All I can see now is the huge gap between the Philson and the other SSDs I own. A sandforce drive will happily accept 60meg per sec or more (depending on drive/NAND) of writes for as long as you want without performance significantly falling away.

Edit: Yep, I do get your point about Philson controllers being generally for portable media .... my USB 3.0 memory stick uses a Philson controller, and for a USB stick, it is quite excellent (where write speeds can be as awful as 2-3 meg per second if you don't pay attention to what you buy)

[Christopher]

Yeah, I wouldn't bother with seeing if the Phison is going to recover... Just keep testing it, unless it goes down to single digits. After a while it should find an equilibrium of sorts.
My 32GB Patriot PS 100 only manages 3 or 4 MB/s in the test.

[Christopher]

MTRON 7000 PRO 16GB SLC, Day 13

GiB : 55929.81
TiB : 54.6190
MBs : 55.70

187 95/94/90129124

[nn_step]

anyone else notice this: http://cseweb.ucsd.edu/users/swanson...BleakFlash.pdf

[Christopher]

anyone else notice this: http://cseweb.ucsd.edu/users/swanson...BleakFlash.pdf

Yes. It didn't really do much to change my opinion that depending on how you want to look at it, the best (quality) drives have already been made. Future drives may be faster -- but not necessarily better.

Who is really looking forward to a drive with TLC NAND? Not me.

[canthearu]

Yes. I didn't really do much to change my opinion that depending on how you want to look at it, the best drives have already been made. Future drives may be faster -- but not necessarily better.

Who is really looking forward to a drive with TLC NAND? Not me.

Future drives won't be all bad ... eventually the increased density will lead to increased sizes, which will largely offset the reduction in erase cycle endurance. At the moment, most of the increased density is being used to reduce prices, but we can only go so far in that direction while maintaining performance/endurance.

I certainly won't be buying a TLC NAND based drive (unless it is to murder in an endurance test ) Giving up way too much endurance for far too little space.

[B.A.T]

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


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

[Christopher]

MTRON 7000 PRO 16GB SLC, Day 14

GiB : 59720.72
TiB : 58.3210
MBs : 55.84

187 95/94/96438169


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

[Anvil]

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)

[bulanula]

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 !

[canthearu]

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.

[Christopher]

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?

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

[Christopher]

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.

[canthearu]

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

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