Sandforce Life Time Throttling

[Anvil]

It's hard to tell if something is quicker without the stopwatch
It's probably not much though, if anything at all.

I reinstalled the OS (W7) on one of my bench-pc's and ~6GB writes is very close to what I found as well so the data looks fine.

Using my benchmark one can easily observe that the different compression ratios results in different scores, but as I've said, there's not much difference between incompressible and 67% and not much between 67% and 46% either. It does depend on NAND and capacity though.

Guess it's time to create that Benchmark thread so that more people can make some input on the various SF drives.

[Ao1]

Guess it's time to create that Benchmark thread so that more people can make some input on the various SF drives.

Nice

My Windows install was Home Premium. No updates etc, just a basic install. MS Office 2007 Enterprise Edition - standard install.

Outside of installs and benchmarks I need to be pursued that compression works in even a minor way. [for data I work with anyway]

The 233/241 ratio should be a good indication if a workload is using compression or not.

[sergiu]

A real life test that I would propose: copy openjdk 7 source code from: http://download.java.net/openjdk/jdk7/ , unzip it, do multiple copies to your ssd, then look how SMART parameters are evolving. The archive uncompressed has 273MiB but is reported to use 333MiB on disk. It is delivered in a 83MiB size but it is easily compressible using 7zip to 30-50MiB depending on settings.

[Anvil]

I checked as well before going online for updates, my W7 is the x64 Enterprise, should be very close in size anyways.

If your work files are mostly multimedia there won't be much compression at all.

In my case it's mostly OS and VM's containing OS's + apps + databases and they all compress.
I made a few checks when cleaning the drives and the results are pretty clear...

These two drives have been running 2R0 as a pair for, well basically 99% of the time and have been used as boot drives running 1-2 VM's for testing purposes.

cdi_1_2011_07_19.JPG cdi_2_2011_07_19.JPG

[Ao1]

I found an interesting article on SF compression here:

"For this article I took a consumer SSD that has a SandForce 1222 controller and ran some throughput tests against it using IOzone. IOzone enabled me to control the level of data compressibility, which IOzone calls dedupability, so I could test the impact on performance. I tested write and read performance as well as random read, random write, fwrite, and fread performance. I ran each test 10 times and reported the average and standard deviation.

The three write tests all exhibited the same general behavior. More specifically:
• As the level of compressibility decreases, the performance drops off fairly quickly.
• As the level of compressibility decreases, there is little variation in performance as the record size changes (over the record sizes tested).

The absolute values of the performance varied for each test, but for the general write test, the performance went from about 260 MB/s (close to the rated performance) at 98% data compression to about 97 MB/s at 2% data compression for a record size of 1 MB.

The three read tests also exhibited the same general behavior. Specifically,
•The performance drops only slightly with decreasing compressibility (dedupability)
•As the level of compressibility decreases, the performance for larger record sizes actually increases
•As the level of compressibility decreases, there is little performance variation between record sizes
Again, the absolute performance varies for each test, but the trends are the same. But basically, the real-time data compression does not affect the read performance as much as it does the write performance.

The important observation from these tests is that the performance does vary with data compressibility. I believe that SandForce took a number of applications from their target markets and studied the data quite closely and realized that it was pretty compressible and designed their algorithms for those data patterns. While SandForce hasn't stated which markets they are targeting I think to understand the potential performance impact for your data requires that you study your data. Remember that you're not studying the compressibility of the data file as a whole but rather the chunks of data that a SandForce controller SSD would encounter. So think small chunks of data."

[Ao1]

Just under 24hours and ~5.3TB. No reduction in the MWI or life curve, so I'm still within the credit zone.

AVG write speed = 65.17MB/s

[Computurd]

excellent find A01 IOzone looks very interesting as well.

I believe that SandForce took a number of applications from their target markets and studied the data quite closely and realized that it was pretty compressible and designed their algorithms for those data patterns.

this would make quite a bit of sense: like johnw says, and I agree, the SF being a low wattage proc it has to have a very rudimentary compression engine. If they did design their algorithms for certain patterns (tweaked it ) then that would help to explain why they pull off so much performance with such little power.

[Timur]

Good find!

I would like to see how much write throughput IOzone reports on a Vertex 3 or other current SF controller based SSD.

[Ao1]

E6 Life Curve Status

New: 00786400000064 (16 hex)
Current: 00626400000064 (16 hex)/ 0 25188 0 100 (Dec 2byte)/ 0 98 100 0 0 0 100 (Dec 1byte)

[Anvil]

Does it match 231?

[Ao1]

No. 231 it's still at 100%, which is impossible considering I'm nearly at 6TB. 98% is much more realistic.


EDIT and the OCZ Toolbox SMART value for 230 (E6) still reports 100. I think the raw value is Dec 1byte

[Anvil]

Strange, could it be due to the initial "credit"?

[Ao1]

That is my guess

EDIT: Let's say 2% of NAND PE = Credit. That means the remaining 98% is distributed across the 100% period of the life curve

[Timur]

Does the "credit" serve any purpose other than allowing shiny specs and fooling review sites who are not in the know?

[Anvil]

Let's see how it develops, if they start moving in "sync" then there is a connection.

[Eggcake]

Does the "credit" serve any purpose other than allowing shiny specs and fooling review sites who are not in the know?

Maybe also because the SSD would immediately reach the throttled state - the first thing a user does is install things and move things to the new SSD.

I'm really looking forward to the results, Ao1

[Timur]

Makes sense!

[Ao1]

E6 100%
E7 100%
E9 6,497

E6 raw values
00616400000064 (16 hex)
0 24932 0 100 (2byte)
0 97 100 0 0 0 100 (1byte)

[Ao1]

E6 100%
E7 100%
E9 6681

E6 raw values
00606400000064 (16 hex)
0 24676 0 100 (2byte)
0 96 100 0 0 0 100 (1byte)

Can anyone convert the raw value when new into 2byte & 1 byte values? 00786400000064 (16 hex)

[Vapor]

2byte:
0 30820 0 100

1byte:
0 120 100 0 0 0 100

If E6/230 has anything to do with LTT, you seem to have a loooong way to go until it kicks in

[Anvil]

78 = 120
64 = 100

7864 = 30820

You can just use the windows calculator, select Viev->Programmer and then enter the value in Hex mode, to convert to Dec just click on Dec.

[Ao1]

Thanks....maybe 100 is the base line. 120 was initial credit and now I am below the life curve at 96. If correct at some stage it will try to get back to 100. Bah, I wish the V2 had this attribute.

Although the PE cycles are not in theory supposed to go below the life line they clearly did with the V2 and it looks like it will be the same for V3.

May it will become clearer when the MWI gets to 99%

[Ao1]

E6 100%
E7 100%
E9 6829 GB

E6 raw values
0 95 100 0 0 0 100 (1byte)

[Ao1]

230 (E6) is supposed to show if the drive is operating under extreme conditions requiring protection measures to be activated.

I've just passed 8,154GB. MWI is still 100. 230 is showing as 100, but the raw value is showing 91.

SPECULATION

It could be nothing more than coincidence, but if you trend the raw value deduction against the data written so far you end up with ~35TB.

Then again once the credit PE cycles have run out maybe it all changes.

[Anvil]

Interesting, a great finding if that is the case!

Still running at 65MiB/s?