SSD Write Endurance 25nm Vs 34nm

[devsk]

Now, the worst possible scenario is indeed using a SSD as a cache, but also, keep in mind that the usage model for a cache is random writes + random reads where depending on the scenario, you might have a higher number of reads than writes which will decrease the average writing speed significantly to allow a recovery period for NAND cells. If real enterprise usage test usage is desired, then the SSDs should be tested in such a way that each page that was written should be also read at least once. Pure random writes on the entire space would be torture, not real life usage.

Even as a cache device it won't see the 4KB random writes that IOMeter unleashes on the drive. A typical block size for ZFS or Oracle database is much larger than 4KB. And then, caches are typically tuned to merge smaller writes into bigger ones because in-memory caches sit in front of it (you will see 128KB random writes instead of 4KB). And then, top that with the fact that if the caching algorithm is any good, your caches will be read more than written to.

[Computurd]

The purpose of the 4k access is to emulate the worst case scenario imaginable. Not to represent any real life patterns, or even actual enterprise loadings. there are some that are dependent upon 4k however.
the reason ssd caching is tested with 4k is, again, due to it being the hardest to handle. If the solution can handle 4k well, it can handle much easier workloads as well.

[Anvil]

It won't be a real life test and 4KB is rather small by today's standards, 8KB is about the smallest there is for the typical database (Oracle, MS-SQL) on top of this, there is a *lot* of sequential writes.
(there are of course other workloads besides databases but they will most likely have a much larger block size)

I'll make some options on how to write, 4KB, 8KB, ..., as well as more options on size. (including full span)

This type of test is highly unlikely in any environment though.

We already know what Intel data-sheets tells.

100% 4KB writes, 100% span.
G2
80GB = 7.5TB
160GB = 15TB

G3
40GB = 5TB
80GB = 10TB
120GB = 15TB
160GB = 15TB
300GB = 30TB
600GB = 60TB

[Computurd]

i agree

some types of adjustable parameters would be great for this type of testing.

it would be interesting to see what the real numbers behind intels testing are, because previous documents show they measure up to 3 percent nand loss...of course the devices would be able to last much longer just by leveraging OP alone..

[Ao1]

4K random full span is obviously not a realistic work load, but it does provide a way to compare directly with Intel’s specs. It would be interesting to see how that pans out on a 320 40GB drive. Exactly how far out would the specified 5TB value be? x 10? x 20? x 30?

What kind of sustained write speed could the 320 manage at QD 32? (With 4k full span random)

[Computurd]

it will be very very slow actually. the write speed will slow down tremendously with full span.

[Christopher]

It won't be a real life test and 4KB is rather small by today's standards, 8KB is about the smallest there is for the typical database (Oracle, MS-SQL) on top of this, there is a *lot* of sequential writes.
(there are of course other workloads besides databases but they will most likely have a much larger block size)

I'll make some options on how to write, 4KB, 8KB, ..., as well as more options on size. (including full span)

This type of test is highly unlikely in any environment though.

We already know what Intel data-sheets tells.

100% 4KB writes, 100% span.
G2
80GB = 7.5TB
160GB = 15TB

G3
40GB = 5TB
80GB = 10TB
120GB = 15TB
160GB = 15TB
300GB = 30TB
600GB = 60TB

See, this completely puts the 30GB number for the 300GB 320 in context -- the article I read didn't mention anything like that. I wasn't even aware that Intel used the 4K full span method to rate their drives.

Now I feel extra, extra stupid.

[sergiu]

The guys from INTEL are real engineers and are specifying the worst conditions, no real life conditions. Nothing wrong with that, but also some real world expectation should be published, otherwise "average Joe" will read the specs, will see 15TB and will be scared on how low are the numbers. That "average Joe" might be your boss to which you requested a SSD replacement for your desktop at work and these specs will be the best reason to deny your request.

[Christopher]

I suppose that if this Chronos Deluxe does have LTT then I could switch to just 4Ks writes and pound it slowly. The only real desktop workload is actually using the drive for the next 12 to 20 years in a desktop. And that sounds more like a prison sentence.

