Sandforce Life Time Throttling

Quote:

---

Originally Posted by Ao1

I've wondered why Micron & Intel NAND would have different specs for P/E cycles. Maybe Intel bins to a higher standard. Don't know, its a bit strange.

---

It could just be different statistical definitions of failure. It is a good bet that they test it by taking a large batch of flash, then repeatedly cycling it, noting failures. Then they could make a graph with % of batch failed on the vertical axis, and cycles on the horizontal axis. Then you could check where the data crosses some percentage failure number, and check the horizontal access for the corresponding number of cycles. But what percentage? 0.1%? Lower?

Maybe there is a standard that the major flash manufacturers have ageed upon for defining failure in a test like this, but if there is, I do not know what it is. Even if Intel and Micron are using the same definition, I can imagine that they could get significantly different results by testing different batches of flash. Or perhaps Intel just has tougher standards for production testing and Intel fails more marginal die or wafers than Micron does. There are so many possibilities.

This thread has meandered a bit. Not only does it cover LTT, but also Sandforce compression efficiency and even RAISE.

To sum up my understanding:

1. Warranty throttling, at least in Ao1's drive, seems to allow for about 1.7 TiB of writes per 24 hour day of powered-on idle time before kicking in. This equals about 7 hours of continuous writing at maximum speed for this particular drive. I'm unclear on exactly how many cycles this has been tested with however. When the drive is new it won't show any throttling until the credit period is used up. I'm uncertain of exactly what the credit period was for this drive however.

[If your computer is turned off when you are asleep, but left on the rest of the time your write allowance per day should be more like 1.13 TB per day. Still a sizeable number. I would have to conclude that very few people would be affected by this number. One realistic high write scenario for desktop usage would be a large ramdisk backup to SSD. For a 24 GB ramdisk with 10 shutdowns per day that would only be 240 GB of writes per day (assuming incompressible data on the ramdisk) in addition to normal usage. If you assume a gaming usage you could also assume 3 12 GB game installs per day for another 36 GB of writes and you still have not even reached 300 GB of writes per day. Perhaps video editing usage could exceed this. Especially with uncompressed or losslessly compressed video.]

