Sandforce Life Time Throttling

[Ao1]

05 204 was around the start.

Currently E6 is:
0 638 0 100 (2 byte)
0 2 120 0 0 0 100 (1byte)

Writes (E9) 38,443

E6 Start 1,479
E6 Current 638
Difference: 841

E9 Start 37,484
E9 Current 38,443
Difference: 959

Anvils app is still going strong. Guess it will do for another 638GiB.

[Anvil]

With regards to the power on count the hours seem to be too high now. Currently it is reporting 217 hours. 11 hours after post ~351 and power on hours have gone from 195 to 217 = 22 hours. Exactly double.

I saw the same thing on the V3 240GB drives w/ fw 2.11, weird behavior, what are the long term consequences of this wrt LTT, will the 1 year LTT drive get to be a 6 month LTT?

[Vapor]

05 204 was around the start.

Currently E6 is:
0 638 0 100 (2 byte)
0 2 120 0 0 0 100 (1byte)

Writes (E9) 38,443

E6 Start 1,479
E6 Current 638
Difference: 841

E9 Start 37,484
E9 Current 38,443
Difference: 959

Anvils app is still going strong. Guess it will do for another 638GiB.

So for every 1.14GB written to NAND, E6 moves 1 notch. How has F1 moved? Could LTT on SF-2200 be aligned with Host Writes and not NAND writes?

EDIT: 1479 * 1.14 = 1686GiB after 24hrs of idle = 601TiB/yr = 9600-11000 P/E cycles, depending how you count (cycle could be 60GB [available NAND], 64GB, 60GiB, or 64GiB [total NAND]).

[Ao1]

