Sandforce Life Time Throttling

[Ao1]

233 = 8C00 = 35,840
241 = 8680 = 34,432
= ~1.04


Nice observation sergiu. With Anvils app I can write at a number of different compression levels so at some stage I will experiment to see how this plays into those SMART readings. If correct it would be really helpful for people to see how much compressible data they write vs non compressible.

[Ao1]

I wrote 29,032,448MB in 168 hours, which induced ~10% wear.

1% MWI = 2,903,245MB

Assume linear wear and the drive could have written 290,324,480MB (276TB) The X25-V & 320 are looking at around 200TB before they get a MWI of 1. The V2 is using 34nm Intel nand. If the drive had carried on writting in theory it would have been able to write more that the X25-V & 320.

Assume 3 year life time throttle (26,280 hours/ 276TB)

Spread 290,324,480MB over 3 years (26,280 hours )and assume 24/7 writing.
The max MB/s to write 290,324,480MB = 3.06MB/s or 11,016MB per hour (10.75GB per hour)

So if you write less than 10.75GB per "power on hour" you should be OK.

Let's say you write 258GB in one day however, but the power on hours are only 8. That reduces the amount you can write per day by one third = 86GB per day.

Assume 5 year life time throttle (43,800 hours/ 276TB)

Spread 290,324,480MB over 5 years (43,800 hours)and assume 24/7 writing.
The max MB/s to write 290,324,480MB = 1.84MB/s or 6,628MB per hour (6.47GB per hour)

So if you write less than 6.47GB per "power on hour" you should be OK.

Let's say you write 155GB in one day however, but the power on hours are only 8. That reduces the amount you can write per day by one third = 51GB per day.

I think that's right. It's still early in the morning though.

It also assumes non compressible data only, so compressible data would add to the writes per hour

[Anvil]

If 233 "E9" indicates "flash writes" it would be a great new supplement to what little we know

Here's my Agility 3 60GB, mostly used for testing my bench app and most writes are easily compressible, will do some more testing on that one.

cdi_233_241.PNG

Would indicate 0.42 which I'm finding to be very likely.

[Ao1]

If 233 "E9" indicates "flash writes" it would be a great new supplement to what little we know

It would be a great discovery It would mean that you can tell how much you are benefiting from compressible writes speeds without any guess work on how compressible a work load was.

Thinking a bit more about how throttling could be regulated.

Assume an un-throttled write speed of 270MB/s for non compressible data = 972,000MB per hour

It would take 298 hours @ 270MB/s to write 290,324,480MB

Assume an un-throttled write speed of 50MB/s for non compressible data = 180,000MB per hour

It would take 1,612 hours @ 50MB/s to write 290,324,480MB

In theory reduced nand cycles, combined with faster write speeds would reduce the writes per hour "allowance" for the V3, unless the V3 has enhanced write amplification.

[Anvil]

OK, I think we can confirm that 233 is a really interesting finding, thanks sergui

Heres what I did (and keep the ss that I posted above in mind, especially E9 and F1)

I wrote 2GB of incompressible data and both increased by 2, good start

cdi_233_241_plus_2GB_incompressble.PNG