2. Sandforce compression is around 5-10% more efficient than NTFS compression in general. Both NTFS compression and Sandforce compression pale in comparison to rar or 7zip compression even in 'fastest' mode, but SF and NTFS compression is real time, on-the-fly compression and the others are not. Sandforce compression seems to slow down writes quite a bit when it is used, although if the data is sufficiently compressible (down to at least half it's uncompressed size) these slowdowns are made up for because there is so much less data to write. Unless the SF compressor attempts to detect and avoid compressing data that is mostly incompressible this performance hit could be a significant disadvantage when compared to drives without hardware compression. Testing also seems to indicate that the average program/data drive is not nearly as compressible as many people might assume, at least with real time compression algorithms. 7zip could likely do a much better job, but it's not designed for real time usage.

[I would guess that some kind of compression software written specifically for the purpose could beat the SF hardware compressor at its own game at the expense of some CPU time by being smart about what it decides is worth compressing or by allowing the user to preselect which directories or file types not to bother compressing at all. You could have default deny or default allow mode, a whitelist or blacklist method.]

3. RAISE is probably not used on most Sandforce 25nm 60 GB drives, but probably is used on many 120/240 GB drives. Which 120/240 GB drives use RAISE is currently unknown however.

^ I have updated the 1st post with key findings. Taking into account the lack of info from SF/ vendors it is not possible to give precise answers in all instances, however hopefully the thread summary has enabled a better understanding of how life time throttling and compression work.

It looks like there is a way to determine the LTT warranty duration on OCZ drives: Open the OCZ Toolbox, press CTRL-ALT L to enable logging, read the SMART data for the drive or the identify data. Leave the toolbox open for a few minutes to enable logging and then close it. Locate the "ocztechnology.log" file in the same directory as the toolbox.

Vertex 2 40GB
Warranty Period : 1 year(s)
Logical Capacity: 78161328 sectors
Sector Size : 512

Vertex 3 60GB
Warranty Period : 1 year(s)
Logical Capacity: 117231408 sectors
Sector Size : 512

But the Vertex 3 wasn't acting like it had a 1yr lifetime setting :confused:

johnw's 24hr wait-then-write and simple extrapolation of LTT speeds both calculated the lifetime setting to be much shorter than 1 year.

The log file must be indicating something and it isn't the OCZ warranty duration. AFAIK there is not a setting below 1 year; other than disabled. Does the OCZ Toolbox work with your modified drive? It would be interesting to see what value it gave. It would also be helpful to see values for larger capacity drives. If an OCZ drive can produce a log file via the Toolbox there must be a command that could generate that info on any SF drive. Might save on testing if the LTT setting could be extracted.

OCZ Toolbox recognizes it and can secure erase, read SMART, etc., (and can probably even flash it--but I'm not trying it), but I tried what you wrote and there's nothing of the sort in the log. :eh:

I'll try again. :)

It can be a bit hit and miss. When you open the toolbox select the drive first and then hit Ctrl/ Alt/ L. The log file should immediately appear in the directory. It won't contain any useful until you select Details> Identity Data or SMART data. Once you have viewed either leave the log file for a few minutes to enable the log to be populated. Close the Toolbox and the log file will hopefully be populated. If not try again. As long as the log file is generated via Ctrl/ Alt/ L it should work.

I've attached a log file that I have just generated.

Attachment 119619

Results for OCZ Vertex 3 240GB:

Warranty Period : 1 year(s)
Logical Capacity: 468862128 sectors
Sector Size : 512
Sector Alignment: 0

Seems odd for me to see 1 year for such a big drive.

Later edit:

Results for OCZ Vertex 2 120GB:

Warranty Period : 1 year(s)
Logical Capacity: 234441648 sectors
Sector Size : 512
Sector Alignment: 0

These results were obtained with OCZ Toolbox 2.39.02. With 2.35 I could not get anything useful. Still, odd to see such a value, but on the other hand, it make sense: power users/light servers who write alot of data will not be so much impacted while normal users will never feel the LLT. As a note of real life usage: The OCZ Vertex 3 model is used for hosting a few virtual machines and it only wrote almost 1TB in 3 months.

So does the LTT go away after a year? I've read every post in this thread, but still don't have a firm grasp on this new information. It seems like even a power user would never hit the 1 year warranty estimates in the OP. Seems like this is good news for Vertex owners, if I am reading right. Please correct me if I am wrong. Amazing work what you guys have done on this subject.

Here's my entire log from my custom baked SF-1200 firmware:

Code:

---

SF DEVICE LOG
STARTED
ReadSmartData Enter
SmartEnable Enter
SmartEnable Exit

ReadSmartData Success

ReadSmartData Exit

ReadSmartData Enter
SmartEnable Enter
SmartEnable Exit

ReadSmartData Success

ReadSmartData Exit

---

Guess the OCZ Toolbox is really meant for OCZ firmware :lol:

And yes, after a year (or whatever the lifetime period is set for), LTT should not activate.

What about Ao1's Vertex2 in the write endurance thread? Is it simply leaving it on for a power-on year, or is it a calendar year?

Power-on year. There's no way for the SSD to know if a year has passed unless it has power and can run its internal timer.

ha That makes sense! Thanks for the info. It does seem like, even for someone doing occasional video editing, that the LTT is generous enough to use a SF drive (at least OCZ). Again, very illuminating info you guys have sussed out.

Something interesting I believe about LLT... OCZ Vertex 3 120GB compared to Corsair Force 3 120GB. Look at E6 parameter:
Attachment 119701
Attachment 119702

I would say that we have a way to figure out if LLT is enabled for second generation Sandforce based chipsets. But also, we would need more posts from non OCZ SSDs

Interesting!

Will check my drives later today, E6 is missing on SF1 series so this looks to work only for SF2. (which is a pity)

Corsair GT

Attachment 119727

Force 3

Notice that several attributes have changed having updated to fw 1.3, amongst them is power on count?
(and the 3rd byte has changed from 100 to 0)
I also noticed that ASC2 changed to ATA8-ASC, not sure what that means as both are ASC-2 Revision 3
Attachment 119728 Attachment 119729

Adata s511

Attachment 120080

To AO1: Just a little correction:

Quote:

---

There are three choices that a SF vendor can choose from for the warranty duration:

 No throttling
 1 year warranty
 3 year warranty
 5-year warranty

---

Math was never my strong point :) I’ve updated the first post accordingly. I’ve also updated it to reflect the fact that it appears that OCZ might be alone in activating LTT. In the endurance thread two SF based drives from Corsair and one drive from Mushkin have revealed that LLT has not been configured.

(Welcome to the forum btw)

Hehe been there since 2008 but didn't post yet.

SSD are what makes me post these last years.

Welcome Kensiko :)

nice to see the SSD tease you out finally!

Quote:

---

Originally Posted by Computurd

Welcome Kensiko :)

nice to see the SSD tease you out finally!

---

LOL that is not what I meant, anyway, you'll know if you go to the OCZ forum :)

Currently I’m using a 520 for my OS drive. I’m going to track host vs nand writes over a week (maybe longer) of normal use. I have installed the OS and typical apps that I use. Static data is on a different SSD, so I’m only using the SSD to run the OS and apps.

End of day one. I’m surprised by the amount of writes. All apps were preinstalled and I did not xfer large files. :shrug:

Attachment 124387

Day 2. The writes seem to be in line with use, which was very light. As mentioned static data is stored on separate drives, so activities like listening to mp3’s is not recorded (as a read).

It seems that light use results in multiple small xfers that generate high write amplification. At the end of the 7 days I will leave the pc to idle for 24 hours to see how many writes are incurred and what the resulting WA comes out at.

Attachment 124395