Typical. Missed the exact time the drive became throttled, but it must have been close to 7 hours. (Looking at Anvil's Avg and current write speeds)

I'm still confident the writes per day in post #374 are about as close a guess as can be had.

F1 is 38,594 btw. I only normally use E9 for writes, but they are both very close anyway.

[Anvil]

Ao1,

Select "Browse results" in the Endurance test and you will be able to spot when the decrease in speed started.
(all loops are recorded in a database)

[Vapor]

Whoa, is power on hours moving properly during writes and moving at double-time when idle?

1339GiB for every 24hrs of idle, that's 477TiB/yr or 7600-8700 P/E cycles, depending on how you count (cycle could be 60GB [available NAND], 64GB, 60GiB, or 64GiB [total NAND]). With 3000 or 5000 cycle NAND, that's not even 1/integer of a year, interesting. Some arbitrary value was assigned?

Either way, 1339GiB a day (15.87MiB/sec) is a very, very large task to even enter LTT conditions. And it does look like 16MiB/sec LTT speed is really close to what you found.

[Ao1]

Ao1,

Select "Browse results" in the Endurance test and you will be able to spot when the decrease in speed started.
(all loops are recorded in a database)

Nice feature I missed that somehow. It looks like I also only just missed the drive going into a throttled state.

Whoa, is power on hours moving properly during writes and moving at double-time when idle?

Strange indeed, but that is what appears to have happened.

[Vapor]

Some SF-1200 compression numbers. 64GB resolution means these figures are rougher than the SF-2200's, but still indicative of how good the SF-1200 is at compression.

That said, it's way too early in the test to say the 8% figure has any merit, this was more of a report of the 0-fill. SF-1200 with 0-fill is worse than NTFS (but so was the SF-2200) but more importantly, it's also much worse than the SF-2200 which compressed it down to ~15% vs. ~24% of SF-1200. If (big if) the 8% Compression test figure stands at 33%, then the SF-1200 is also worse than NTFS (23.7%) at that setting...and more importantly, much worse than SF-2200 (~17%).

[sergiu]

Interesting... the results contradict what Ao1 found out in posts #141 and #148 which is 12.5% for zero fill and 15% for 8% compressible results. In his 0 fill test, the resolution was worst than yours, but in 8% compressible results should be comparable. Also, is any chance for your drive to be misaligned? Your 4k random reads are identical with my drive's speed when it was misaligned.

[Ao1]

I was coming out at 15% on the V2, but I had higher readings over a small data range. I suspect the 64GB refresh was the problem.
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


(I posted the Excel results for the V3 compression comparisons in the first post).

[Vapor]

All I did was plug in the drive and format with Windows 7's Disk Management which should align it just fine (right?). Both AS-SSD and Anvil's Apps report it's aligned fine, but there's always a possibility that alignment is not okay.

I thought the random reads were symptomatic of Hynix 32nm's poor performance, but they could well be because of poor alignment.

EDIT: 8% setting is still compressing down to 33% after roughly double the sample size from a few posts up. This is odd that the two SF-1200s are so different

[sergiu]

This is indeed strange... I usually check manually the starting sector number for alignment but I also knew that W7 disk management is doing it right. I will also do the 0fill test on my SSD (Vertex 2 120GB) and I will post the result later.

[therat]

I think the fact that the warranty throttling is undocumented makes it easier for Sandforce and OCZ to sell SSDs with buggy firmware. After all, if no one knows what is supposed to trigger the throttling, then no one can claim it is not working properly. OCZ blames it on Sandforce being secretive, which is absurd since Sandforce has patented the technique (which isn't particularly innovative anyway) and so the fundamentals can be known to anyone simply by looking up the patent.

All that is needed is for OCZ to document the specifics for each SSD model: what triggers the throttling, how slow is the throttled performance, and what needs to happen for throttling to be released. This seems like an obvious thing for the SSD datasheet, since it directly impacts the functioning of the SSD and does not require disclosing any of Sandforce's trade secrets. But OCZ's representative dubiously claims Sandforce is keeping it secret, and no doubt Sandforce would say that OCZ is keeping it secret. It is like Laurel and Hardy selling SSDs.

There is no way OCZ is going to publicly state their drive supports throttling regardless of how rare it might occur. Most casual SSD buyers would see "throttling" in the specs and avoid them like the plague.

[sergiu]

I just tested the 0 fill compression rate on my OCZ Vertex 2 120GB, but in a little unorthodox way. First, I wrote movies until E9 and F1 parameters incremented (manual refresh in Cristal Disk Info every 3-5s) and I noted the values. I run then Anvils Storage Utilities with 0 fill for 339.7 GiB and switched to a dumb Java program that wrote continuously on all available free space from the partition and logged result in increments of 2-3GiB (actually 2.44GiB but rounded to lowest int). In this time, I followed changes in Cristal Disk Info.
So here is what happen:
F1->3328
E9->1984 later, after around 13GB of movies written. After the increment I started the endurance test with 0 fill.
F1->3840 after 339.7GiB + ~151GiB = ~490GiB => SSD incremented the value with 512 for around 503-504GiB written
E9->2048 after 339.7GiB + ~153-159GiB = ~492-498GiB.
Based on what I counted it incremented with one 64 step for 492-498GiB =>Compression 12.8%
Based on what SSD seems to have counted, it incremented one step for 501-507GiB => Compression 12.6%

Considering that the SSD is running as a primary drive with OS and other programs that also wrote data in the same time (although I closed all unnecessary programs), I would estimate a compression ratio of 12.5-13% for 0 fill on my drive.





Now, a little strange thing during Anvil's tool. The application wrote what it seems to be a lot of random data and according to HddSentinel, at the beginning of each burst of random writes, the peak speed was around 60-70MiB/s then suddenly settled for around 28MiB/s

[Ao1]

Nice observations I'm retesting 8% fill on the V2. Currently the compressed rate is coming out at around 17% , but that is only on 400TB of host writes so far. 64Gb refresh periods are a pain

[Vapor]

I continued testing 8% until I went to bed and it stayed pretty constant, finishing at 32%. It wasn't as large of a sample size as I wanted, so I will test it again (just ~1300GiB and I didn't do any of the micro-counting sergiu did).

I tested 25% for 12hrs and it was compressed to just 86%. SF-2200 was at 41% and both of your SF-1200s have been performing similarly to the SF-2200.

[sergiu]

I continued testing 8% until I went to bed and it stayed pretty constant, finishing at 32%. It wasn't as large of a sample size as I wanted, so I will test it again (just ~1300GiB and I didn't do any of the micro-counting sergiu did).

I tested 25% for 12hrs and it was compressed to just 86%. SF-2200 was at 41% and both of your SF-1200s have been performing similarly to the SF-2200.

Your numbers for 0fill, 8% and 25% seems to be double the SF-2200 and SF1200 (for first two tests). I would say somehow is not aligned or internally its doing something that doubles the writes. Maybe some static data rotation? Could you do a short test with 4K incompressible random writes? If there's doubling, you should see almost twice the writes.
Also, regarding testing, I did the micro-counting because, being my main and only drive unfortunately I cannot let it wear until I see a significant increase in values. But you can easily achieve the same or much better precision if you have at least 20-30 increments (100 would be ideal for a 1% error margin).

[Tony]

There is no way OCZ is going to publicly state their drive supports throttling regardless of how rare it might occur. Most casual SSD buyers would see "throttling" in the specs and avoid them like the plague.

This info is covered by SF under NDA, we asked if this could be made public but we were told NO.

You guys need to remember SF want to protect their IP here, you are now in fact *Possibly* reverse engineering that IP which could give a competing controller manufacturer an advantage.

