Sandforce Life Time Throttling

[Vapor]

I just want to clarify on something there will surely be questions about. Yes, groberts101 has been banned for his general conduct in the Storage section; the ban is medium length.

How things are said are important in terms of getting your point across effectively but also in terms of staying within the rules so that one can continue to post here.

Thankfully everyone else kept their cool here

[johnw]

I just want to clarify on something there will surely be questions about. Yes, groberts101 has been banned for his general conduct in the Storage section; the ban is medium length.

Doh! Now we can't try to convince him to use one of his 8000 hour SSDs in an endurance test!

[Ao1]

Hi sergiu,

OK I've just started running Anvils app with no trim after a SE.

In the first loop the MB/s speed is noticably faster. I'm getting around 60MB/s compared to around 45MB/s without TRIM. The blocks are of course clean at the moment so I doubt it will last.

[Ao1]

Here is the end of the first loop. The V2 was significantly faster without TRIM.

[Ao1]

Here is the 2nd loop. Still faster without TRIM. (No TRIM hang either, which makes it faster still)

[Ao1]

1 hour in. Anvils app is becoming unresponsive. I don't think life time throttling has kicked in yet.

[Ao1]

Nearly 2 hours in. Anvils app becomes periodically unresponsive for a few seconds and then it starts to respond.

I've got to go out and do some work now, so I'll have to leave it running and report back when I get back. (3 to 4 hours)

[Ao1]

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.

[Ao1]

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.

[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]

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.

[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]

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.

[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...

[Ao1]

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

Thanks for posting. Lifetime writes < write to NAND

[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.

[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

[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

[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?