[Anvil]

The Force 3 is doing great so far.

This first ss shows 2.87 hours of writes w/Security Essentials enabled on the folder where writes are being performed.
2011-09-17-21-51.PNG

This one show 2.87 hours of writes w/Security Essentials disabled on that same folder.
Corsair Force 3 SSD ATA Device_120GB_1GB-20110918-0044.png

CDI_2011-09-18-00-50.PNG

There drive is filled with W7 files (OS), one Virtual Machine, 22GB of mp3 files + some miscellaneous files (mostly incompressible), this leaves ~49GB of free space.

We'll see tomorrow if it can keep up the pace

[Anvil]

I suppose that if this Chronos Deluxe does have LTT then I could switch to just 4Ks writes and pound it slowly. The only real desktop workload is actually using the drive for the next 12 to 20 years in a desktop. And that sounds more like a prison sentence.

Lets see how it works out on the LTT, that is the make or break for the test for all SF based drives.

If we can establish that some of the Manufacturers don't do LTT this alone is worth the drive imho

[Christopher]

I've been playing around some more with the 128GB Vertex Turbo I got in the mail early this week. A few days before that, I had also received a new 60GB Agility 60. Both purchased and received within one week.

Obviously, OCZ isn't making anymore of the original Vertex/Agility, so I figured both drives were leftover stock, stuck in a warehouse somewhere. I was reflecting on this today, and had this crazy idea.

Remember, earlier this year OCZ switched from their metal shell to cheaper plastic ones. So that would mean that these 2 drives should have been manufactured this year, probably in May.

What if OCZ is taking RMAs and returns, destructive flashing them, then dropping the PCB in new enclosures and selling them as new? Mind you, I did get pretty good deals on each, both were about $1 a GB. The metal enclosures' paint wore off easily, so it would be hard to recycle those. That's actually kind of disturbing, since they're you know, sold as new. You'd never have any way of telling how long ago the drive's PCBs were manufactured, and they could destructive flash and remove all the SMART attributes as well. The new plastic drive cases differ only by the sticker on the top, so if you have a functioning returned drive, why not put it in a new shell and resell it?.

Something like 10% of SSDs are returned in perfect working order, but lots of Indilinx drives locked up or got bricked -- both things that could be fixed with a D Flash.


I just thought it was a little suspicious. After all, I don't even think Samsung uses 5xnm Samsung NAND anymore. They have new versions of the 470, ones I believe use smaller process flash, and have slightly different model numbers.


I think it's a little fishy myself. Not saying that's what OCZ is doing, just that if they did, how would you know?

[johnw]

Not saying that's what OCZ is doing, just that if they did, how would you know?

If there were any changes to the circuit board or layout between when the older model was manufactured and the newer models, you could tell by carefully comparing the circuit boards.

[Computurd]

I have a vertex that i received from a RMA situation. It 'panic locked' and could only be broken free of this by means of using a firmware flasher that isn't generally released unless you have a specific problem.
However, these panic-release flashers are released regularly to people with problems, they talk about them all the time in the vertex area of their forums. Only given via pm or email whatever with support.
So they sent me a few of these flashers, as they match up to certain configurations with the type of nand on the vertex series, as there has been a few versions over the years.
When none of the versions worked on my drive, they happened to ask me directly if the drive was received from an RMA> when i told them that it had in fact been an return from a RMA drive, they informed me that drive there wasnt a flasher for, and it had to be sent back.

Struck me as odd then, and still now. I believe it was a refurb and something akin to what you are mentioning is the situation. Otherwise, why would only a drive that was received from an RMA return the only drive that they did not have a flasher for(or at least one they are willing to release)?

[bulanula]

Pure random writes on the entire space would be torture, not real life usage.

Maybe, but isn't this the purpose of this whole testing ? It is not really "real life usage" because you are not giving the NAND time to recover as would happen in real life ( people do turn off their computers at some point or another ). Maybe we should test just some using 4K writing to full span of the drive ?