Everything OCZ was able to tell has been told...this has been more than any other SF partner....we do our best to keep you in the loop but there are limits...which have now been hit.

[Vapor]

Your numbers for 0fill, 8% and 25% seems to be double the SF-2200 and SF1200 (for first two tests). I would say somehow is not aligned or internally its doing something that doubles the writes. Maybe some static data rotation? Could you do a short test with 4K incompressible random writes? If there's doubling, you should see almost twice the writes.
Also, regarding testing, I did the micro-counting because, being my main and only drive unfortunately I cannot let it wear until I see a significant increase in values. But you can easily achieve the same or much better precision if you have at least 20-30 increments (100 would be ideal for a 1% error margin).

I have no static data on my drive. I'll get to incompressible data soon enough.

I agree with you doing micro-counting, it's the fastest way to do it and it's accurate I'm out to kill this drive so I'm doing the normal way

My 25% on the V2 came in around the same as the V3.

Attachment 118453

I haven't tested my Vertex 3 yet, the table I'm showing is just your Vertex 3 numbers summed instead of an average of an average (which is why they're slightly off). Instead of averaging 15%, 16%, 15%, and 17% when the test sizes aren't the same (1, 1, 1, and 10), I'm just summing the total E9 and F1 growth dividing based on those numbers.

Looks like with the SF-1200, I'm doubling except at 0-fill. I've had 46% going for a few hours, let's see what that is at now.

This info is covered by SF under NDA, we asked if this could be made public but we were told NO.

You guys need to remember SF want to protect their IP here, you are now in fact *Possibly* reverse engineering that IP which could give a competing controller manufacturer an advantage.

Everything OCZ was able to tell has been told...this has been more than any other SF partner....we do our best to keep you in the loop but there are limits...which have now been hit.

No worries, we don't need to be given all the answers, more than half the fun is finding it out ourselves (or as best we can).

If I were SF, I'd say no to releasing the info too

(as for us reverse engineering for a competitor--if a competitor wanted to do it, they've had a chance to get months (or even a year+) ahead of us and could put more resources into it than us)


EDIT: early in the test for 46%, only 640GiB of Host Writes, but the Compression/WA is 150% Ao1's SF-2200 was 70% so I seem to still be doubling the SF-2200 (and almost exactly doubling). Could it be my firmware is reporting double but not writing double?

[Ao1]

Whoops, chart changed. TBH I only have confidence in my figures for the V3. I'm not sure how you are micro-counting, but it sounds like it is more accurate, so if your results conflict with mine I can take mine out or re-check them. Currently 46% is coming out at 80%, but without E9 & F1 being aligned its open to being inaccurate.

When I get time I'll consider how write speeds are linked to the compression ratios. That should provide a cross check.

[Ao1]

For what it's worth. V2 46& fill = 75% after 0.5TiB of writes. Just after I stopped the E9 value changed, which would have given 83% if included.

[johnw]

There is no way OCZ is going to publicly state their drive supports throttling regardless of how rare it might occur. Most casual SSD buyers would see "throttling" in the specs and avoid them like the plague.

That is because warranty throttling is not a feature, but a limitation. It does not benefit anyone except possibly OCZ (no need to explain to an RMA customer that the warranty does not apply because they wrote 1PB in 3 months).

And customers should avoid drives that are throttled. So basically what you are saying is that OCZ is selling an inferior product, but hiding that fact from potential customers.

[johnw]

This info is covered by SF under NDA, we asked if this could be made public but we were told NO.

You guys need to remember SF want to protect their IP here, you are now in fact *Possibly* reverse engineering that IP which could give a competing controller manufacturer an advantage.

Right, you asked Sandforce if you could say that the drive gets throttled if you write a lot of data to it in a short time, and they said no, you cannot say that. Thanks, Hardy, that's good for a laugh. Sure, the fact that the drive gets throttled is reverse engineering, yup. You are a riot!

[Dragoonseal]

Tony's post is a little weird, I can't tell if he's being defensive or just paying you guys a compliment. I think it should be taken as a compliment either way though.

You guys are like the A-Team or MacGyvers of SSD testers, reverse engineering top secret classified information about controllers using paper clips, ballpoint pens, rubber bands, tweezers, nasal spray, and turkey basters!

[Ao1]

Here is a comparison of write speeds using different levels of compression rates.

For sequential xfres there are three main bands

• 0% to 8% Compression = ~100% of max speed
• 25% to 46% = Compression = ~45% of max speed
• 67% to 100% Compression = ~30% of max speed

4K QD1
Performance approximately the same regardless of compression ratio

4K QD 4 & QD 16
Compressible 4K xfers are assisted with queue depth.






EDIT: I added an X25-M just to help show where compression might be helping.