SandForce "SF-22XX" issues and workarounds

This thread is for the general discussion and possible workarounds for the SF-22xx based SSD's.

There are lot's of suggested workarounds and we've been scratching the surface in the Endrance thread trying to find a way to avoid the dreaded disconnects, freezes and BSODs that some of the SF-2281 based drives have been plagued with.

In my case I've been having problems with the SF-2281 drive used in the Endurance thread.
In general it lasts for somewhere between 25-35 hours and as it's used as a secondary/spare drive it simply disconnects at some random point, there have been total freezes as well but disconnects is the norm.

Up to date I've been using the drive on both AMD SB850, Intel Z68 and X58 based motherboards and none of them have been successful, in the end the drive disconnects.

Still, there are a lot of suggestions and possible workarounds to try and some of them involve
- RAID option ROM's for the Intel chipsets
- Intel RST Kits/drivers
- Enabling/Disabling TRIM
- Power saving



more to come...

Reserved

Is the only way to update the option rom to pre-release 11.x via a BIOS or UEFI update injected with the 11 rom?

Yes, the "bios" needs to be injected with the option rom.

I'm currently compiling a bit of info and links to where one can find modded bios/uefi's and the tools necessary to extract/inject the option roms.

I'm trying to bone up on the subject, but it's not straightforward. It looks like some mobos are great for this and some aren't.

BTW, shouldn't you have broken the 51hr continuous mark with your Force 3 by now?

I'm avoiding using certain programs as well, as the Mushkin has only dropped out in the past few days while I was using the system, so basically I'm limiting my use of certain programs like CDI, and instead am just using SSDLife for all endurance updates. While it may sound ridiculous, it really seems like the Chronos Deluxe is always on the edge of just giving up and certain programs like RST's application and CrystalDiskInfo might tip the scales to instability. I haven't had a crash while I was away from the system is almost a week (which might be a guarantee that it happens later...).

It has gone past 54 hours so it is a new record.
More than 20TiB written in one session.
I'm running CPU-Z + RealTemp + CDI and the occational IE9 or Chrome when posting updates.

It is closing on 2x the expected runtime for this rig, not sure what to expect.

If past history is any indicator, my Chronos D should punch out between now (25hrs) and the ~30hr mark. I do notice that there are some slight pauses in the system, even thought the testing drive is no longer the OS drive. Maybe during one of these short pauses the drive just can't recover. I'm kinda exploring the option that the drive is running fine until a program does something that upsets stability. Given that I'm only ever in front of the system for a couple hours a day, it can't be a coincidence that it's only crashed when I've been using it in the last week, never when I've been away. As the system drive it would crash every 30 hours or so, then as a secondary it was much sooner, usually at some point over night.

To update to the new UEFI for my motherboard I had to downclock the ram to 1067 and swap in an AMD board instead of my nVidia GTX460. It shouldn't effect the Mushkin one way or another, but who knows? I'd believe anything at this point.

On this particular setup (ASRock Z68) it has been behaving badly but it looks like the current adjustments do work, for some reason.

It is now 58 hours w/o issues

Attachment 120891

@Anvil
You might want to check/get in touch with stasio and Lsdmeasap and let them know what you are trying to do and why. They are both GB gurus and extremely generous with their help. I think they might be willing to help you out in being able to mod the BIOS's yourself.

Quote:

---

Originally Posted by Anvil

Up to date I've been using the drive on both AMD SB850, Intel Z68 and X58 based motherboards and none of them have been successful, in the end the drive disconnects.

---

Anvil have you tried running different brand SFxxx drives on the mobo’s that have experienced problems when using the Corsair drive? SF2xxx drives might use either a reference or propriety board. The NAND type/ manufacturer will also provide a variable, so it would be interesting to see if one SF brand worked and another did not.

Also have you tried running non SF brands on the mobo’s that have experienced problems with SF drives?

Quote:

---

Originally Posted by bluestang

@Anvil
You might want to check/get in touch with stasio and Lsdmeasap and let them know what you are trying to do and why. They are both GB gurus and extremely generous with their help. I think they might be willing to help you out in being able to mod the BIOS's yourself.

---

Will do although I,ve managed to find option rom modded bioses for all my X58's, that still leaves the Z68's and a P67.

@Ao1

Sure, all system are running with loads of drives including SSD's.

The ASRock Z68 boots off a Vertex 120GB (gen1) and is also hosting the Kingston used in the Endurance test.
The AMD boots off a WD SSD and hosted the Kingston from early June up until the SF drive caused issues, about a week ago. (The AMD acts as a server and hosts 8 HDD's in raid)
There was an issue with the Kingston on the AMD but the issue was not reproducible.

The X58 I used for the short test which resulted in 51 hour runtime for the Force 3 is my main workstation with loads of SSD's, the X58 I have prepared for further tests currently boots off a Corsair Force GT 120GB.

edit:
The second Z68 is the ASUS M4E-Z, it's booting off 2R0 Crucial m4.

--

The Force 3 is still running, it is close to 65 hours and more than 24TiB is written during this session.

So the builds are stable with other HDD's/ SSD's (?) If the F3 (as an example) is problematic on one particular set up is an V3 (or any other SF2 drive) also problematic on the same system? If you had more than one F3 would they both play up on the same system or would only one of them be a problematic?

Quote:

---

Originally Posted by Anvil

Will do although I,ve managed to find option rom modded bioses for all my X58's, that still leaves the Z68's and a P67.

---

Which P67 model?

I was hoping for more out of the new changes, but like clockwork it just can't handle more than about 30hrs. My drive dropped out this morning. Its just a fact of life now. 30hrs is the ceiling, and its going to happen every time.

What I wonder is why only 2/3s of 1% of 2281's have this problem (according to OCZs stats on their drives). Why don't all 2281s disconnect and BSoD if its the fault of the platform? Now with the progress the Force 3 has made, maybe 11 oroms are the way out of this.

Maybe I should just reboot after every 24hr update...

Quote:

---

Originally Posted by bluestang

Which P67 model?

---

It's the original Asus P8P67 Deluxe (rev 1), I have not exchanged if for the B3 yet.
I'm more interested in getting OROM updated on the Z68's but the P67 would of course be great as well :)

Quote:

---

Originally Posted by Christopher

I was hoping for more out of the new changes, ...

---

What did you change?
The one and only thing I have changed is that I have disabled all Power savings, nothing else has changed.

The Force 3 is currently at 71.5 hours.

Quote:

---

Originally Posted by Ao1

So the builds are stable with other HDD's/ SSD's (?) If the F3 (as an example) is problematic on one particular set up is an V3 (or any other SF2 drive) also problematic on the same system? If you had more than one F3 would they both play up on the same system or would only one of them be a problematic?

---

All systems are stable, the X58 that boots on the Force GT is an exception, will know for sure over the weekend, it's currently sitting there waiting for the Force 3 to fail. I won't stop the Endurance test on the F3 until it's either past 100 hours or it disconnects.
So, when that happens the X58 will host 2x SF-2281 drives.

If it doesn't disconnect I might have to consider making the Force GT the boot drive on the ASRock.
(I wasn't expecting the F3 to last this long...)

Quote:

---

Originally Posted by Anvil

What did you change?
The one and only thing I have changed is that I have disabled all Power savings, nothing else has changed.

The Force 3 is currently at 71.5 hours.

---

I updated to the 2053 UEFI revision for my Intel DP67BG(B3). To do this, I had to remove the nVidia GPU and swap in an AMD, and have to downclock the ram to 1067MHZ. It won't even boot with the ram at 1333 or higher. It has a slightly different OROM, and I was thinking maybe something would help, but it didn't -- still 30hrs. I've changed Windows 7's power scheme to performance from balanced, and next time I reboot I'll try disabling cstates/eist/speedstep/turbo, and possibly anything else with an off switch :shrug:.

I'll probably just wait until the drive disconnects again, so probably around this time tomorrow.


If the Force 3 refuses to disconnect, just leave it where it is.... just put a glass case around the system, and write "DO NOT TOUCH" in red lipstick...

Maybe disabling EIST helps indeed. Jumping from one speed to another adds additional stress on voltage regulator (and also power supply) and some components might not like it too much. Or maybe there are also other internal lines that are reduced.

There looks to be a connection, but why would that lead to issues with the SF-22XX drives while others are more or less unaffected.

I'll be playing with the Power settings, there are plenty of factors/settings that can be reactivated.

I prefer enabling power savings and so this is not something I can live with but lets see how it develops, I wish I had more drives, that way one could try different settings and the process could be done in days in stead of weeks.

Attachment 120942

Robustness principle, "Be conservative in what you do, be liberal in what you accept from others" is not respected most probably by Sandforce and this would explain why it works with other drives. I would be curios to find out which party initiates the disconnect: SSD or chipset?
Also, I was thinking, EIST enabled might lead to higher variations in 5V and 12V lines as CPU goes suddenly from a low load to a high one. Do you have an oscilloscope to check the lines and record max variation during a period of a few hours?

Hmmmm...

I've had two crashes in the past twelve hours since adjusting the power settings in the UEFI. Turning everything off (speedstep, eist, C states, etc.) seemed to make matters worst. I was a little surprised as I thought it would make no difference.

My system, while running ASU, is always at idle. It doesn't spike up (that I know of), it's just always at idle. Now with it running with no C cstates or eist/turbo I get even more instability.

Not sure where to go from here.

Are you 100% sure you have made all the necessary adjustments?

CPU-Z should show no signs of power saving, VCore and Core speed should not "move" at all.

Quote:

---

Originally Posted by sergiu

...
Do you have an oscilloscope to check the lines and record max variation during a period of a few hours?

---

Unfortunately, No.

I'll try to get hold of one early next week.

Yes, I did it right :)
I verified that it was idling at the max non turbo multi, and performance power profile was set (with the change that drive sleeps: never)

I'll reboot and try again (for some reason, after I flashed back to the 2040 UEFI, the spash screen lasts for about 2/10s of a second.... I actually have to use a jumper to get into the UEFI now... seriously, power on to desktop is like 8 seconds now). Now the UEFI has been changed back to power savings (Cstates/eist/turbo/etc.) but the power plan is still high performance, but the CPU speed changes from 2.49mhz to 3.29mhz frequently (with a default 99.8 base clock, can't adjust it with anything other that whole increments, not tenths like many boards).

With regards to the oscilloscope, I think it's a good idea. I've got a fairly high quality power supply (A Seasonic 80+ Gold X 650). It has pretty tight voltage regulation, but it's a 650 watt power supply. I'm idling at 3.3GHZ and it's still only pulling 47w from the wall. I'd be surprised if the PSU doesn't have trouble operating at such a low percent of it's rated output. As far as I can tell, at 47w from the wall, 12w is wasted as inefficiency and maybe I should try a smaller capacity PSU... I've heard that some people have swapped PSUs and couldn't get the SF problem to reappear.

EDIT
Maybe dropping power savings allows the PSU to operate in the sweet spot, where regulation is tightest.

There are a lot of variables.

I haven't decided on how to continue yet, I might start off by changing the multiplier back to 48x again and let it run until it's past the normal disconnect period (30-33 hours), or I might try keeping C states disables but reactivating the other settings.

I'm not sure about the PSU in the ASRock, it's 750W and it's not a cheap one, it's not Corsair though.
The other PSU's are mostly Corsair or Seasonic, 750-850W. (HX and/or AX)

I have a noisy, mediocre, 500W OCZ Modular PSU. If I can put up with the awful noise, I could try it. Maybe SF2281s need bad power supplies, not good ones........ probably not, but if something changes, it'll be a place to start.

Quote:

---

Originally Posted by Christopher

Yes, I did it right :)
I verified that it was idling at the max non turbo multi, and performance power profile was set (with the change that drive sleeps: never)

I'll reboot and try again (for some reason, after I flashed back to the 2040 UEFI, the spash screen lasts for about 2/10s of a second.... I actually have to use a jumper to get into the UEFI now... seriously, power on to desktop is like 8 seconds now). Now the UEFI has been changed back to power savings (Cstates/eist/turbo/etc.) but the power plan is still high performance, but the CPU speed changes from 2.49mhz to 3.29mhz frequently (with a default 99.8 base clock, can't adjust it with anything other that whole increments, not tenths like many boards).

---

The speed change you described is the variation you see to the default speed in Mhz? or it is the real speed switching from 2.49Ghz to 3.29Ghz. If it is the last one, then EIST is still enabled. Another thing to concern... most PSUs from today are focusing on 12V line. I guess SSDs are usually taking power from 5V line, as it is closer to their needs. It might be the difference between SSDs as others might use 12V instead of 5V one.

