Did read it months ago, totally forgot about this. Very good news that there are some measures for dealing with 25nmOriginally Posted by Anvil
Still trying to figure out the puzzle of which have RAISE and which do not...I've been horribly misreading some of the info I've seen and now I think RAISE is enabled in most cases. I have no idea about the status of RAISE in the 60GB 25nm devices, however.
At least Sandforce and OCZ are consistent! They consistently fail to provide even minimal documentation about the basic functionality of their SSDs. I imagine next an OCZ rep will post blaming it all on Sandforce, and no doubt if we contact someone from Sandforce, they will say it is all OCZ's fault. Laurel and Hardy are back!
I searched a bit and found very few mentions on RAISE, Partiot does however list RAISE as a feature on both the 120GB and the 240GB drives in the WildFire series. Link
(they are both using Toggle mode NAND and iirc it was mentioned in one review that the WildFire had a different number of NANDs/dies vs other manufacturers)
Well, this will only lead to speculations but anyways, I'm not sure where I got it from but I'm pretty sure that I've read somewhere that the 60GB does not feature RAISE.
-
Hardware:
Here is my understanding. Could be wrong
Within a 64Gb Logical Unit there are 448 bytes per 8K page for ECC error control. This enables bit error correction. The 448 byes is unseen capacity. The 64Gb Logical unit therefore provides 8 GiB of capacity.
8 x 8 = 64GiB. My 60 GB drive has 64 GiB of NAND.
The only reason to see less capacity on a formatted drive is that some of that capacity has gone toward OP and or RAISE.
To repeat what SF state about RAISE on their web site:
"SSDs are built using flash die that are assembled up to 8 die per package. For optimum capacity the SSD can be assembled with up to 16 packages".
Now I'm not sure here but I think they are saying each Logical Unit consists of multiple dies.
They then state:
"If the failure rate (unrecoverable read error) of one MLC die is conservatively 1,000 PPM (a failure probability of 0.1%) then using the probability formula for 128 devices the failure rate increases to 12.0% over the life of the SSD.
Using RAISE technology in a SandForce Driven SSD reduces the probability of a single unrecoverable read error by 100 times to 0.001%. Applying that same formula, the failure rate of the SSD drops from 12.0% to a mere 0.13%, nearly 100 times lower."
So, if a die fails ECC is not going to help, but if you have RAISE it will.
If that is correct I fail to see why RAISE is not required, unless the amount of dies per device have been reduced for the SF2xxx drives. If not the risk remains as SandForce have calculated: i.e. the likelihood of a failure for the SSD is 12.0% without RAISE. (According to SF anyway)
Last edited by Ao1; 08-03-2011 at 11:46 AM.
In the Agility 3 article Anandtech shows most of the lineup from OCZ. Here is a screenshot
Link to the article.
1: AMD FX-8150-Sabertooth 990FX-8GB Corsair XMS3-C300 256GB-Gainward GTX 570-HX-750
2: Phenom II X6 1100T-Asus M4A89TD Pro/usb3-8GB Corsair Dominator-Gainward GTX 460SE/-X25-V 40GB-(Crucial m4 64GB /Intel X25-M G1 80GB/X25-E 64GB/Mtron 7025/Vertex 1 donated to endurance testing)
3: Asus U31JG - X25-M G2 160GB
Based on that, I think Anand has the same info, and the info says nothing about a 25nm 60GB drive.In the Agility 3 article Anandtech shows most of the lineup from OCZ. Here is a screenshot
Link to the article.
He says the Agility 3 with 64GB NAND has only 6.3% spare area, implying 59.97GiB of available NAND (or 64GB on the label), but the same table lists and the full population of drives out there have 55.8GiB of user capacity (60GB on the label), inline with 12.7% OP from the others in the product line.
There was a false alarm about the 120GB drives not having RAISE (all the 120GB/240GB drives on the market should have RAISE), but there's mixed signals about the status of RAISE with the 60GB drives. Documents only talk about 25nm 64GB drives...and they don't have RAISE (as shown in his table, 6.3% spare area means 64GB on the label). 25nm 60GB drives don't exist in the documents but that's all there is on the market.
I think the 60GB edition was launched after all the reviews at anandtech was published. OCZ homepage gives the spec but does not mention anything about RAISE.
1: AMD FX-8150-Sabertooth 990FX-8GB Corsair XMS3-C300 256GB-Gainward GTX 570-HX-750
2: Phenom II X6 1100T-Asus M4A89TD Pro/usb3-8GB Corsair Dominator-Gainward GTX 460SE/-X25-V 40GB-(Crucial m4 64GB /Intel X25-M G1 80GB/X25-E 64GB/Mtron 7025/Vertex 1 donated to endurance testing)
3: Asus U31JG - X25-M G2 160GB
It would be helpful if OCZ could make a clear statement to save any confusion. Tony?
Compression testing update
Still early in the C Volume testing for the SF-1200 (won't be done until tomorrow morning, it seems...big thanks to Anvil for the batch file idea), but it's tracking right with the SF-2200, which is good to see. Biggest difference is with 0-fill, which is kind of odd (though the testing of others has shown a WA below .14x for the SF-1200 with 0-fill too, maybe some low-level change that has little other impact?).
Two ways of looking at the data: 1) overall write amplification (WA), simply NAND writes divided by host writes and 2) compressed size, which is intended to show how well the controller can compress the data (independent of how well it writes the data). Compressed size takes the assumption that the compression algorithm can package incompressible data to 101% of its original size and that write amplification as a ratio (1.09# / 1.01) is constant across all sequential writes. Compressed size then takes the overall WA numbers from each setting and factors out the write amplification (WA * 1.01 / 1.09#).
I'm not sure what you mean by "logical unit", but each package (aka module) will typically have 1, 2, or 4 die. I suppose 8 die per package is possible, but it is not common.
Now, with 25nm IMFT flash, I believe the smallest available die size is 64Gibit = 8GiB.
RAISE apparently needs at least one full die devoted to parity. Which with 25nm IMFT flash, means RAISE needs at least 8GiB for parity.
So, for an SSD with only 64GiB of flash on board, if 8GiB were devoted to parity, that only leaves 56GiB = 60.13GB for data. If the drive is to have a usable capacity of 60GB, then that only leaves 0.13GB for OP, which is not nearly enough. Which is why I don't think there are any 60GB (or 64GB) Sandforce drives with 25nm IMFT flash that have RAISE.
On the other hand, 3Xnm flash is available with 4GiB die. So 3Xnm 60GB Sandforce SSD may have RAISE.
It is interesting to compare Sandforce RAISE with Intel's parity approach with the 320 series of SSDs. Every model of Intel 320, from 40GB up to 600GB, has parity, and they all use 25nm Intel flash. Since the smallest die size is 8GiB, they all devote at least 8GiB to parity. Unlike Sandforce, though, Intel just adds more flash. So the 40GB Intel 320 has 48GiB of flash on board (6 x 8GiB), with 8GiB for parity. The 80GB Intel 320 has 88GiB of flash (9 x 8GiB + 1 x 16GiB) with 8GiB for parity.
I wonder why the Sandforce drives do not take a similar approach. The 64GB drives might have used 7 x 8GiB + 1 x 16 GiB, so they could have 8GiB devoted to RAISE, leaving 64GiB for data, so they could have 7.37% OP and still have a usable capacity of 64GB. Maybe the Sandforce controller requires all packages to have the same flash capacity?
Last edited by johnw; 08-03-2011 at 02:42 PM.
That makes sense on a lot of levels (including why 25nm 64GiB with RAISE ends up being 55GB and why 25nm 128GiB with RAISE ends up being 115GB).
If that's the case, though, I don't understand why the 60GB drives aren't 64GB drives. What performance gains are there from those extra 4GB? (not that it helps, 25nm+60GB+SF-2200 seems awfully slow)
I cannot explain it, either. I agree with you that it would be more logical for the 64GiB SSDs without RAISE to have 64GB usable capacity.
That chart from Anandtech appears to be incorrect. You can't have a reduction in RAW to User Capacity of 12.7% and state it is all for OP. There would have to be a further reduction in user capacity to allow provision for RAISE, or it would have to be included in the OP.
The OP for the Agility 3 cannot be 6.3%. It is 12.7%. How can it be 6.3% whilst not having RAISE?
Ao1
You could send Anand an email, he might do an update on RAISE/OP. (unless OCZ or others comments on this)
-
Hardware:
^ DoneLets see what Lal comes back with. Hopefully it can be cleared up.
Well from an architecture standpoint, its much easier to implement. Sandforce also has some other data protection/error correction features as well that is easier to implement by having the same flash capacity on all channels.
Correct.
As in your case with your 60GB Vertex 2, its based on Hynix 32nm.
I don't know what flash they are building the 60GB SF-2000 in question, but with RAISE off having that extra overprovisioning amount helps with minimum performance levels when the drive is filled near maximum capacity.
"Red Dwarf", SFF gaming PC
Winner of the ASUS Xtreme Design Competition
Sponsors...ASUS, Swiftech, Intel, Samsung, G.Skill, Antec, Razer
Hardware..[Maximus III GENE, Core i7-860 @ 4.1Ghz, 4GB DDR3-2200, HD5870, 256GB SSD]
Water.......[Apogee XT CPU, MCW60-R2 GPU, 2x 240mm radiators, MCP350 pump]
C Volume and D Volume compression tests done on the SF-1200, looks to be no different in ability than the SF-2200
8% is in progress, then 8% ND, then 25% ND, then 46% ND...but if you ask me it's already apparent that there's no appreciable difference between SF-1200 and SF-2200 compression capabilities. 0-fill being the biggest difference between the two, but it's not a big difference (and 0-fill is also the least likely real world scenario).
Ao1 already answered that in this thread. He wrote:
"I've just taken my V3 60GB drive apart. SF controller 2281. Intel NAND 29F64G08ACME2"
Thank you for taking the time to run all of those tests. This is the first comprehensive data I have seen on the compression abilities of SF1200 and SF2281 controllers.
I'm not surprised to see that the two generations of controllers have about the same compression ability, but it is good that you measured it so that we know for certain.
My thanks also for the charts Vapor.It's hard to appreciate sometimes how much work goes into a chart like that. Please feel free to add it to the first post it you want to. (I'm going to tidy that first post up some time)
Here is a comparison between the V3 and the un-throttled V2 drive. Seems that even when DuraWrite is deactivated there is a still a credit period in terms of how much could be written before the first drop in the MWI and subsequent drops. The credit period is quite different though. ~8.5TB for the V3 vs ~5.5TB for the V2
It looks like the V2 (32nm Hynix) is writing a lot less vs the V3 (25nm Intel) per MWI drop, although there is not much data to go on so far.
Last edited by Ao1; 08-04-2011 at 11:50 AM. Reason: updated graph
+1My thanks also for the charts Vapor.
How did that batch file work?
-
Hardware:
In my database I have 6.1TiB of NAND writes as the last 100MWI data point
Though I have been logging the V2 more than posting (don't want to spam) because I can't predict when the V2 will have its MWI move. Differences are minor, overall. Once compression testing is done, my forum posts will match what goes into my database.
Though this is interesting, your V3 is almost behaving like it is programmed for 4000 cycles (Micron rates at 3000 and Intel at 5000 for NAND off the same production line, maybe that's why?) compared to my NAND's 3000 cycles.
@Anvil, needed a few tweaks but overall worked great, thanks for the idea and initial code
I took the value for 99 and then averaged out the MWI from 99 to 96. I then deducted that average from the write value at 99. I had to guess a bit from 99 to 96. No worries though. Chart changed.
I've wondered why Micron & Intel NAND would have different specs for P/E cycles. Maybe Intel bins to a higher standard. Don't know, its a bit strange.
Reply With Quote
Bookmarks