[Anvil]

I'm having some issues on the Kingston drive, it is dropped by the MB, just like earlier this summer.
(there were no errors on the drive, I've been suspecting issues with the MB though)

I'll move it to one of the Intel rigs and let the Corsair run on this rig, for a few hours that is.

The Corsair is still doing fine.

E6 100
E7 0
E9 5930
F1 7927

106.74 MiB/s on avg. (~15.5 hours)

So, it's closing on 8TiB host writes.

edit:

The Kingston V40 has had no issues since I moved it to one of the Intels, will have to find out if there is something going on with the workload on the AMD board, cooling should be OK and so I'm not sure what it could be.
(will check the temps though)

[sergiu]

Maybe, but isn't this the purpose of this whole testing ? It is not really "real life usage" because you are not giving the NAND time to recover as would happen in real life ( people do turn off their computers at some point or another ). Maybe we should test just some using 4K writing to full span of the drive ?

Personally, I would prefer a real life test over the the torture one because there is no real life scenario for something like this, not even close, but your point is right, a full span 4K would be interesting, from multiple points of view like WA, endurance, impact of smaller recovery time, wear level algorithm, etc.

Out of curiosity, I did some calculations see what Intel expects from its drives compared to theoretical results for 160GB G2 model. For those interest, here are details:
NAND geometry: 34nm cells, 4K page 128pages/block =>
- Usable: ~39,07MPages ~305,25KBlocks
- Spare: ~2,880MPages ~22,50KBlocks
Worst case scenario: drive is completely full and truly random 4K write requests are issued continuously. Because free pages will be scattered around entire drive, best strategy would be to postpone block erasing as much as possible and use spare area. After spare area is full, if writes were completely random there should be ~2,880MPages free scattered around 327,75KBlocks (usable + spare). This translates into an average of 8,78 pages free in each block. Now erasing is inevitable, and each block cleared needs to be filled again with the valid pages that were not yet erased. This will translate in a WA = 128/8,78 = 14.57. Now, 160GB*5000 cycles = 800TB => Intel expects a WA of 800/15 = 53.33 which is much higher than the theoretical ideal one.
With this kind of scenario, most probably the write speed would be low enough to allow some recovery, so I would bet we could see at least 50-100TB written
The theoretical WA should be the same also for G3 model IF internally 8K pages are split in two 4K logical ones. For this model we have 160GB*3000 cycles = 480TB => Expected WA = 480/15 = 32 < 53.33 for G2. This comes naturally from algorithm improvements or maybe more computing power available to scan the list of blocks for most suitable erase candidate.

[Anvil]

It's been 24 hours since I started the Corsair test and it's still doing just fine.

Corsair Force 3 SSD ATA Device_120GB_1GB-20110918-1843.png

CDI_2011-09-18-18-44.PNG SSDLife-2011-09-18-18-44.png

[johnw]

I'm surprised the 120GB F3 is not writing faster. It is about the same speed, or a little slower, than the 64GB Samsung 470.

Could it be partially throttled?

[Anvil]

Depends on what you put into "partially throttled", I'd call it steady-state.

In fact the speed is on par with my initial tests (early September)
I expect the synchronous NAND version (GT) would yield better overall performance.
I might do a short test on my GT just to confirm.

[johnw]

I expect the synchronous NAND version (GT) would yield better overall performance.
I might do a short test on my GT just to confirm.

Yes, good point. I forgot that the non-GT had async flash. That would definitely account for rather slow write performance.

[Christopher]

And the Corsair's average is being generated with a dedupe friendly workload.

Not to mention the fact that it's also the 120GB version, which makes sense, as with 25nm async NAND you are looking at the same number of channels populated as a 60 with 34nm.

I'm a little worried that the Mushkin won't be much faster even if is a 60 with 32nm toggle NAND.

[Christopher]

I have a vertex that i received from a RMA situation. It 'panic locked' and could only be broken free of this by means of using a firmware flasher that isn't generally released unless you have a specific problem.
However, these panic-release flashers are released regularly to people with problems, they talk about them all the time in the vertex area of their forums. Only given via pm or email whatever with support.
So they sent me a few of these flashers, as they match up to certain configurations with the type of nand on the vertex series, as there has been a few versions over the years.
When none of the versions worked on my drive, they happened to ask me directly if the drive was received from an RMA> when i told them that it had in fact been an return from a RMA drive, they informed me that drive there wasnt a flasher for, and it had to be sent back.

Struck me as odd then, and still now. I believe it was a refurb and something akin to what you are mentioning is the situation. Otherwise, why would only a drive that was received from an RMA return the only drive that they did not have a flasher for(or at least one they are willing to release)?

I ran identify on both the drives, and the new Agility is 2x32 Intel 34nm 661302, the the 120 Turbo is 081102, which is Samsung NAND - I don't even remember if they hand out D flashes for drives with Samsung NAND. You said some (all?) of your drives were Turbo FW capable, right? Maybe that was someone else with 8 Vertex drives that I thought was you on the OCZ forums...

I'm not saying that's what they did, just that they could have. It's different to get a drive from RMA which may be used (because somewhere, in the fine print, they make this fact known), but it's another thing entirely to sell as new drive which may be used. When you do that, it's called REFURBISHED.


I'm still happy with the purchases... sequentially speaking, the Turbo 120 does 270mb/s reads and 210mb/s writes. It's sole weakness is of course 4k randoms, but is still compares pretty well for an old design.

[Anvil]

And the Corsair's average is being generated with a dedupe friendly workload.
Not to mention the fact that it's also the 120GB version, which makes sense, as with 25nm async NAND you are looking at the same number of channels populated as a 60 with 34nm.
I'm a little worried that the Mushkin won't be much faster even if is a 60 with 32nm toggle NAND.

The block size and the compression has proven not to be dedup friendly on the SF controller, meaning there is next to no de-duplication done. (Vapor performed the test some time ago)
The 60GB will most likely have RAISE disabled, just like the other 60GB SF2 based drives.

Lets hope it's a bit faster than the sync/async ones.
The low capacity SF based drives have always been noticeably slower than their higher capacity siblings and so the toggle mode drive could be really interesting.
Don't get your hopes up too high though , compared to the "kamikaze-like" Samsung 470 drives I'm afraid most other drives are slow. (for this test pattern)

--

Running on my Z68, will have to move it later tonight, will try to get another Z68 ready tonight for both drives.

CDI_2011-09-18-20-59.PNG

[Christopher]

Anvil, I don't really know what to expect. It's not like there are any reviews floating around out there. I wasn't even sure the 60GB Mushkin was for real, which is why I didn't really want to say what it was before I got some hard confirmation that it indeed exists. I figure it's somewhere between a 120 async and a 120 sync, but even that may be far too optimistic. I think it would be a killer drive for many applications, maybe just not this one. The only reason I got the 60GB over the 120GB version is that I was expecting higher sustained writes vs capacity. A 120GB mushkin chronos deluxe is still a great deal cheaper than the 510 at 120 GB, and the 60GB is comparatively not such a good buy. We'll see on Tuesday. Also, this gives me a chance to see if the SF 2281 BSoD bug is as rare as they say it is. There's now one in the test, and you own a GT as well. You've never seen the bug, right? SF and OCZ say that you must use a SATA bus probe to get the diagnostic data you need, but that putting the analyzer in the chain actually stops the BSoD from happening.

Kamikaze is the right word for the Samsungs, writing themselves to death with little regard for the future. I kinda like that -- Imagine that philosophy but with Sata III speeds. You'd be murdering the drive at like 400MB/s.

I expect the Samsung 800 series to really shake up the standings among drive performance. They're out now for Dell's Precision laptop line, but should be a while longer for retail availability. Intel's claiming they'll have the fastest drives on the market in the 4th quarter, but I'll believe it when I see it (not the speed, but actual release in the 4th quarter -- that would be surprising).