Don`t know if someone can reproduce it, but on my Vertex3-480 :
During setup, and Win install I had it on a Molex to Sata lead(no orange lead) and halfway the install, it shut down, several times.:eek:

Now hanging on a true Sata lead, it`s up and running for 76 hours.:)
(X58)

Quote:

---

Originally Posted by sergiu

The speed change you described is the variation you see to the default speed in Mhz? or it is the real speed switching from 2.49Ghz to 3.29Ghz. If it is the last one, then EIST is still enabled. Another thing to concern... most PSUs from today are focusing on 12V line. I guess SSDs are usually taking power from 5V line, as it is closer to their needs. It might be the difference between SSDs as others might use 12V instead of 5V one.

---

Yes, but the Seasonic X series uses DC to DC for the 3.3 and 5v rails.

Yes, EIST/Speedstep and Turbo are now enabled... but performance power mode is too. With all the power saving functions off, it was just sitting at the max non turbo ratio as it should.

I'd turn off TRIM if it didn't result in positively awful avg speeds. I'd be better off just living with the disconnects than running without TRIM. If I were having these problems but not trying to write 10+ TB a DAY, I'd not expect turning off trim to have much of an effect.

Quote:

---

Originally Posted by XII

Don`t know if someone can reproduce it, but on my Vertex3-480 :
During setup, and Win install I had it on a Molex to Sata lead(no orange lead) and halfway the install, it shut down, several times.:eek:

Now hanging on a true Sata lead, it`s up and running for 76 hours.:)
(X58)

---

That's a very important piece of information. Orange line is 3.3V which is probably most neglected by PSU manufacturers as from P4 days, most power is taken from 12V lines. I have not noticed until now that SATA power cable has 3.3v line and when I search for specs, I found that this line is optional and might not be implemented in all PSUs.

Quote:

---

Originally Posted by XII

Don`t know if someone can reproduce it, but on my Vertex3-480 :
During setup, and Win install I had it on a Molex to Sata lead(no orange lead) and halfway the install, it shut down, several times.:eek:

Now hanging on a true Sata lead, it`s up and running for 76 hours.:)
(X58)

---

During the Windows install, I think it's common since you can't turn off LPM (unless you have it in the BIOS).

You'll have to try it multiple times or just clone another drive to get Windows on the drive, then make necessary tweaks.

Maybe I should try it WITH a molex to sata connector. With my most successful setups with two motherboards, I can't get more than about 30hrs. If I try it with a new PSU or maybe just a molex to sata, something could possible change. I'm going to take a few hours to figure out how to proceed, the tonight I'm going to post my Mushkin Update of the Day, then swap some stuff around.

Quote:

---

Originally Posted by Christopher

Yes, but the Seasonic X series uses DC to DC for the 3.3 and 5v rails.

Yes, EIST/Speedstep and Turbo are now enabled... but performance power mode is too. With all the power saving functions off, it was just sitting at the max non turbo ratio as it should.

---

I personally trust a PSU only if it passes the oscilloscope test. I had a bad experience with a "good" PSU in the past. Also, to check if the issues are related to power saving features/ power lines, could you keep one or more cores from your CPU busy with a CPU torture program like Prime95 or any other one while running the endurance test? This should keep the power consumption relatively stable and allow for a much better regulation.

Quote:

---

Originally Posted by sergiu

I personally trust a PSU only if it passes the oscilloscope test. I had a bad experience with a "good" PSU in the past. Also, to check if the issues are related to power saving features/ power lines, could you keep one or more cores from your CPU busy with a CPU torture program like Prime95 or any other one while running the endurance test? This should keep the power consumption relatively stable and allow for a much better regulation.

---

I've been considering that very solution. Except that I was thinking at the 12 - 18 hour point I start Prime95. My system doesn't get louder (or much warmer) under prolonged CPU loads, so I won't be able to tell by listening (Which is how I like it -- quiet.) The Noctua U12 SE2 is highly recommended by me if you dig quiet. It's great for Sandy Bridge processors with just one fan at 800-900RPM, even with a substantial OC.

EDIT
Maybe I'll just try running P95 tonight as the Mushkin's only been running for a few hours now. If I can make it through the night, I'll just leave it until it A)disconnects or B) I get tired of it running P95 all the time (I was thinking all 4 cores, but one/two might be sufficient and leave me with some spare cycles for when I need to use the system.)

Quote:

---

Originally Posted by Christopher

During the Windows install, I think it's common since you can't turn off LPM (unless you have it in the BIOS).

You'll have to try it multiple times or just clone another drive to get Windows on the drive, then make necessary tweaks.

Maybe I should try it WITH a molex to sata connector. With my most successful setups with two motherboards, I can't get more than about 30hrs. If I try it with a new PSU or maybe just a molex to sata, something could possible change. I'm going to take a few hours to figure out how to proceed, the tonight I'm going to post my Mushkin Update of the Day, then swap some stuff around.

---

The Molex to Sata, is what gave me the trouble. Power comes from a AX1200, on a Sata now.
After the first reports on Anand, I sent him a mail, with a request if he could verify, but never got response.

I had a bad molex to sata that I put in a friend's computer. Caused no end of problems, but the only reason I used it was because it was a really unconventional case style and made cable routing much easier. It would just cut out power to the drive, and this screwed up the Window's install. So I could see that happening. I don't see too many people using a molex to sata with a 480GB Vertex 3 though... probably not likely.

Quote:

---

Originally Posted by Christopher

I had a bad molex to sata that I put in a friend's computer. Caused no end of problems, but the only reason I used it was because it was a really unconventional case style and made cable routing much easier. It would just cut out power to the drive, and this screwed up the Window's install. So I could see that happening. I don't see too many people using a molex to sata with a 480GB Vertex 3 though... probably not likely.

---

