Sandforce Life Time Throttling

[therat]

This may sound like a total newbie question (but them i am new to SSDs) but is there a simple way to test if an SSD has RAISE enabled or disabled like there is with TRIM?

[Ao1]

I think I get it now. With RAISE enabled you will see less useable capacity.

For example a 60GB drive with RAISE will show 51.24GB user capacity. Without RAISE it will show 55.90GB

To use Tony's post on the "Info regarding 64Gbit drives that did not meet IDEMA specifications." thread over at the OCZ forum

• 120x0.93= 111.6 Windows formatted GiB capacity
• if your 120 formats to less than 111.6, this post applies.
• so 60x0.93 = 55.8 Windows formatted GiB capacity
• if your 60 formats to less than this, this post applies
• so 80x0.93 = 74.4 Windows formatted GiB

Substitute "this post applies" with "you have RAISE"

[therat]

So all the new 32Gb Die Size SSDs have no RAISE but the old 64Gb die size do

[Ao1]

No. 32Gb is only now used for SLC based solutions. Package densities for MLC are 64, 126, 256 & 512.

As far as I can see if the difference between NAND capacity (excluding ECC) and formatted space is > than 12.7% you have RAISE if it is = to 12.7% you don't.

My V3 uses 64Gb density NAND and the formatted capaity = 55.9GB = 12.7% difference, so I assume I don't have RAISE.

SF vendors should explain why RAISE is not used on some models and confirm how to tell if it has or hasn't been applied.

[johnw]

There is something weird here. The most common overprovisioning amount is about 7%, since 1024^3 / 1000^3 = 1.0737, so without parity, 128GiB of flash gives you about 128GB of capacity after subtracting 7.37% OP.

But you are saying that if there is 12.7% difference between flash on board and usable capacity in Sandforce SSDs, then there is no RAISE.

If that is true, then I can only conclude that most Sandforce drives are using 12.7% over provisioning. Which is odd, since Crucial and Intel both tend to use only 7% overprovisioning. I guess Sandforce just does not perform well with only 7%, so they need 12.7% ?

I agree that whether RAISE is present or not needs to be well-documented. It is false advertising for Sandforce to claim all these great bit error rates with RAISE when a lot of Sandforce SSDs do not even have RAISE.

[bluestang]

Normally from what was observed E9 records real flash writes while EA/F1 records host writes. The increment is indeed in 64GiB. Now I believe the relation with the doubling is more a coincidence of the moment. The numbers are strange because judging from first reading, the WA was around 2.1 while in between decreased to 1.5. It is strange because normal data is compressible up to one point so WA is usually below 1. Could you check if you have ntfs last access update enabled or not: http://www.pctools.com/guides/registry/detail/50/ ? This is a source of small writes. Not sure how would translate in real world data, but I guess it would translate into higher WA because the metadata update would probably be as small as one sector while real data written would be at least one flash page. Also, could you do some zero fill testing? I'm interested to see if your drive has the same compression rate as Vapor's drive.

My "NtfsDisableLastAccessUpdate" is set to "1"

Zero-Fill testing using Anvil's App? How many runs and at what test size? Since it needs to be at least 64GiB of total write for it to increment right?

[Ao1]

OCZ don't claim to use RAISE. SF make a big issue out of it and reviewers pick it up as a feature when they write reviews, but that does not mean that it is being deployed.

If you look at OCZ's web site/ product lit it does not mention anywhere that RAISE/ DuraWrite or DuraClass are features of their SSD's. It is easy to make an assumption that they are after you read a web site review, but it's not always the case.

[Vapor]

It is on my to-do list, can't promise anything yet though.

It can be done using a standard batch file.

In it's simplest form one can

xcopy drive:\sourcefolder drive:\destinationfolder /E/V/C/Y
rmdir drive:\destinationfoler /s/q

those commands are from the top of my head and should be tested/verified

then just duplicate to get 100 operations and save to a batch file...

Thanks

I'll try that....any timer delay needed between the 100 duplicates (will it just try to copy it 100 times at once?).

I found a quote from SandForce that skims over compression and talks about the importance of RAISE.

Interestingly it appears that RAISE has been DISABLED on most of the SF2xxx client based offerings.

"In the recent article by David Rosenthal he mentions a conversation with Kirk McKusik and the ZFS team at Sun Microsystems (Oracle). That conversation explains why it is critical that meta data not be lost or corrupted. He goes on to say that “If the stored metadata gets corrupted, the corruption will apply to all copies, so recovery is impossible.”

