Sandforce Life Time Throttling

[Vapor]

Hi Vapor, any chance of posting your #233 (E9) and #242 (F1) stats and power on hours? Have your drives always been in raid 0? What stripe size? It would be interesting to see how the #233 & #242 values compare between drives.

They have not always been in RAID 0. When I first got them I tested single vs. RAID, so one V2 has noticeably more wore wear. I use a 32KB stripe.

Anyway, here's the info:



Seems compression/write-amp levels are similar-ish (what with the low resolution and uneven usage), though you bring up a really good question: does RAID (except R1) compromise some of the compression ability.

[Ao1]

Try to keep in mind that life throttling is an optional feature, albeit an idiotic one.....

Specifying a workload is a much better way to provide a warranty imo. Essentially that is what you get with Intel. Intel give a duration based warranty, but they also stipulate the workload that the warranty duration is based on. (Both Client and Enterprise) If you exceed the workload and burn out the NAND before the warranty expired, I'd guess you would have no warranty.

The downside for vendor's is that they would have to check all RMA's to verify the workload = time/ cost/ money, still it's surprising that none of the small vendors have started to sell un-throttled drives.

The other issue I guess is that it would not look good for an immerging technology if people started reporting their NAND had burnt out "prematurely".

[Ao1]

They have not always been in RAID 0. When I first got them I tested single vs. RAID, so one V2 has noticeably more wore wear. I use a 32KB stripe.

Anyway, here's the info:

Seems compression/write-amp levels are similar-ish (what with the low resolution and uneven usage), though you bring up a really good question: does RAID (except R1) compromise some of the compression ability.

Thanks for posting The difference between #233 & #241 are quite low on both drives, so it does not appear that much of your work load could be compressed.

It would be great if more people could post their SMART values for these attributes to get a better picture.

[Anvil]

I wonder if this could be related to fixes in the firmware, meaning that early firmwares might not implement this feature properly, just speculating.

Most of my drives have a rather large difference between 233 and 241, I just had a look at one that has been sitting in my laptop (E6400) and it had just 313 hours.

E9 384
F1 1024
F2 2624

[bluestang]

It would be great if more people could post their SMART values for these attributes to get a better picture.

My V2 60GB...hope it helps...

[Vapor]

Thanks for posting The difference between #233 & #241 are quite low on both drives, so it does not appear that much of your work load could be compressed.

It would be great if more people could post their SMART values for these attributes to get a better picture.

Yeah, I was surprised at the low differences compared to 'expected.' All that is on these drives is OS and applications, things that should be very compressible. All documents (from .doc to .jpg/RAW) are on a different SSD.

Part of the pagefile is on this R0 array (part of the pagefile is on the other SSD, too), but with 18GB of RAM I'm not sure how much either gets used (usually in the 8-13GB of RAM usage range). Firmware is 1.10 on both V2s.

I am curious why my write amplification (233 vs. 241) values are higher compared to others' values. Usage, firmware, and RAID are probably the three leading candidates in my mind, but I'd be surprised if it's my usage.

Seeing as I'm very far away from hitting a lifetime throttle state, I could run Anvil's app a few nights with the different compressibility levels and try to decode some of it.

EDIT:

My V2 60GB...hope it helps...

image snip

Whoa, looks like a write amplification of over 2x there...I'm wondering if different firmwares have broken reporting now.

[Ao1]

My V2 60GB...hope it helps...

Thanks for posting. Lifetime writes < write to NAND

[zads]

Weird, my last post didn't go through? Maybe I fell asleep last night before submitting it lol

I am still pondering on the reasoning why this warranty throttle even exists and why SF couldn't just warranty their SSDs based on the amount of data written to them (like Intel does it). Could it be there to prevent enterprise users from using the cheaper consumer SF drives instead of their expensive enterprise models?

Enterprise can be throttled too.
Only certain customers get unthrottled drives.
Its much easier to sell a warranty based on time than a warranty that will vary in time based on your workload.
Also much easier so you don't have to deal with RMA checking every MWI.

No, as I said in the other thread, all that is required is a SF drive that has around a year of power-on hours, but minimal writes. It will have built up a large gap between current writes and the warranty-throttle line, so it should be able to be written hundreds of TBs before warranty-throttle begins.

...
So, without a "throttling disabled" SF drive that's pretty much it for the Endurance test.

You could buy unthrottled drives through me but you would have to start again at MWI=100

...
The downside for vendor's is that they would have to check all RMA's to verify the workload = time/ cost/ money, still it's surprising that none of the small vendors have started to sell un-throttled drives.

The other issue I guess is that it would not look good for an immerging technology if people started reporting their NAND had burnt out "prematurely".

Right on the money. Sell unthrottled drives and those retail vendors will get 1 egg reviews on newegg "it died after only 1 month. I was only benchmarking it 24/7!!"

[Vapor]

Right on the money. Sell unthrottled drives and those retail vendors will get 1 egg reviews on newegg "it died after only 1 month. I was only benchmarking it 24/7!!"

Doesn't every non-SandForce drive have this 'problem' then? They seem to be getting on fine

[bluestang]

so Zads...Milpitas, CA...just how close exactly do you live/work to SandForce?

Edit: LOL, I figured out where you work. Do I get a prize!

[Ao1]

You could buy unthrottled drives through me but you would have to start again at MWI=100

Or you could post your test results

[Ao1]

@ bluestang