It was a temporary setup, as I wanted to do it quick. To the Molex line, the casefans were connected, and a free one.
All Sata`s were used. Laziness bites your ass :D

I'm thinking about just trying another motherboard; If it doesn't help the Mushkin's stability, at least I'll have another board to play with.

Thinking about the Maximus IV Gene-Z... a lot.

I guess in about 20hrs I'll know whether I'm currently making any progress as it stands now, so I suppose I can wait to place an order until tomorrow night/Monday morning.

I ended up letting it idle for 12 hours, no change at all to WR Delta, power on hours still looks to double while idling?

It is now running on the X58 with the 11.x orom and the alpha RST 11.xx as well.
Power savings are disabled on this rig so if it works out it should go well past 33 hours w/o issues.

WRD has gone from 57 to 56 in 4 hours so it's still decreasing.

It looks like someone was able to get a Maximus IV Gene-z BIOS from an Engineer at ASUS which had the 11.x in it, and I'm trying to figure out if there are some tools you can use to add it to UEFIs, or if it has to be a regular BIOS. I'm trying to sift through about 900 forum posts to figure this out, so it might take a while, but I think I'm going to order the board anyway. Of course, if the 11.x orom could just be inserted into any UEFI, I could just use the boards I've already got laying around. If anyone knows a way to put 11.x into an Intel DP67BG UEFI, that would be supremely cool.

EDIT
After the last changes I made, I'm already sitting at 30.5 hours without crashing. In another 90 minutes it'll be a record for me, so that's positive.

Haven't posted here in quite a while :)

I have an OCZ V3 ( with stability problems ofc ) and I've noticed that E9 has skyrocketed since I've installed the latest FW ( 2.13 ). In fact it's now bigger than F1, while ~10 days ago ( when I was on 2.11 ) it was at 87% of F1. Has anyone else noticed a similar behavior in 1.3.2 from Corsair or in 2.13 from OCZ ? ( I'm not sure if any other manufacturers released newer FWs lately ).

Quote:

---

Originally Posted by scorp

Haven't posted here in quite a while :)

I have an OCZ V3 ( with stability problems ofc ) and I've noticed that E9 has skyrocketed since I've installed the latest FW ( 2.13 ). In fact it's now bigger than F1, while ~10 days ago ( when I was on 2.11 ) it was at 87% of F1. Has anyone else noticed a similar behavior in 1.3.2 from Corsair or in 2.13 from OCZ ? ( I'm not sure if any other manufacturers released newer FWs lately ).

---

So your V3's writes to NAND (E9) have gone up substantially, so much that actual writes to NAND are now outstripping host writes(F1)???

I don't think that's possible. In a worst case scenario where you workload is 100 percent random, F1 and E9 should be the same and increase at the same rate. You can't have more writes to NAND than you have in host writes. Most of the time writes to NAND should be between ~75 to ~85 percent of host writes. I could see why you'd be alarmed though...

Unless your workload has some crazy amount of write amplification, and that amplification shows up in NAND writes (I don't think it does), I don't see how it's possible without some sort of error. With SF, your WA should be well below 1 on a client system, and in reality it should be around .7 with Windows.

Can you post a screen shot from CrystalDiskInfo?

There are no such issues with my 1.3.2 FW.

I have seen the issue though, on an early firmware and in my case it was on a Vertex 2.

I'd give it a few days and reflash the drive if it doesn't change.

I'm not sure that 2.13 = 1.3.2 but it's very likely.

My work pattern hasn't changed at all. The PC is very lightly used ( mainly browsing with Chrome, reading emails with Thunderbird; all the games are installed on another SSD / HDD ). It's not that I'm really worried, but I think this might be some kind of a "fix" for the stability issues, a bug in the FW ( probably affecting the reporting ).

Quote:

---

Originally Posted by Christopher

I don't think that's possible. In a worst case scenario where you workload is 100 percent random, F1 and E9 should be the same and increase at the same rate. You can't have more writes to NAND than you have in host writes.

---

Try running uncompressible 4K random writes and you will soon see that NAND writes can exceed host writes :) WA & WL can offset savings in compression. For most people the value will be below 1, but with certain workloads it can be higher. (I've seen as high as 3.3)

It's entirely possible that I get small writes on the drive. This morning I had E9 at 232 and F1 at 227. In the meanwhile E9 got to 235 and F1 to 228, hence writting ~3G on the NAND for only 1G of actual data.

Quote:

---

Originally Posted by Anvil

:)

Lets hope it works out and is reproducible!

---

The reproducible part is what I'm aiming for...

But at this point, I have a SF2281 which will disconnect like clockwork every 30 hours (or I can get it to disconnect earlier). If.. and I say again... IF I can get the Mushkin to:

A) Remain stable for a few more days with the changes I've made (I'm well past my previous record)

AND

B) Get a disconnect with the new motherboard I have on the way on the same time frame (as the P67 and H67 boards)

THEN

C) I think I'll have something interesting going on here.


All power saving and turbo technologies are enabled, current power draw at the wall is 47w.

Using RST 10.6 drivers, Intel DP67BG with 2040 UEFI revision.

Unfortunately, even if (and that is a big IF) I can get the drive to be stable, I'm worried that I might have also changed something without knowing, and won't be able to reproduce the error. So if the drive crashes soon I don't have that problem. If it doesn't, then how long should I wait? 60 hours? 80?

Quote:

---

Originally Posted by scorp

It's entirely possible that I get small writes on the drive. This morning I had E9 at 232 and F1 at 227. In the meanwhile E9 got to 235 and F1 to 228, hence writting ~3G on the NAND for only 1G of actual data.

---

Are you sure your drive is properly aligned? If you run AS SSD, does it say "1024K OK" in green text (or some multiple of 1024 - OK)?

If the drive is sector aligned and not 4K aligned, this could account for the write amplification if that's what is going on.

AS SSD download page (it is at the bottom)
http://www.alex-is.de/PHP/fusion/dow...&download_id=9

Attachment 121048

Are you guys deploying either of the Toshiba Toggle NAND drives (Wildfire and MAXIOPS)? I had all sorts of issues with the vanilla Vertex 3, but the MI drive has given me no issues. Obviously that's nothing scientific, and since OCZ is the only vendor using LTT (right?), there's no way to test it.

Quote:

---

Originally Posted by squick3n

Are you guys deploying either of the Toshiba Toggle NAND drives (Wildfire and MAXIOPS)? I had all sorts of issues with the vanilla Vertex 3, but the MI drive has given me no issues. Obviously that's nothing scientific, and since OCZ is the only vendor using LTT (right?), there's no way to test it.

---

I'm using the Mushkin Chronos Deluxe 60GB, which is like a 60GB Wildfire or MaxIOPS. 60GB of Toshiba 32nm Toggle NAND. Anvil is using the Corsair Force 3 120GB with asynchronous Micron 25nm.

With respect to lifetime throttling, it isn't clear who is using LTT and who isn't, except to say that Mushkin and Corsair don't use it, so I think that all the drives using reference SF FW do not have LTT. OCZ may or may not still use LTT, but I have no way of knowing.

Mushkin, Patriot, OWC, Edge, and a few others all have their drives assembled in America and all use the same firmware. A Patriot Pyro and a Mushkin Chronos vary only by the label of the front of the case.

I have heard that the Toggle equipped drives were better in this respect, but people have been saying a lot of things about SandForces. OWC switched their 2281 Synchronous equipped SF SSDs to Toggle NAND and are using the 2282 processor in the 240GB version.

Oh I didn't know the Mushkin drives used the toggle NAND as well. Guess you have ruled out that NAND then.

Quote:

---

Originally Posted by squick3n

Oh I didn't know the Mushkin drives used the toggle NAND as well. Guess you have ruled out that NAND then.

---

Mushkin has the Chronos and the Chronos Deluxe. The Chronos line is asynchronous IMFT 25nm NAND. The Chronos Deluxe is 32nm Toshiba Toggle NAND. Both drives come in the same retail box and the labels on the drives look the same as well. Mushkin is the only company selling in America that has a 60GB Toggle NAND 2281.

Mushkin Chronos, OCZ Agility3/Solid3, Corsair Force, OWC Mercury 6G = IMFT 25nm Asynchronous

Corsair Force GT, OCZ Vertex 3, Older OWC Mercury Pro 6G, Kingston HyperX = IMFT 25nm Synchronous

Mushkin Chronos Deluxe, Patriot WildFire, newer OWC Mercury Pro 6G, OCZ MaxIOPS = Toshiba 32nm Toggle NAND

Thanks for the info. I really enjoy the performance of the MI, but if there are comparable drives out there w/o LTT, I might look in to those

Quote:

---

Originally Posted by squick3n

Thanks for the info. I really enjoy the performance of the MI, but if there are comparable drives out there w/o LTT, I might look in to those

---

Have you been throttled with your Max Iops?

I don't think it should ever be much of a concern unless you're writing.... I don't know exactly, but probably a few hundred GB a day. Maybe even more, but I don't think we have confirmation that the Max Iops or Vertex 3 have LTT to begin with. If you aren't having problems with you MI, I say leave it.

Oh I've had no problems. But I occasionally do some heavy video editing, and don't like the unknown nature of LTT.

As time goes on, you'll have less and less to worry about. If your system is always on but you only use it part of the day you should accumulate enough power on hours. It might not have it at all, and I think you just need to look at the smart data. If life curve stays at 100, you don't have LTT. Someone else like Ao1 might be able to verify this (I could be completely wrong).

Well, it just rebooted.

The interesting thing here is that it wasn't the Force 3 that disconnected, it was the boot drive (Force GT) and it is still running FW 1.3.

So, a bit annoying as it was past 27 hours, the Force GT had been online for 72 hours when it disconnected.
I had to cold boot as it wouldn't show up having performed several warm-boots.
It's time to upgrade to Force GT to the latest firmware.

I had hoped the Force GT would sort of confirm that it was stable (as it had been online for quite some time) but apparently not, at least not on the 1.3 FW.

I didn't know you were running both Corsairs on the same system, but I have a hard time just keeping up with one...

The Force GT is just the boot drive, there's no testing except for mostly idling which looks to be a test on it's own.

The Kingston (X25-V) is back online on the X58, the Force 3 has been offline while deciding on what to do next.

I knew you were not testing it, but I didn't know you had two SF2281s in one rig. I think idling is the opposite extreme of the endurance test anyway for SF2. On my system, I've been writing about .7 to 1.2 GB a day on the system drive. I was using my Intel X25-E, but cloned that to my Vertex Turbo 128.

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive. Maybe SFs aren't limited by the NAND endurance overall, but perhaps they keep wearing out the same NAND device from storing all the associated SF data. If it didn't adequately rotate where it stored all the data necessary to make SF work, maybe writing millions of files is more detrimental than just writes to NAND.

Quote:

---

Originally Posted by Christopher

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive. Maybe SFs aren't limited by the NAND endurance overall, but perhaps they keep wearing out the same NAND device from storing all the associated SF data. If it didn't adequately rotate where it stored all the data necessary to make SF work, maybe writing millions of files is more detrimental than just writes to NAND.

---

I guess SF data is specific to a number of pages (like keeping parity data for 8 pages in a separate and complete page) so it should not matter too much the number of files. Also, most probably pages are grouped so writing pattern should also not impact the usage. Sandforce advertise the fact that internal data is spread thru all dies for better redundancy. It might be very sad to find out that this is not true

Quote:

---

Originally Posted by sergiu

For a SSD, it should be no difference other than WA between writing one file and writing one million, as writing file system metadata is still just a write request, just like any other. It would be possible for a SSD to "know" about OS filesystem but that would be "suicide" as that model would be tied to a specific file system and thus to a specific family of OSes.

---

The SF has to keep tables of information and I guess hash data, that gets written in conjunction with NAND writes. If it writes this info to the same area without rotating it, couldn't it wear out that nand from constant writing since it's not keeping this info in flash? Maybe I'm grossly overestimating the amount of data this is, but if it's always writing this information to the same physical nand device, maybe it could put disproportional wear on one nand device vs. the others - forget the file system, but maybe this data is a different amount based on the compressibility of the written data, or something. Maybe it's different for smaller capacity drives that don't have a whole die's worth of nand sacrificed.

I'm not really smart enough to know much about that, but I wonder if SF drives might have additional reasons to not wear in the same fashion as non-SF controlled drives. So far, wear to non-SF drives has been pretty linear. Perhaps there is something else going on behind the scenes with SF that would make them not wear out in the same linear manner.

There are a lot of possible variations, indeed. Another thing is that we do not know for sure different internal details. We can only guess based on behavior but we might be far from truth. Now either way, the overhead cannot be so high to seriously impact the wear. At zero fill for example, it has a compression rate of ~13% and what I always assumed is that a big part of these percents are actually the overhead.

The Mushkin team just released some new standard SF firmware. 3.3.0, so I'd assume that other vendors will have it out as well. The poses a dilemma as I've just found stability.

EDIT
I can't tell you how irritating it is the SF fw releases can't have changelogs... even some really basic information would be helpful.

Many users are going to want to try the new fw even if they don't have problems, but at least some of those people are going to get instability for the first time if history is any indication.

Even Intel will tell you (sometimes) what the new FW is for... like adding TRIM, or the last 320 Intel FW to fix the 8MB Bug.

Quote:

---

Originally Posted by Christopher

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive.

---

I don't think that is true. They may not cache host data in DRAM, but I think that they keep some metadata in DRAM. That is similar to how the Intel 320 SSDs work -- they also do not cache host data, but they do have a small DRAM for holding metadata.

By the way, remember that some of the higher end Sandforce SSDs have/had a supercapacitor for backup power. There would be little reason for a supercapacitor if there was no information stored in volatile memory.

Quote:

---

Originally Posted by johnw

I don't think that is true. They may not cache host data in DRAM, but I think that they keep some metadata in DRAM. That is similar to how the Intel 320 SSDs work -- they also do not cache host data, but they do have a small DRAM for holding metadata.

By the way, remember that some of the higher end Sandforce SSDs have/had a supercapacitor for backup power. There would be little reason for a supercapacitor if there was no information stored in volatile memory.

---

That's a very good point.

With a 120GB Toggle Nand equipped 2281 you will end up with 111GB, with almost 17GB worth of over provisioning and one die given up for the RAISE scheme (and supposedly other SF related needs). It is said that the SF processor has some internal cache, but probably not very much, so who knows?

I'm way more excited by almost hitting the 60hr mark with the Mushkin. If I can hit 75 or 100 hours I'm going to "undo" the changes I've made, and see if I go back to having crashes every 30 hours (or earlier if I want... I can get it to happen whenever I want, so long as I only want it to happen within 12 hours with MSAHCI, but there's no magic switch to make it happen immediately). 30hrs is with latest official Intel RST drivers for both 1155 motherboards and I have another one on the way to test with as well.

I still maintain that there is something fundamentally flawed with the SF2281s, that all drives will exhibit the BSoD/disconnect issues. I have finally found a fix for the Mushkin, and I'm thinking about getting another SF2281 drive to test. But I would like one with a track record of producing BSoDs, and if I get another new one, I would expect that I could make all three drives (The Mushkin, a used drive with a BSoD record, a new retail model) crash or not if I wanted.

Can you tell what fix you applied ? I tried to find it but I couldn't be sure.

Quote:

---

Originally Posted by kensiko

Can you tell what fix you applied ? I tried to find it but I couldn't be sure.

---

I'm still testing it to make sure it's actually a fix, and I'd like to test it some more before I tell everyone about it.

So you didn't miss it, I just haven't told anyone yet. After some more testing, I'm going see if Anvil will try it out.
After I make sure I'm not just imagining this, I'll tell everybody who'll listen.

Kensiko,

Are you having problems with a SF2281?

If so, could you list the full system specs of the system that's experiencing the problems?
I'm just curious, and it might be handy to have some people here with the problem in the future.

Or were you just wondering what the hell I was doing? Because sometimes I wonder that myself...

My days of joy with SF 2281 go like this ( OCZ Vertex 3 120G to be more precise ) - the motherboard is ASUS P8Z68 Deluxe, BIOS 0706; all C-states are enabled ( not AUTO, but actually set to ENABLED ); TRIM is enabled
- 2.11 ( came with 2.06, updated before installing Win on an ICH9R mobo via the Linux tool ) + IRST 10.6: first reboot about 1h after installing Windows ( while Win was installing updates); a BSOD about 6 hours later
- 2.11 ( force-flashed with all the OCZ tweaks via the Linux tool - remove CMOS battery, remove drive power etc ) + IRST 10.6: crashed the next day when trying to boot
- 2.09 ( flashed with all the OCZ tweaks via the Linux tool ) + IRST 10.6: crashed in about 20 hours ( soon after Win 7 started in the morning )
- 2.06 ( flashed with all the OCZ tweaks via the Linux tool ) + IRST 10.6: crashed in about 26 hours ( soon after Win 7 started in the morning )
- 2.11 ( flashed via the OCZ Windows tool ) + MsAHCI ( with the tweaks Tony specified to force the ports to internal ): solid freeze after 10 days ( no BSOD )
- 2.13 ( flashed via the OCZ Windows tool ) + MsAHCI ( with the tweaks Tony specified to force the ports to internal ): running stable for 11 days 20 hours

About the strange behavior of E9; I don't think it's actually a wrong counter; I let it do its thing for a few days and it finally managed to get to a value of F1 + 15; I run an ATTO and now I have E9 at F1 - 4; the daily "writes" ( as shown by SSD Life ) are 22 and as far as I remember ATTO writes around 20 GB; this means that the actual amount of data written to the NAND for ATTO was really small as you would expect it to be; my best guess at the moment is that FW 2.13 has changed the behavior of the GC to make it more aggressive in order to avoid the disconnects ( that generally seem to happen when the FW decides its time to do some housecleaning ).

If you've got your drive running stable, then you should never touch your system again.

I had the worst luck with MSAHCI, but I'm currently running it now to see if it's stable with my Mushkin.

If you've got your drive running stable, then you should never touch your system again.

I had the worst luck with MSAHCI, but I'm currently running it now to see if it's stable with my Mushkin.

The Force GT has been running now for 82 hours and counting.
I moved the Kingston (X25-V) to the Z68 as I needed this rig for other tasks.

I'll keep the Force GT running as longs as I'm able to, hopefully throughout this weekend.

I am not sure if it is the firmware upgrade or the Power saving schemes that has helped on this drive.

The Force GT is still doing fine, up time, 4 days 10 hours 43 minutes
(almost 107 hours)

I'm about to shut down the computer where the Force GT is running, it has been online for 4 days, 21 hours and 46 minutes.
(X58)

Christ. Since when has it become acceptable that we pay massive money for uncomplete unreliable hardware.

Quote:

---

Originally Posted by Etihtsarom

Christ. Since when has it become acceptable that we pay massive money for uncomplete unreliable hardware.

---

Well, if some asks me what is the best drive to get, I might not recommend a SF2281 -- but most people don't have these problems. I think the numbers of people who experience this problem is larger than what is generally said to be the problematic population (OCZ claims 2/3 of 1 percent...), but not more than 5 percent probably. It's clearly a fault of the drive, and it's difficult to track down what it is about your system the drive doesn't like. I knew this might happen when I got the drive to endurance test, so I can't really say that I'm torn up about it. I've had success getting the drive to act right, but remember, in the endurance test 10,500GB are being written per day to my drive (if it doesn't crash) so that's pretty stressful. If you have anger management issues or need a reliable system... don't use a SF2281. If you need a fast drive and are willing to put up with some possible problems, then you could consider getting one. The Intel 510 and Crucial M4 are still awesome. The new SATA III Samsung drives aren't available in America yet, and Intel's next SATA III is supposed to come out next month, so your non-SandForce 2281 options are not numerous at this point. It's not like the drives are eating your data, they'll just drop out every once in a while.

The SF2281 drives with Toggle NAND are worth the aggravation in my opinion.

Double post

Oh, great, a dedicated thread; dunno how I missed this :) Anyway, I'll include my previous post for good measure:

"Having an SF-22xx drive myself, I've been especially interested in this aspect of the thread. I've owned a Force GT 120GB for a bit more than a month now and I've had crashes with the drive disappearing from BIOS two times only. While not much compared to other folks, it's still annoying, and maybe even more annoying knowing I've got a... fragile... piece of hardware with the potential to cause trouble when it feels like doing so.

So, may we have a recap on the SF issue and can you say anything concrete on the matter in terms of causes/workarounds at this time?

Also, I don't mind helping out if you have some specific BIOS settings/workloads/etc to try out if it brings the world closer to solving the infamous SF problem. This is my only PC tho and it's not running 24/7, so I may not have the same resources but I'll do what I can if needed.

What I have observed around the SF bug myself is that it's only happened during an overclock with an OFFSET vcore while running the BOINC client with the specific settings of 100% CPUs used and 60% CPU time. This configuration results in an erratic load on the processor going literally from 0% to 100% and back down to 0% in under a second with the vcore being thrown around like mad. The first time it crashed within 2 hours of this load and the second time it happened within 10 hours of this load. C3/6 states disabled, altho C1E and EIST have been enabled.

At the moment I'm testing the same CPU workload but with a static vcore."

My system specs are:
2600K
Gigabyte GA-Z68X-UD4-B3 (oROM 10.6.0.1091)
8GB Corsair Vengeance C8
Force GT 120GB (FW 1.3.2) as systemdrive restored from an HDD image of Win7 (alignment is ok)
IRST 10.6.0.1002

I should mention that I haven't experimented with any voodoo like reg hacks, modded BIOSes, uninstalling/disabling MEI or even MS default SATA driver. I've pretty much only updated FW of my drive after the second crash and haven't had any crashes since, but I also have not tried provoking it with the conditions I mentioned earlier.

Quote:

---

Originally Posted by FoLmEr

Oh, great, a dedicated thread; dunno how I missed this :) Anyway, I'll include my previous post for good measure:

"Having an SF-22xx drive myself, I've been especially interested in this aspect of the thread. I've owned a Force GT 120GB for a bit more than a month now and I've had crashes with the drive disappearing from BIOS two times only. While not much compared to other folks, it's still annoying, and maybe even more annoying knowing I've got a... fragile... piece of hardware with the potential to cause trouble when it feels like doing so.

So, may we have a recap on the SF issue and can you say anything concrete on the matter in terms of causes/workarounds at this time?

Also, I don't mind helping out if you have some specific BIOS settings/workloads/etc to try out if it brings the world closer to solving the infamous SF problem. This is my only PC tho and it's not running 24/7, so I may not have the same resources but I'll do what I can if needed.

What I have observed around the SF bug myself is that it's only happened during an overclock with an OFFSET vcore while running the BOINC client with the specific settings of 100% CPUs used and 60% CPU time. This configuration results in an erratic load on the processor going literally from 0% to 100% and back down to 0% in under a second with the vcore being thrown around like mad. The first time it crashed within 2 hours of this load and the second time it happened within 10 hours of this load. C3/6 states disabled, altho C1E and EIST have been enabled.

At the moment I'm testing the same CPU workload but with a static vcore."

My system specs are:
2600K
Gigabyte GA-Z68X-UD4-B3 (oROM 10.6.0.1091)
8GB Corsair Vengeance C8
Force GT 120GB (FW 1.3.2) as systemdrive restored from an HDD image of Win7 (alignment is ok)
IRST 10.6.0.1002

I should mention that I haven't experimented with any voodoo like reg hacks, modded BIOSes, uninstalling/disabling MEI or even MS default SATA driver. I've pretty much only updated FW of my drive after the second crash and haven't had any crashes since, but I also have not tried provoking it with the conditions I mentioned earlier.

---

See, this sounds like system instability, not the GT exhibiting the SF behavior. Why are you so sure that it is the Force GT doing this, and not your system?

The best way to test this out is to use another drive as the system drive and the Force GT as a secondary drive. This way you can isolate the issue, as my Mushkin Chronos Deluxe as the system drive would crash the whole system when it became unstable. As a secondary drive, the drive just disconnects and your system will still do whatever -- unless it's your motherboard not keeping up Vcore, in which case it's not the drive.

Quote:

---

Originally Posted by Christopher

See, this sounds like system instability, not the GT exhibiting the SF behavior. Why are you so sure that it is the Force GT doing this, and not your system?

The best way to test this out is to use another drive as the system drive and the Force GT as a secondary drive. This way you can isolate the issue, as my Mushkin Chronos Deluxe as the system drive would crash the whole system when it became unstable. As a secondary drive, the drive just disconnects and your system will still do whatever -- unless it's your motherboard not keeping up Vcore, in which case it's not the drive.

---

I assumed it was the disk as I had the SF behavior people describe just prior to the crash: one ~30 sec freeze followed by an X second period of applications stop functioning one by one followed again by the F4 BSOD. That is, as I see it, the disk disconnecting prematurely. It really leaves little doubt as to what's happening if you ask me.

The other time it happened, I just had like a frozen 640x480 rectangle sliced out from the middle of my desktop with the mouse cursor being double the size of normal. I had a black background at that time so if I hadn't had the cursor shown, I'd just have thought it was a black screen. It points me in the direction of the graphics driver breaking due to the disconnect and then it didn't even make it to the BSOD, but simply froze. I've seen people report this as well on the SF issue. Disk didn't show up in BIOS afterwards. I haven't had that disk disappearing behavior on failed OCs ending in BSOD.

Also, the system running overclocked had been stable for 4 weeks until I started playing with offset vcore, whereafter I see the SF disappearing behavior.

I'm not knowledgeable in this area, but could the erratic load/vcore disturb the SATA signal, making the SF crap out? Also, I hadn't disabled LPM at that time, could that play a part too?

double post

Well, some have found that disabling the power saving features help stability. Then there are another class of SF2281 issues that I've experienced that are caused from Anvil Storage Utilities it seems, as during file deletion more of a pause is needed or the drive disconnects. That's probably not what's happening in your case as this is most likely limited to endurance testing. I found that ASUs pause wasn't long enough until I was generating more than 10000 files per loop. So that's another issue.

I know from experience that if you drop the System Agent and/or PCH voltage low enough that you'll get crashes. This is total speculation, but you could try increasing those a few notches in your BIOS.

Yeah I'm not so fortunate as to have a mainboard where the MCH voltage is actually adjustable I'm afraid. It totally shocked me when this turned up as a possible solution and I have no idea why Gigabyte didn't include this in their BIOS.

I might play around with the System Agent voltage, but for now I haven't established if it's the 1.3.2 FW or static vcore that keeps the drive running (it HAS crashed with c3/6 states disabled).

Just waiting anxiously for the next crash... :S

Quote:

---

Originally Posted by Christopher

Kensiko,

Are you having problems with a SF2281?

If so, could you list the full system specs of the system that's experiencing the problems?
I'm just curious, and it might be handy to have some people here with the problem in the future.

Or were you just wondering what the hell I was doing? Because sometimes I wonder that myself...

---

Sorry to answer late. No I don't have any SF2281 yet, but I'm going to have one this week. I'm mainly interested for helping people in the OCZ forum and maybe for our server at work, currently running with SF12xx but we are planning to buy another SSD and the SATA 6Gbps may be preferred by the IT guy who ask me for recommendations. Not sure what I will answer yet. But in Canada the OCZ SSD are clearly more competitive in term of price.

My Mushkin will crash regardless of motherboard. I've tried swapping in an Biostar TH67+ H67 and an Asus Maximus IV Gene-z Z68 in place of my Intel DP67BG, and it crashes regardless. Using MSAHCI drivers makes it happen at random (and quickly), but the Intel RST drivers gave me more stability.

Quote:

---

Originally Posted by kensiko

Sorry to answer late. No I don't have any SF2281 yet, but I'm going to have one this week. I'm mainly interested for helping people in the OCZ forum and maybe for our server at work, currently running with SF12xx but we are planning to buy another SSD and the SATA 6Gbps may be preferred by the IT guy who ask me for recommendations. Not sure what I will answer yet. But in Canada the OCZ SSD are clearly more competitive in term of price.

---

The drives with Toggle NAND are the best in my opinion. The Patriot Wildfire, Mushkin Chronos Deluxe, OWC Mercury Extreme Pro 6G, and that small company that no one has ever heard of... what's the name... oh yeah, OCZ has the MaxIOPS.

They're all around the same price as one another, but every once in a while you can find some good deals on the WildFire and Chronos DX, and sometimes the MaxIOPS. If you're going to get a SF2281, then one of those are what you want. Otherwise, just get a Crucial M4 or something.

Guys, firmware 2.15 just came out for OCZ, it will probably get for the others soon too.


Changes:

Fixed a rare condition that may cause Windows Blue Screen error when the primary-configured drive woke up from either a SATA slumber mode or S3/S4 modes
Fixed a rare condition that may cause Windows Blue Screen error when the drive was configured as primary with OS installed
Fixed a corner-case issue that may cause the drive to stutter or Windows freezing screen when a media read error occurred
Further improved robustness of Secure Erase operation to prevent possible low-level data structure corruption
Significantly improved TRIM handling to enhance system stability

Vertex 3 series, Vertex 3 Max IOPS series, Agility 3 series, Solid 3 series Known open issue:

Formatting a RAID1 volume takes longer than expected with PMC-Sierra BR-8 HBA

http://www.anandtech.com/show/4973/s...vailable-today

Supposed to be going out to all vendors. Hopefully they've cleared it up. Just in time for Intel's new SSD

Quote:

---

Originally Posted by squick3n

http://www.anandtech.com/show/4973/s...vailable-today

Supposed to be going out to all vendors. Hopefully they've cleared it up. Just in time for Intel's new SSD

---

Yeah I just posted that on the endurance thread.

These people are probably just using ASU to figure out what to fix... If they needed two systems with easily replicated issues, there are two right here.

They should beg me to test their stupid firmware for them... :rofl:

I'm not able to get my Corsairs to disconnect nor BSOD anymore, all settings are back to normal on the Z68.
So I was beginning to wonder what changed, I'm now almost confident that it's the firmware that made most of the difference.
Orom did not seem to matter at all, the one thing that looked to make sense was power related settings.

The question is, does Corsair fw 1.3.2 = SF fw 3.3.2, did they make an early release or is there something more?

Some if my Vertex 3's are still on 2.02 and some are 2.06/2.09/2.13, no issues but it looks like it's time to get all on the same fw.

I agree.

Also, i don't believe that SF isolated this problem, i think they had help. There is a certain someone who is most interested in SF lately...regardless if this is what it looks to be, hallelujah!

Let's hope that *this* is it!
The new SF controller really is good but I can see that some are reluctant and stay away.

The 240GB drives have never caused BSOD's or disconnects for me and that covers both the Intel PCH and the LSI 926X controllers.
I find that strange as all other capacities have caused issues for me at some point, well, maybe I was just lucky?

If you're not having problems anymore, then perhaps you should just stick with what you have... who knows as to what fresh new disorder a FW update could bring to a drive that works?

One can always return to an earlier firmware :)

My confidence is pretty good on the 1.3.2 (Corsair) and so I don't think I'm taking any chances in upgrading the OCZ's.
In the end there's always the sneaking suspicion that something is wrong and so I'm prepared to spend some time verifying that it's stable.

I've got a good thing going on for testing FW here, so if there are any weaknesses... it should pop up. Seriously, you should try dropping the Min free space down on the Force 3 to see if it still crashes under TRIM like the Mushkin.

And I swear that the only way to get a consistent SF fault is to use ASU for endurance testing. Dollars to doughnuts, that's what SandForce had to do to find this magical system.

@Anvil
Are you going for the new firmware when it becomes available for your GT even if the drive has proven stable with 1.3.2 as you suggest is has?

Yes,
I'll definitely be upgrading both Corsair's as soon as the new firmware is available, will most likely do the GT first.

I had a weird experience with my V3 after updating to the new firmware. (Previously the drive has been faultless). Check out the MB/s. With uncompressible writes ASU is normally around 57MB/s. I was getting up to 76MB/s and then bam, for a good 60 seconds ASU became unresponsive and write speeds dropped. Write speeds then went back to 57MB/s. I suspect that a major housekeeping clear up event occurred (GC/ TRIM) mid-way through the loop as I’d been playing with 4K random writes before I started ASU. I'll see if I can reproduce it later.

Attachment 121435