SandForce employs a feature called DuraWrite which enables flash memory to last longer through innovative patent pending techniques. Although SandForce has not disclosed the specific operation of DuraWrite and its 100% lossless write reduction techniques, the concept of deduplication, compression, and data differencing is certainly related. Through all the years of development and OEM testing with our SSD manufacturers and top tier storage users, there has not been a single reported failure of the DuraWrite engine. There is no more likelihood of DuraWrite loosing data than if it was not present.

We completely agree that any loss of metadata is likely to corrupt access to the underlying data. That is why SandForce created RAISE (Redundant Array of Independent Silicon Elements) and includes it on every SSD that uses a SandForce SSD Processor. All storage devices include ECC protection to minimize the potential that a bit can be lost and corrupt data. Not only do SandForce SSD Processors employ ECC protection enabling an UBER (Uncorrectable Bit Error Rate) of greater than 10^-17, if the ECC engine is unable to correct the bit error RAISE will step in to correct a complete failure of an entire sector, page, or block.

This combination of ECC and RAISE protection provides a resulting UBER of 10^-29 virtually eliminates the probabilities of data corruption. This combined protection is much higher than any other currently shipping SSD or HDD solution we know about. The fact that ZFS stores up to three copies of the metadata and optionally can replicate user data is not an issue. All data stored on a SandForce Driven SSD is viewed critical and protected with the highest level of certainty."

http://storagemojo.com/2011/06/27/de...of-good-thing/

I wonder how much dedup is actually happening...it does not seem as if a file written many times is only stored once. It doesn't seem like SF's dedup ability has much macro effectiveness at all, actually.

Don't know which vendors do or don't. They will have to answer that as it is not possible to determine if RAISE is activated by looking at the NAND capacity. The larger capacity drives (240GB) in general have RAISE the smaller ones don't.

Here are a couple of examples:

SF = 8 channels

OCZ V3 120GB (WITHOUT RAISE)
64Gb LU = 69,120Mb / 8.4375GiB
16 x 8.4375 = 135GiB (Including ECC)
16 x 8 = 128GiB (Excluding ECC)
Formatted capacity = 111.79GiB
Difference between capacity (excluding ECC) and formatted = 16.21GiB /12.7%

OCZ V3 240GB (WITH RAISE)
128Gb LU = 138.24Mb / 16.875GiB
16 x 16.875 = 270GiB (Including ECC)
16 x 16 = 256GiB (Excluding ECC)
Formatted capacity = 223.58GiB
Difference between capacity (excluding ECC) and formatted = 32.42GiB /12.7%

Omitting RAISE does not reduce the amount of NAND being used (at least as far as I can see).

So why do it? To devote more OP to help performance at the expense of reliability?

I don't know the answer.

There seem to be seven main SF-2200 configurations on the market right now, can you elaborate on the RAISE status of each of them?

60GB IMFT 25nm -
120GB IMFT 25nm - No (based on what you posted)
240GB IMFT 25nm - Yes (based on what you posted)
480GB IMFT 25nm -
120GB Toshiba Toggle NAND 32nm -
240GB Toshiba Toggle NAND 32nm -
480GB Toshiba Toggle NAND 32nm (SF-2282) -

There are surely sub-configurations with NAND layout, those don't have any impact on RAISE, right? (that would muddy the waters an awful lot)

I don't understand why SF/vendors would not include RAISE on 25nm devices when they did with 34nm SF-1200 devices. I hope there's a good reason

There is something weird here. The most common overprovisioning amount is about 7%, since 1024^3 / 1000^3 = 1.0737, so without parity, 128GiB of flash gives you about 128GB of capacity after subtracting 7.37% OP.

But you are saying that if there is 12.7% difference between flash on board and usable capacity in Sandforce SSDs, then there is no RAISE.

If that is true, then I can only conclude that most Sandforce drives are using 12.7% over provisioning. Which is odd, since Crucial and Intel both tend to use only 7% overprovisioning. I guess Sandforce is just does not perform well with only 7%, so they need 12.7% ?

Yeah, that is very weird. What makes it weirder is the 240GB and 120GB Ao1 show both have 12.7% OP....but only the larger has RAISE.

Could it be they need a percentage OP for RAISE and a non-percentage OP for wear leveling/performance? What if they, practically speaking, are interface limited such that they never need more than xGiB of OP for wear leveling/performance, and that allows RAISE to be enabled with 240GB devices? With the initial SF-1200 25nm devices, they were 55GB and 115GB, not the 55GB and 110GB that would have been a more logical pairing based on just % OP requirements.

Say they need 9% OP for RAISE with 25nm (all numbers are hypothetical) and a minimum of 6GiB of OP for wear-leveling/performance. 9% OP for RAISE leaves 3.7% for wear leveling/performance. With 128GiB of NAND, 3.7% is 4.735GiB but with 256GiB of NAND, that's 9.47GiB. 4.735GiB doesn't meet the requirement (6GiB), so they just give all the OP to wear-leveling/performance.