I then shifted to writing 4GB files and this one is set for 25% compression (as in 25% of the original file size)
It should in theory write 1 GB but as we know very little about the SF drive we can't know for sure.
(and we don't know how much it compresses vs the 7zip files which these percentages are based on)

It changed by 2GB, could be some rounding that occurs so I might have to increase the file size

cdi_233_241_plus_4GB_25perc.PNG

Looking good so far

I then wrote a 4GB 8% file (as in 8% of the orginal file size)

cdi_233_241_plus_4GB_8perc.PNG

And finally

4GB of 0-Fill

cdi_233_241_plus_4GB_0Fill.PNG

I'd say this is confirmed...

[Ao1]

Nice one Anvil

So, it would be great if V2/ V3 owners could post their SMART values for those atributes, which would enable us to compare how compression works in real life workloads.

[sergiu]

FWIW, 8080 divided by 7C40 is 1.034x

8080 = 32896 GB, 7C40 = 31808 GB

After Ao1 second reading we have:
233 = 8C00-8080 = 2944
241 = 8680-7C40 = 2624
=> Write amplification = 1.12 for incompressible data. I assumed initially a greater write amplification because, as far as I remember, there was also some compressible data written at beginning if endurance test.

Now, knowing that the parameter is indicating real writes, I believe we can find out more about how compression works and its efficiency compared to a zip algorithm. For example, if controller is archiving chunks of 64KB of data and it does not make any difference when only zeroes are written, then for each 64GB we should see an increase of 4GB for 233. This would tell us that lowest theoretical write amplification is 0.0625. Also, would be interesting to see how write amplification is evolving with free space for incompressible data. I would suspect a higher write amplification as drive gets full.

[Anvil]

Well, this is my most recent V2 with actual data running on it.
Almost no benchmarks have been run on this drive, well, extremely little considering I do test my drives

It is my OS drive on my laptop and is running a few VM's as well.

cdi_233_V2_240GB.PNG

So,
768GB Host writes
448GB Flash writes

= 0.58

There are no incompressible files on this drive, except for the installation files used by a few apps, so, a small amount of images (mostly screenshots) and the VM's.

One of the VM's contain development tools and the other one is my main VM containing Outlook, Office, documents etc.

The drive has some extra OP (I normaly add some OP) and so this drive utilizes 203GB out of the 223GB that are available.

[Ao1]

Interesting. This gives a nice overview and what sergui suggests would put compression under a microscope.

Anvil could you run a series of benchmarks on an un-throttled SF drive as I did in post #237?

The V2 is currently still going strong. Maybe I have to wait 7 days.

[sergiu]

And here is my drive:

It is used as primary drive in my laptop and I have both compressible (programs/VM images) and incompressible data (mp3s, some small movies). Recently I even enabled memory paging to see how it is handled, but based on my usage pattern, it wrote only 3-5GB more per day.

[Ao1]

So sergui, you have written on average ~0.37GB per hour. Anvil you are at 1.89GB per hour.

Both well below the requirements to induce life time throttling.

I'm around 0.98GB per hour on my X25-M.

This form of life time throttling is unlikely to be an issue unless you writes lots of uncompressible data and don't leave the drive idling afterwards.

Regarding if a SE clears throttling. technically you could say yes. BUT as soon as you start to write heavily immediately afterwards it will kick straight back in. That's exactly what I saw last time and I think it is essentially what Tony states here in a roundabout way.

Yes it clears the drive, but no it does not clear life time throttling.

We will soon see when I throw in the nuke SE option after the drive becomes throttled again.

[Ao1]

OK, I think we can confirm that 233 is a really interesting finding, thanks sergui

And finally

4GB of 0-Fill

Anvil, if you use Hard Disk Sentinel you can get MB values. It would be interesting to see how many MB are required for 4GB 0fill.

It must be really low so it seems like read/ write speeds for 0fill are more down to processor speed.

Hard Disk Sentinel is available on a free trial.

[Ao1]

Looks like throttling has kicked in. Speed started dropping at the end of a cycle and when the new cycle started it had slowed down significantly.



When I'm sure its fully throttled I'm going to run a few benchmarks. I'll then do a SE with the OCZ toolbox followed by a re-run of the same benchmarks.

If the drive is still throttled I'll run the nuke SE and then re-run the benchmarks

[Ao1]

[Anvil]

I'll give smartmontools a try, the sentinel trial won't allow me to select what drive to monitor.

If it works I'll try on both generations of SF controllers, might differ

[Ao1]

SE with the OCZ Toolbox. Reboot. Initialise and format disk. Run As SSD.

The OCZ Toolbox SE does not reset throttling.

Nuke option coming up after I work out how to do it.

[Ao1]

[Ao1]

The nuke SE option.

SE does not clear life time throttling.

I'll leave the V2 to idle for one hour and then I'll run AS SSD again. Then I'll leave it for a couple of hours and run AS SSD again.

[One_Hertz]

Security erase is just a standard ATA command. There are really only two ways to do this - standard SE and enhanced SE, which are two different commands. They do different things for some HDDs (the HDDs that support enhanced security erase will also wipe remapped sectors). I don't know if this matters for SSDs.

[Ao1]

I'll give smartmontools a try, the sentinel trial won't allow me to select what drive to monitor.

Mine does. Are you using this one?

[Ao1]

Security erase is just a standard ATA command. There are really only two ways to do this - standard SE and enhanced SE, which are two different commands. They do different things for some HDDs (the HDDs that support enhanced security erase will also wipe remapped sectors). I don't know if this matters for SSDs.

Exactly. A SE is an SE. I was asked to use Sanitary Erase (the nuke option) so I gave it a try. No reason for it to be any different to the OCZ Toolbox SE, unless that was somehow not following the ATA comand. For sure it was working however, as I had to re-initialise the disk every time.

[RyderOCZ]

If you want to try something different, issue the SE from Linux (Hdparm) while you are in IDE mode with the SATA controller.

[Anvil]

Mine does. Are you using this one?

Don't know, tried it a few months back, will try it again. (downloaded the pro edition)

[Ao1]

If you want to try something different, issue the SE from Linux (Hdparm) while you are in IDE mode with the SATA controller.

Is it worth the trouble? Does the OCZ Toolbox not properly execute a SE? Praz has stated that if you need to re-initialise the disk after a tool box SE you can be sure it has worked. (He said that on the OCZ forum......haven't got a link at hand)

Edit, also I tried a hdderase in IDE mode last time I tested this. It made no difference.

[Ao1]

@ groberts101

Could you post your SMART attribute values for 233 & the power on hours?

Thanks.