You guys are asking for trouble, SSDs are an immature technology. You better backup any data you want to save, they will surely fail any minute!
Printable View
You guys are asking for trouble, SSDs are an immature technology. You better backup any data you want to save, they will surely fail any minute!
i would recommend many devices that have large spinning platters of metal and tons of moving parts. the more moving parts the better!
if Ao1 wasn't able to restore the V2 with a secure erase then there are other issues at play there. I would do a secure erase and test it as secondary using a quick sequential test with AS SSD. Even a hammered state drive would never go much below 50% of original fresh write speeds as the on the fly recovery is sufficient enough to keep from dropping below that.
These controllers implement a lifetime throttle called a settled in state when the Durawrite mapping has fully formed(all nand written to at least once). A proper SE will wipe that map completely and allow fresh speeds immediately afterwards. If it doesn't?.. something else going on there.
The other thing that needs to be kept in mind about Sandforce is the need for some idle time as TRIM alone will not initiate recovery as other controllers would do. SF needs that low activity idle time for the controller to recover those trim marked blocks more efficiently.
Also consider that if a Sandforce drive is barraged with random data like that it can take quite some time to rotate data and work towards improving internal data consolidation to allow any future writes to even have the slightest chance at being written contiguiously(which the controller tries to do whenever possible/within wear leveling's requirements. IOW,.. I've seen many that become far too fragmented(well..even moreson that usual for SSD) and can suffer badly. Still never seen one drop much below 50% of fresh incompressible write speeds though, and something seems odd given that the drive didn't respond to the SE as expected. I'd be trying it on another machine as a freshly SE'd/quick formatted secondary drive and I would guess that would help paint a truer picture.
How was the SE done and with what tool?
I ran secure erase a number of times from the OCZ toolbox. It made no difference at all, most likely because DuraClass is located on an inaccessible secure area of the drive along with SMART & the fw etc. If it was accessible you could just bypass DuraClass with a secure erase, which would defeat its objective.
Obviously the load I placed on the SSD was extreme and it seems that DuraClass reacted accordingly. How long it takes to deactivate I don't know. Unfortunately access is not provided to the 230 SMART attribute to confirm or otherwise if DuraClass is active.
There is no information available about how it works, other than it will slow down writes that threaten to wear out the NAND before a predetermined life span.
It would be easy enough to repeat what I experienced by just running Anvil's app for 7 days.
Currently I have left the V2 plugged in and idle. I will leave it that way for three months to see if DuraClass is then deactivated.
One thing I don't understand about Sandforce's throttling is how it determine how many years into the warranty the drive is. Does the SSD actually have a clock on board? If not, I guess it can only judge the passing of time by how many power-on hours it has had. In that case, the throttling could make a huge mistake for someone who only turned his drive on for 24 hours once a month, but ran Anvil's program for the entire 24 hours each month. After a few months, the drive would think it is only a few days old, but it has written so much that it would throttle the speed to try to extend its lifetime, even though what it has written is acceptable for several months of life.
Writing 24/7 is pretty extreme and no idle time is given.
I've had a few moments where I wished I had made a small pause at the time when the files are deleted or one single 30min pause per day.
I did test a small pause on the Intel and it didn't make a difference so I didn't bother, should be mentioned in one of the early posts.
I've never had any of my SF drives drop below 60MB/s (the 60GB) and about 90MB/s for the LE's, the workload the 40GB's are given is beyond anything they could possibly encounter in real life, even as "enterprise" drives.
--
45.6TB Host writes
MWI 74
I might give it a day or so on an Intel setup just to see if that makes a difference, could be this weekend.
I got curious. The drive has been sat idle for 5 days. No data on the drive, which was secure erased before being left to idle.
I ran AS SSD twice. Seems that throttling has been reduced, but it's still evident.
I will start running Anvil's app again until it gets full throttled. I will then unplug it, leave it for 5 days and then run a couple of AS SSD benchmarks. That should give some indiction if it is power on time.
Ao1
Based on your test, that period could be 7 days. (there is no saying that the limit is based on a daily rate, so an avg on 7 days is just as likely)
Thinking about this some more, if it had a clock it would need a power source, either a small lithium button battery, or possibly a capacitor. I'm pretty sure there is no battery on the board (based on many pictures I have seen), so it would have to be a capacitor. But even the best capacitors would have enough leakage that I doubt they could hold a charge for months. So my guess is that there is no clock on board the Sandforce SSDs.
If I'm right, then it must either be using power-on hours, or perhaps it makes an assumption, like 8 hours power-on = 1 day of life. Either way, it could get the throttling way wrong for non-standard usage, like the guy I mentioned who only powers his SSD on one day a month.
60TB. 70%. The reallocated sector count went up to 4 from 2 overnight.
It is powered on time and if you secure erased it you erased any throttling due to lifetime.
It would be interesting to see as a comparation a similar test but with HDDs. Let's say taking a few models with 640GB or higher plates, make a 40GB partition at the beginning then do the same job and watch how many bad sectors popup in time. We could compare the reliability of old vs new technology when it comes to real usage.
Hi Ryder,
I ran a secure erase from the OCZ toolbox 3 or 4 times and it did not clear the throttling.:shrug:
In post #252 write speeds came back after a couple of hours idling, but within an hour the write speeds went back to a crawl.
Prior to that happening the drive chugged along nicely writing continuously for 7 days.
I have now been running Anvil's app for 5 hours and write speeds have remained stable and within the parameters of the 1st 7 days of running the app. I will continue to run the app to see what happens next.
Does the OCZ Toolbox secure erase do the same job as hdderase?
If you can erase the Duraclass lifetime throttling (by inducing even more wear with a secure erase) what purpose does it serve?
Did you shutdown the drive after the SE?
Yes, toolbox just issues the ATA secure erase command, which is the same as hdderase.
I will check with my cohorts, but I am fairly sure that SE should stop a lifetime throttle. Lifetime throttle is all about the number of writes over a period of time. Get them too high and it slows down to prolong the life.
I tried rebooting a number of times and had to create a new partition after each secure erase, so it would certainly seem that the SE worked, but the drive remained throttled.
Let's see if I can reproduce it with another onslaught from Anvil's app.
Been running now for 7 to 8 hours and no sign of a slow down yet. :up:
Delta between most-worn and least-worn Flash blocks is now 13, otherwise no change.
EDIT. Spoke too soon. Write speeds dropped by half mid way through a loop and are now steadily decreasing.
Down to 6MB/s on Anvil apps within 460GB of writes. AS SSD as below.
Clearly DuraClass stepped in much faster this time.
Now I try a flash and a reboot. Then I'll run an AS SSD Benchmark and will post the results in a bit.
The reads do not look throttled this time around.
The sequential write test started off running quite fast, but then slowed down after a few seconds.
It appears that a secure erase does not clear the throttling.
Now I will unplug the drive, leave it 5 days before trying another AS SSD benchmark run.
Since the throttling is based on power-on time rather than calendar time, and secure-erase does NOT eliminate throttling (as Ao1 found), it seems this Sandforce "feature" is worse than useless. No power user would want that monkey on his back...errr...SSD.
Has OCZ looked at the possibility of selling a model of Sandforce SSD with throttling disabled?
Here is shot with a different SSD Benchmark. I'm under NDA so I can't post a screen shot of the bench app unless I'm given a heads ups that it's OK to do so, but the bench output is as below.
8GB test size. Non compressible data.
Considering that after 460GB you were limited to a speed of about 0.5TB/day, I would assume that for your model, the limit might be to 0.5TB/day of usage. Could you let it run a few days more at this speed? If this would be the worst throttling scenario, this would still allow at least 14K cycles with uncompressible data. Or maybe around 5K cycles with data that compresses to around 35%.
For transparency it would be very helpful if the 230 SMART attribute could be made available in a fw update. Ideally it should indicate “lifetime throttling was active for last write” AND “lifetime throttling is currently active”
More info about write limits on a daily basis (or whatever time frame it uses) to avoid throttling would also be very helpful.
Do you mean it will sit unpowered for 5 days? If so, it sounds like that will have no effect on the throttling, since Ryder said it is based on power-on hours, and that coincides with my guess.
But it is still worth a test, I think, so I'm not saying don't do it. I just wanted clarification on whether you were doing 5 days unpowered or powered.
I'm fully expecting the drive to still be in the same throttled in 5 days time, but as least I will know for sure this way. :up:
Currently the drive is sitting on my desk completely disconnected and it will remain that way for 5 days.
Sergiu has an interesting point. Maybe the fully throttled state gives an indication of how much you can write per day. When I reconnect it I will see just how slow it goes and what can be written per day at that speed.
I had to stop the test for a few hours last night, this process apparently puts a bit of stress on this computer and so a backup ended up failing due to that the NIC stopped working, happened several times.
This isn't a real server and there is a reason to why they do build real servers, anyways, I'm ordering an Intel NIC, should be much better than the onboard stuff.
48.06TB Host writes
MWI 73
Attachment 114839
64TB. 67%. 5 reallocated sectors. The reallocated count seems to be on the rise for me :)
How are write speeds holding up for both of you?
I honestly thought some of the drives would be done before this point. It seems SSD life is much better than I had thought from what I read in reviews.
A trend line based on current readings
Attachment 114845
... and whos to say that it stops when we reach 0 MWI.
Assuming 190TB and 10GB/day of writes that's 53 year lifespan, lol.
That graph really does show a couple of things :
-Intel 320 SSD is the most endurance capable and the fastest write speeds.
-Vertex 2 premature uselessness due to stupid throttling
Thanks !
53.4TB Host writes
MWI down by 1 to 70
Reallocations also up by 1 to 5
(updated chart in post #1)
@bulanula
Yes, I wish I had the 320 :), the old dog (X25-V) is slow on sequential writes.
I started ahead of One_Hertz and the 320 is 15TB? ahead of my X25-V already, that is a huge difference.
By the time we reach 0 (MW) the 320 should be ~50TB ahead, if all follows the same pattern that is.
55.82TB Host writes
MWI 69
No other changes.
73TB. 62%. Still 5 reallocated sectors. The linear pattern continues...
Considering the 320 is based on the same controller the performance is a lot better. Faster writes and less wear and tear with reduced PE cycles. Not bad at all. :cool: Seems even upping the random factor has made no difference.
EDIT: Improved chart. Some entries are best estimates.
Thanks again for the chart :)
I've updated the one in the first post with the latest readings.
56.78TB Host writes
MWI 68
Last 91 hours
9.927 TB written ~111.7GB/hour (<32MB/s on avg)
35,021MB Random writes
3,390,000 files created/deleted
Will try running it on an Intel tonight.
5 days later......
ouch :(
78tb. 60%.
Good to know that we are getting closer and closer to the "moment" when the MWI reaches 0 !
59.55TB Host writes
MWI 67
Reallocations remains at 5. (unchanged)
(updated chart in post #1)
@One_Hertz
78TB written, thats > 2x the advertised "endurance" :)
I left the endurance app running for about 6 hours today. Write speeds remained around 6MB/s, which comes out to ~ 500GB of data per day.
I was tempted to leave it running to see if the write speeds would get even slower, but at 6MB's the reponse times made the app unresponsive.
Right now my internet speed (50 Mbps) is as fast as my SSD (6MB/s).
One could certainly ask whether 6MB/s is throttled state or if there is something else going on.
6MB/s is on par with a slow USB stick.
Congrats with your new Internet speed :)
What else could be going on apart from throttling :shrug: The drive was able to maintain speeds before the throttling started so it can't be degradation. Even a SE does not help.
What I do notice however is that after a small amount of idle time the throttling is reduced, so if you write a small file performance goes back up, but if you start writting a larger sized file it slows down again.
I might experiment after a few days idle to see how much you can write before performance drops.
Ryder I have noticed something strange. When I run a SE from the Toolbox it states it has completed when finished, however I can still access files on the drive. It is only after I reboot that the drive appears as an un-partitioned space with no data on it.
Does the SE command somehow delay itself until re-boot?
I've noticed in Tony's troubleshooting guide that he states a SE has to be done via Linux in IDE mode. I assume he is referring to a hdderase.
Why use hdderease if it is the same as the toolbox SE process?
i personally use the stand alone version of SE, with the comp set in IDE mode. works perfect. i have never used the toolbox. but i have SE probably a million times with the standalone app :)
If we do an extremely simplistic lifetime endurance computation (ignoring WA, WL, etc.) and assume 5000 P/E cycles for the flash, then a 40GB SSD should have a lifetime write capability of about 200TB. Over 3 years, that comes to about 183GB per day.
So that is within a factor of 3 of the throttled write speed. I wouldn't expect exact agreement since the lifetime write capacity estimate was so crude.
I read in the news section that all drives are set to 5 years. :down:
I more or less always run SE on GB MB's and thats due to issues I've had while HDDerasing on Asus MBs :)
When cleaning drives using the OCZ Toolbox they are always cleaned immediately, meaning I don't have to reboot.
Bizarre. l can navigate file structures, and some of the files will execute. Others won't. Once re-booted the drive has to be reinitialised and all data is gone.
Dang, now I'm going have to swap it over to a non ASUS board to run hdderease to see if that clears the throttling. (Would be really nice if it did :) )
oh no. drive is dead effective immediately. i would highly reccomend using the stand alone utility. i think it is available for DL still, if not let me know. i have a copy. several actually, even the original which was password protected.Quote:
When you run a SE from the toolbox can you still see the files before you re-boot? Did performance go back to a fresh state? I just want to be sure that the drive was in fact SE.
What version of Toolbox are you using? 2.35 and 2.36 should send a reset to the drive (if you are in AHCI mode, which you have to be) and after a short period it should appear blank and need to be initialized in disk management, etc.
Immediately after the SE, yes it may still show data.
I definitely recommend a reboot though after SE or SE in Linux.
Hi Ryder,
I'm using 2.36. It seems that the reset function does not work. Maybe it is a quirk on Asus boards as I can't run a SE with hdderease (although I can with Intel drives).
Anyway, I've swapped the drive over to another system to run hdderease and it didn't clear the throttling, so I guess the toolbox SE was working.
Any chance of shedding some more light on how throttling works?
• Are the drives set to a 3 or 5 year life?
• How much can you write per day before duraclass kicks in?
• Once duraclass kicks in does it remain active for the rest of the drives life?
• Why are read speeds affected?
Thanks in advance.
61.3TB Host writes
MWI 66
Too add to DuraClass questions:
- Can it be disabled at our risk?
81tb. 58%.
Coming soon: Mushkin Chronos - SandForce SF-2281 SSD processor with unthrottled IOPS firmware :up:
Someone really needs to offer the SF controller without throttling and if Muskin will offer one I'm ready to order :)
Lets just hope it's unthrottled *and* IOPS firmware and not just "unthrottled IOPS".
updated chart
TBW 62.15TB, MWI 65.
I'm going to take a small 5-10 minute break every 24h as it leads to more TBW per day, 3-500GB per day.
During that break I'll be running TRIM from the SSD Toolbox.
@john
My Agility 3 60GB does 85-86K random 4K writes, short bursts though and as usual we are talking about easily compressible data.
It seems that the SF2xxx drives have more options in how you can throttle performance. Muskin have confirmed the following to a query I made:
"DuraClass management functionality is still active. “Unthrottled” in this context refers to write IOPS bursting up to 90,000+ but being governed down to 20,000 after a few seconds which is typical behavior with standard firmware with SF-2281. The firmware we have on the Chronos and Chronos Deluxe drives will not have that governor activated."
If they switch it off altogether I might get one.
So why are the drives being throttled then, exactly? If it's not DuraClass...
64.23TB Host writes
MWI 64
No other changes.
65.32TB Host writes
MWI 63
updated chart
An update on my V2. I left it idling with no data on it after a secure erase. I then ran a series of iometer based benchmarks. The advantage of the benchmark is that I can incrementally increase the size of the test file from 1GB to 12GB.
I ran each benchmark run sequentially, starting with 0 fill for the first run. All following runs were done with non compressible.
In total 30GB of non compressible data & 1GB of 0 fill.
After this barrage I let Anvil's Endurance app run. Within 2.91 hours or 383.17Gb the drive was throttled down to 6.71MB/s.
So, it seems that even a small amount of idle time will enable performance to get back, but if you sustain the writes you end up back being throttled.
Good news in a way. If I leave the drive to idle for a week or so and don't write excessively I should not experience any slowdowns.
That's the end of the V2 in this thread ;)
6.71 MB/s comes to:
403 MB/minute
24.2 GB/hour
580 GB/day
4.06 TB/week
17.6 TB/month
212 TB/year
635 TB in 3 years
1.06 PB in 5 years
In P/E cycles, assuming 40GiB of flash to distribute writes over, no WA:
13.5 per day
94.5 per week
410 per month
4900 per year
14800 in 3 years
24700 in 5 years
If the throttling algorithm is indeed a hard 6.71MB/s lifetime limit line that the controller does not allow the SSD to cross (although I wonder about the granularity....1 second? less? 1 hour?), then if your SSD is in a throttled state, you should be able to "revive" it at a rate of 24.2 GB per hour of powered-on idle time. So if you had a benchmark that wrote 20GB of data, if you just left the SSD idle for an hour before the benchmark, it should measure unthrottled performance. Depending on granularity, and whether the algorithm really works the way I think (a lifetime write line that cannot be crossed).
So do Mushkin's new SF2xxx unthrottled drives still come with a 3 year warranty? Anybody know?
If they do, then I think the other acts need to follow suit and offer the same. While I believe I've never experienced a throttle with my SF2xxx SSDs (and maybe RAID0 lessens the chances) it'd still be nice to see this throttling bit be a consumer choice.
It seems that formula might not be too far off. Here is an AS SSD after an hour or so idle. (Time between this post and the last).
(This really is the last post here on the V2 :D )
67TB Host writes
MWI 63
Attachment 114967
edit:
At 67.01TB MWI changed to 62 :)
69.88TB Host writes
MWI 61
updated chart
92.2tb. 53%.
So, not long before you reach 3x rated endurance :)
The daily break (5-10minutes, including manual TRIM) helps a bit but there is no competition vs the 320 Series.
72.79TB Host writes
MWI 59
updated chart
97tb. 50%.
Interested to see final results.
75.69TB Host writes
MWI 58
close to 10GB of random writes last 24 hours.
If you do a fresh format, how much available space does windows say you have?
So it look like the added random data is not having a noticable impact. Still near perfect linear wear and writing speeds.Attachment 116191
99TB. 49% as of this morning. It sure is taking a long time to kill this thing. I still don't believe there is any way it will last close to 1PB.
100TB is 50+gb per day for 5 years. Kind of funny how many people still do things like putting page files and browser cache on their HDD to minimize writes to the SSD...
yes this has definitely changed my perception of how to treat my own ssds. these are probably a bit tougher than the ol vertex gen1 i still use, but really theyve been in raid-0 with 8 disks forever, so im sure they have tons of life left in them!