I don't know the performance numbers of SF drives without enough OP for wear-leveling/performance, but I still think I'd prefer RAISE to be present on all devices.

EDIT: RAISE could have the fixed (GiB) OP while wear-leveling/perf could be %, point/question still stands, I think.

[johnw]

Here is my understanding of Sandforce capacities and RAISE. I could be wrong, but this is what I thought before reading the recent posts.

First, I should say that I do not like to refer to any flash used for parity or RAISE as overprovisioning. I only like to use the term overprovisioning for flash that is used for normal data in excess of usable capacity. I consider parity flash to be something different than overprovisioned flash.

Okay, so my understanding was that most Sandforce SSDs that are not a nice power of 2 would have RAISE. So, 60GB, 120GB, 240GB would have RAISE. They would also have about 7% OP. So the 60GB model would have 64GiB of flash, 4GiB would be reserved for RAISE, and the remaining 60GiB allows for 7.37% OP and 60GB usable capacity.

In contrast, 64GB, 128GB, and 256GB models would not have RAISE. For example, the 64GB model would have 64GiB of flash, and 7.37% OP, yielding 64GB usable capacity.

Now, that is just what I have assumed for a while now. I could be wrong.

[Vapor]

That makes sense and I think that was true for 34nm

Remember the initial 25nm drives though? They had more OP as they were only 55GB and 115GB out of 64GiB and 128GiB. So did space required (percentage or non-percentage, doesn't matter) for RAISE increase with 25nm? That was what we were told at first, IIRC.

Then 60GB and 120GB 25nm SF-1200 came out after complaints over IDEMA. Do those have the original (34nm) RAISE OP or no RAISE at all? I think if we knew that, it might help figure out what's going on with SF-2200 and RAISE.

I think it comes down to 25nm needing more RAISE OP and 60GB and 120GB varieties don't have enough OP (in terms of a fixed GiB + minimum %) for expanded RAISE and ensuring normal wear-leveling/performance. If that's the case, I'm not a fan of that decision....I think I'd rather have reduced wear-leveling/performance capabilities and be able to regain it by choosing to have a smaller partition size.

[sergiu]

My "NtfsDisableLastAccessUpdate" is set to "1"

Zero-Fill testing using Anvil's App? How many runs and at what test size? Since it needs to be at least 64GiB of total write for it to increment right?

Yes, Anvil's App would be ok. The test size does not matter too much as it will be 0fill. You would need to configure it to write continuously until you see at least 4 increments for E9. If it has a compression rate of 25% like Vapor's SSD you will see 4 increments for 1TB written, otherwise you will see 4 at 2TB.

Also, today I had access to a OCZ Vertex 3 120GB and SMART parameters were E9=129 and F1=105 => WA= 1.22. The drive had OS installed and was used for a database, a load which does not translate into many flash writes so the value is definetly higher than usual. Also, on a Vertex 3 240GB which is used for some VMs, the parameters are now E9=411 and F1=588 => WA= 0.69. My guess is that this "doubling" effect has something to do with drive's size, because both models have firmware version 2.06.

[Ao1]

I've just taken my V3 60GB drive apart. SF controller 2281. Intel NAND 29F64G08ACME2
RAISE is disabled

Will try to make a decoder.

Bluestang/ Vapor.
Most likely the f/w is reporting writes incorrectly, but out of interest are your drives set to enable Windows write caching?

[johnw]

I've just taken my V3 60GB drive apart. SF controller 2281. Intel NAND 29F64G08ACME2
RAISE is disabled

What is the usable capacity of your SSD in GB? Is it 60GB? (Note that Windows will display in GiB even though it is labeled GB, you can get an accurate display by doing "properties" on the drive, then windows will list the exact byte count)

[Vapor]

What is the usable capacity of your SSD in GB? Is it 60GB? (Note that Windows will display in GiB even though it is labeled GB, you can get an accurate display by doing "properties" on the drive, then windows will list the exact byte count)

An AS-SSD screenshot he posted says 55.9GiB usable capacity.

@Ao1, Windows write caching is enabled (and the 2nd box is unchecked).

[Ao1]

If I was correct in my earlier posts I would see less capacity if RAISE had been endabled.

[johnw]

An AS-SSD screenshot he posted says 55.9GiB usable capacity.

Ok, thanks. So that is 60GB of usable capacity, same as advertised. So the next question is how much flash is there on board.

Are all 8 of the flash chips on board 64Gibit? Or is one of them larger? If they are all the same (and there are eight of them), then you have 64GiB of flash on board.

[johnw]

If I was correct in my earlier posts I would see less capacity if RAISE had been endabled.

I don't see how you can conclude any such thing. If there is 64GiB of flash on board, and the usable capacity is 60GB (as your screenshot shows, technically 60.019437568GB), then we have one of two situations:

1) 60GB usable + 7.37% OP + 4GiB RAISE = 60GiB + 4GiB = 64GiB of flash on board