As you have not written that much is there a specific workload you could think of that might be generating the difference between lifetime and NAND writes?

Have you updated the f/w? How soon after you got the drive?

[bluestang]

@ bluestang

As you have not written that much is there a specific workload you could think of that might be generating the difference between lifetime and NAND writes?

Have you updated the f/w? How soon after you got the drive?

It's pretty much my boot drive with my OS (XP SP3) on it, programs, pagefile, temp internet files. "My Documents" folder is on a spinner along with all my other data and all my downloads get saved to the spinner as well. Since it's my work PC, our ERP program runs off the server but the client does get and store temp files locally on my C: drive which average around 50-100MB in size.

I initially received one of the drives with the 64Gbit die NAND (OCZSSD2-2VTXE60G) and I RMA'd it for a 32Gbit version (OCZSSD2-2VTX60G). I can't remember but I think it came with FW 1.32 and I update to 1.33 about 2 to 2 weeks later when it came out.

[Anvil]

You could buy unthrottled drives through me but you would have to start again at MWI=100

Let me think about that, could be interesting.

So, it would just slow down to whatever rate the controller is capable of handling?

[sergiu]

Looking at the run without TRIM Anvil's app generated 293.47GB of writes.

#233 started at 37,312 and ended at 37,696. Difference = 384GB. Even if you allow 64GB for the delayed reporting that still comes out at 320GB = 26GB more than what was written.

What you see is absolutely normal. If data cannot be compressed, write amplification is for sure greater than one. Based on earlier measurements in this thread, it looked like a 1.12 write amplification for incompressible data written with the application. I would also have another request if possible: do some pure random writes and look at SMART parameter before and after the test to see how write amplification is evolving with this kind of load. For the test, to be statistically correct, you would probably need to write at least 2-3TB of data, so probably you would need to keep it idle for a few days.

[Ao1]

1TB of 8% fill.

#233 at start = 37,696GB
#233 after 1TB 8% fill = 37,824GB
Difference = 128GB

#241 at start = 37,120GB
#241 after 1TB 0fill = 38,144GB
Difference = 1,024GB

@ sergiu, I'll run a 46% fill for 1TB and then I'll do 100% 4K random writes.

[sergiu]

1TB of 8% fill.

#233 at start = 37,696GB
#233 after 1TB 8% fill = 37,824GB
Difference = 128GB

#241 at start = 37,120GB
#241 after 1TB 0fill = 38,144GB
Difference = 1,024GB

@ sergiu, I'll run a 46% fill for 1TB and then I'll do 100% 4K random writes.

Could you repeat also the test with 8% compression, but writing 4TB of data? Technically the result gives us a 0.125 write amplification which is a little too good to be true considering that controller is theoretically also writing some data to assure a proper error correction. With 4TB written I believe we can approximate with a lower margin of error the write amplification.

@Anvil: Would be possible to modify your application to detect SMART parameter changes (something like pooling the drive every 30s)? You could then easily compute write amplification (with a good aproximation) on Sandforce based SSDs after first detected changes on 231 and 241 parameters.

[Ao1]

It's pretty much my boot drive with my OS (XP SP3) on it,

I wonder if XP has anything to do with it. No TRIM and a non 4K aware OS. Is your drive aligned?

[gojirasan]

You could buy unthrottled drives through me but you would have to start again at MWI=100

How about disabling the warranty throttle in Ao1's drive so that he can put it back in the endurance test?

[zads]

How about disabling the warranty throttle in Ao1's drive so that he can put it back in the endurance test?

I could but it poses a number of problems:
1. Such a thing would absolutely void your warranty (requires opening up the drive)
2. It would reset everything on the firmware (MWI would go back to 100 even though the flash has PE=1000 or whatever, so you would hit PE=3000 at MWI=33 or something)
3. You're not really supposed to do it and so even if I did do it,
4. I would have to kill all of you to get rid of the evidence and,
5. I don't want to go back to jail.
6. Such a thing would only be discussed through private communication.

[bluestang]

I wonder if XP has anything to do with it. No TRIM and a non 4K aware OS. Is your drive aligned?

Aligned with Paragon Alignment Tool to 2048k. I also do an overnite idle about every week or 2.

[zads]

Oops.. I just realized even my own drive is in a firmware test state right now lol

[Ao1]

Could you repeat also the test with 8% compression, but writing 4TB of data?

Got cut short, so only 2.79GB

2.79TB of 8% fill.

#233 at start = 37,696GB
#233 after 2.79TB 8% fill = 38,144GB
Difference = 448GB

#241 at start = 37,120GB
#241 after 2.79TB 0fill = 40,000GB
Difference = 2,880GB

[Ao1]

As throttling is based on #233 it was possible to write at close to full speed for 0fill.

With 8% fill the drive started off at ~120MB/s, but went down to ~45MB/s when the drive went back into a throttled state. Non compressible throttled write speeds are ~6MB/s

For the 46% fill the drive is at ~10MB/s, 4MB/s above the throttled speed state of ~6MB/s.

Those write speeds, referenced to the MB/s speeds above the throttled state, should be able to verify Anvil's assumptions of % fill that he based on zip files, against the compression that the SF controller can achieve.

[sergiu]

Aligned with Paragon Alignment Tool to 2048k. I also do an overnite idle about every week or 2.

Could you also check manually if partition is aligned? You need to look at sector offset with a tool like Active@ Partition Manager