2) 60GB usable + 14.5% OP = 64GiB of flash on board

I do not see any way to determine whether you have situation 1) RAISE enabled or 2) RAISE disabled, from the information that you have provided in this thread.

[Ao1]

Here is a screen shot from the OCZ thread "Info regarding 64Gbit drives that did not meet IDEMA specifications."

V2 with RAISE. 64Gb NAND/ same RAW capacity as my V3 drive.

[Anvil]

Did you guys read Anands Preview on V3?

Link

RAISE was discussed in that article and it is as such not "news".

Quote from Anand:
"With the SF-2100/2200, SandForce allows the manufacturer to disable RAISE entirely. At that point you're left with the new 55-bit BCH ECC engine to do any error correcting. According to SandForce the new BCH ECC engine is sufficient for dealing with errors you'd see on 25nm NAND and RAISE isn't necessary for desktop workloads. Drive makers are currently contemplating what to do with RAISE but as of now the Vertex 3 is set to ship with it enabled. The drive we have here today has 256GB of NAND, it'll be advertised as a 240GB drive and appear as a 223.5GB drive in Windows."

It may just have gone under the radar and from what I can recall there has been very little on RAISE lately.

[bluestang]

Bluestang/ Vapor.
Most likely the f/w is reporting writes incorrectly, but out of interest are your drives set to enable Windows write caching?

[johnw]

Yes, when OCZ tried to trick everyone by selling 54.9GB drives advertised as 60GB drives, those did have RAISE enabled. But I think that was too dishonest even for OCZ, and they stopped doing that.

Nevertheless, that is still not enough information to determine whether the additional capacity is used for more OP, or for RAISE.

I think that one addtional piece of information will let us determine whether RAISE is enabled on a 60GB SSD. The additional information is that, with 25nm IMFT flash (Intel or Micron), the minimum size that RAISE can use is 8GiB. With 64GiB of flash on board, 60GB usable capacity, and 7.37% OP, there is only 4GiB of flash left over. That is not enough for RAISE with 25nm IMFT flash, so we can guess that the extra 4GiB was used to increase OP from 7.37% to 14.5%. Which is weird. I would have expected them to instead keep OP at 7.37% and raise the usable capacity to 64GB. But maybe Sandforce is just inefficient, and to get enough speed, OCZ thought it was better to use 14.5% OP?

All of this goes out the window for 120GB or 240GB SSDs. For the larger SSDs, there is enough flash on board to devote 8GiB (or 16GiB for 240GB SSD) to RAISE. Therefore you cannot tell whether you have a drive with 7.37% OP and RAISE enabled, or a drive with 14.5% OP and RAISE disabled.

That should really be documented in the SSD datasheet for each model, whether RAISE is enabled or disabled.

[johnw]

RAISE was discussed in that article and it is as such not "news".

Of course it is news which models have RAISE enabled or disabled. Yes, I read that article when it came out. Please point me to the passage where it says which models of Vertex 3 have RAISE enabled and which have it disabled. I don't think it is there. The 240GB drive does have RAISE, the article says. But it says nothing about the 60GB drive. I'd be willing to bet you that the 60GB V3 does NOT have RAISE. Will you take the bet?

[Ao1]

.......as of now the Vertex 3 is set to ship with it enabled.

I had read that, but it states that the intent was to ship the V3 with RAISE enabled. Bit and block protection are two different things. If the new 55-bit BCH ECC is so great why is RAISE used on some drives and not others? Is RAISE not more critical with 2x nm? Why do SF make such a big thing about RAISE if it serves no useful purpose?

Maybe it doesn't, but there is a total lack of transparency about what is going on.

[Anvil]

The article does not tell if they are going to ship with RAISE, just that it is now an option and it speculates on the 240GB drive will ship w/RAISE.

There is no mention of RAISE in the datasheets, so, it could be that none of the drives are configured with RAISE. (all "extra" space could be OP)

I'd still say that it's not news (as it was discussed in that article 5 months ago) but no one has really picked up that it might have been disabled for "desktop" drives.
I'll have a look at the other manufacturers datasheets just to see if anyone makes a note about it.

[johnw]

I'd still say that it's not news (as it was discussed in that article 5 months ago) but no one has really picked up that it might have been disabled for "desktop" drives.

That is just semantics.

Whether RAISE is enabled or disabled on particular SSD models is useful information, and it is not widely known at this time. Therefore it is indeed "news" by any reasonable definition of the term.