SSD Write Endurance 25nm Vs 34nm

[bluestang]

M225->Vertex Turbo 64GB Update:

414.13 TiB (455.34 TB) total
1136.52 hours
8647 Raw Wear
117.97 MB/s avg for the last 64.32 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) at 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)

[Anvil]

The Corsair is still doing fine on the X58.
It is noticeably slower in 3Gb/s mode but it looks to be stable.

50 hours w/o issues points to that there is something with the drive in 6Gb/s mode or that the drive is having issues with the SnB chipset.
I'll leave it running a few more hours and then I'll update fw + move it back to the SnB rig, if it fails I'll try disabling Hot Plugging.

CDI_2011-10-03-17-06.JPG

Corsair Force 3 SSD_120GB_1GB-20111003-1707.png

[Anvil]

The drive just disconnected, so it took almost 51 hours on the X58.
Not sure what triggered it, a lot of activity on this rig but still it shouldn't disconnect.

I'm about to upgrade the fw.

[deathman20]

Anybody wants to bet the m4 goes all the way to 1PB?

650TB is where im sitting with it, maybe 700TB. Still thats an incredible amount of data written to that drive.

[bluestang]

1PB would be around 15890 P/E cycles at the current rate.

[Christopher]

Since I had to take my desktop with the H67 down for a few minutes last night, the Mushkin's been running non-stop. So all I can say is that it's more stable on the H67, not completely stable. It might only last 40 or so hours uninterrupted -- I can't really say yet.

In the first few days I had the drive, as the boot device, it only crashed once every 30 hrs. After that I moved it to to a secondary position where disconnects were much more frequent -- every night (and every day). At least for the last two days when I check the system in the morning the drive is still working... that in itself is pretty nice, and if I can keep up the pace I'll pass the Force 3 in writes/host writes in a few days. With all the disconnects over night, then the testing in the much slower laptop, I was only getting about 8 - 9 TB a day.

What part of this H67 board is helping is impossible to say. It could be the disabled per-device hotplugging, or advanced link power management (also in the UEFI) disconnected. It could just be that the sata ports themselves are operating in spec or whatever. Who knows? It might not even be stable yet. I just don't understand what the hell is going on -- but I'll know more in a few days.

[Vapor]

Seems to me this app is the most consistent/repeatable usage case for causing SF-2200 failure....

[Christopher]

Seems to me this app is the most consistent/repeatable usage case for causing SF-2200 failure....

I believe so.

What I find most interesting is that most of the blame is placed on power saving chipset functions, like the ability to partially shutdown the drive. Why would a drive operating at 100% go into a power saving mode? I would assume it would happen when the system is idling, as is the drive -- not when the drive is interleaving writes across many devices -- when the drive uses the most power. It really seems like the drive just "gives up" after a while under endurance loads. So if you want to make sure your SF 2281 is actually stable, the best thing to do is endurance test it for months on end...

[sergiu]

If power saving chipset functions are to blame, then a simple solution would be to disable all power saving options possible. This might explain why is so hard to reproduce and why is not affecting all the drives, as this is usually configured differently from one computer to another.

I just realized a funny thing... I have set my laptop on max power profile from the moment I have bought my SSD, as my CPU is undervolted and there is not a significant gain in keeping it running at lower frequencies. It might be a reason why I never experienced any issues

[Christopher]

If power saving chipset functions are to blame, then a simple solution would be to disable all power saving options possible. This might explain why is so hard to reproduce and why is not affecting all the drives, as this is usually configured differently from one computer to another.

I just realized a funny thing... I have set my laptop on max power profile from the moment I have bought my SSD, as my CPU is undervolted and there is not a significant gain in keeping it running at lower frequencies. It might be a reason why I never experienced any issues

Maybe. That's the problem.

No one actually knows.

[Anvil]

I just realized a funny thing... I have set my laptop on max power profile from the moment I have bought my SSD, as my CPU is undervolted and there is not a significant gain in keeping it running at lower frequencies. It might be a reason why I never experienced any issues

Why don't you enable power savings

Seems to me this app is the most consistent/repeatable usage case for causing SF-2200 failure....

Using these exact drives, it certainly looks that way.
Would be tempting trying one of the other new gen drives like the m4 but as B.A.T has had no similar experiences...

My drive has been running for almost 3 hours with the new fw (1.3.2) on the original SnB rig, let's see if the new fw makes a difference.
I formatted the drive as a test, next time I might SE the drive.

The fw upgrade reset the power on counter on my drive as well.

[bulanula]

Maybe you just solved the SF issue : power saving features !? SF should pay up a big stash

[Christopher]

My drive has been running for almost 3 hours with the new fw (1.3.2) on the original SnB rig, let's see if the new fw makes a difference.
I formatted the drive as a test, next time I might SE the drive.

The fw upgrade reset the power on counter on my drive as well.

I hope it works out for the Force 3, but I'm more of the opinion that the motherboard matters the most. There may ne some edge cases where stability can be achieved some other way, but it seems like it works with some mainboards and doesn't work with others. A possible exception is if you have ALPM(very few boards have this) and hotplugging disabled in the UEFI... I'd love to test this some more but I'm going to see what happens as is. It's only been 40 hrs on this H67, and only 20 without a reboot. I think the mark to beat is 51hrs stable right? That's the longest number of consecutive hours either 2281 was active.


EDIT
The Avg MB/s has crept up to an astounding 127.28MBs while the wear delta has plunged to 16 from the mid 20's. That's a substantial increase in speed

[Anvil]

@bulanula

Power savings (and what not) have been frequently mentioned on the OCZ forums, I've not tried it myself as it hasn't been an issue, until now.

@christopher
51 hours on the X58/ICH10R, I'll have to do a check on the AMD rig though, could be that the first runs were longer...

[B.A.T]

Would be tempting trying one of the other new gen drives like the m4 but as B.A.T has had no similar experiences...

Like Anvil says the m4 has been performing without a hitch. The same can't be said of the Kingston V+100, but it has behaved nicely for a week now. On the other hand, I'm using AMD chipset but I don't know if that has anything to do with it.

Todays update
m4
590.0843 TiB
2166 hours
Avg speed 88.75 MiB/s.
AD gone from 18 to 13.
P/E 10300.
MD5 OK.
Still no reallocated sectors


Kingston V+100
105.6310 TiB
417 hours
Avg speed 77.03 MiB/s.
AD gone from 98 to 93.
P/E ?.
MD5 OK.

[Christopher]

I just noticed BATs SSDLife warning says "too many bad cells and projected lifetime is less than one month".

I'm certain that both are false

[B.A.T]

Lets hope so
SSDLife is just reading value 202

[Christopher]

Lets hope so
SSDLife is just reading value 202

I know... just really not applicable.

I'm really, really impressed with it's performance.

EDIT
I emailed someone at OCZ to ask what the deal was with my brand-new Vertex Turbo 120. I asked if it was possible for a drive manufactured in the last few months to have 50nm Samung flash (if that was in fact what it was using). I posted the identity tool results of 081102. I said I had bought the drive a little over two weeks ago new from an etailer. It had the pre-May plastic chassis (doesn't fit in many laptops as the case dimensions are too large).

They sent me the datasheet for some Samsung NAND and replied, "hope this helps".

I'm not sure it does... on the bright side, it's nice that I can just ask random questions to people at OCZ.

[Christopher]

Mushkin Chronos Deluxe 60 Update

05 2
Retired Block Count

B1 16 (Down from 21)
Wear Range Delta

F1 113531
Host Writes

E9 87533
NAND Writes

E6 100
Life Curve

E7 55 (Down from 60)
Life Left

Average 127.02MB/s Avg
(up from 124.95)

261Hours Work (22hrs since the last update)
Time 10 days, 21 hours

Last 23.64hrs on 6gps port (Biostar TH67+)

11GiB Minimum Free Space 11500 files per loop, 12.9 loops per hour

SSDlife expects 14 days to 0 MWI

[Ao1]

Hi Johnw, have you tried reading from the Samsung recently? I’m not 100% sure but I believe current SSD’s use dynamic wear levelling rather than static wear levelling. Dynamic wear levelling excludes static data, which mean that the NAND with static data on your SSD would have no wear. It would be interesting to run the endurance test on another Samsung without static data to see how much longer it would last for.

[Christopher]

After about 30 hours of consecutive running, the Mushkin disconnected -- but I actually think it was something I did. I ejected a USB HDD enclosure a few hours before, and then disconnected it. I left for a few hours and when I came back to the system CrystalDiskInfo wasn't running anymore. I tried relaunching it several times. After a few seconds it popped up while the Mushkin disconnected. When I had ejected the USB drive earlier, it didn't fully dismount which CDI doesn't like. Somehow in that condition, trying to relaunch CDI may have done it. What's weird is hotplugging is disabled in the UEFI, but RST still acted like hotplugging was enabled. So I removed the RST drivers, reverted to MSAHCI, and registry hacked the two SATA III ports to internal only. The disconnect could have been nothing more than coincidence, but I'm not so certain. Of course, the two other SSDs didn't go anywhere -- only the SF drive.

[Anvil]

Kingston SSDNow 40GB (X25-V)

367.12TB Host writes
Reallocated sectors : 10
MD5 OK

35.60MiB/s on avg (~16 hours)

--

Corsair Force 3 120GB

01 90/50 (Raw read error rate)
05 2 (Retired Block count)
B1 51 (Wear range delta)
E6 100 (Life curve status)
E7 75 (SSD Life left)
E9 103714 (Raw writes)
F1 138188 (Host writes)

107.07MiB/s on avg (~17 hours).

power on hours : 400

Both are running off the ASRock SnB Z68 rig.

It looks like I had forgotten to disable Security Essentials scanning on the X58, so, it could have had higher throughput.
(will test later)

@christopher
Most of the disconnects have happened in conjunction with me checking the status or some other heavy I/O (when using the computer)
It has happened more than once so I'm not sure what it could mean. All power savings are on on my systems, I'd be willing to try disabling those features if necessary.

[Christopher]

Anvil,

I'm starting to think the drives either like your motherboard or they hate it. End of story.

One consideration is the fact that I used the OS installation from the DP67BG mainboard. Windows 7 doesn't protest much (Office needs reactivation though), but I'm just running out of ideas. I'm running it with MSAHCI with this H67 for a while. I don't think the disconnect I had was a coincidence, but I'm just going to try it the H67 msahci combo for a little while. It didn't work very well with the other board and msahci is 6mb/s slower avg as well. I'm pretty sure I caused it, but the drive is just really "sensitive". I'd had another similar circumstance with the other board too. I'll take a crash every thirty hours over every eighteen, but I won't be happy about it.

[bluestang]

M225->Vertex Turbo 64GB Update:

420.32 TiB (462.14 TB) total
1149.38 hours
8760 Raw Wear
117.04 MB/s avg for the last 15.32 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) at 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)

[bulanula]

Hi Johnw, have you tried reading from the Samsung recently? I’m not 100% sure but I believe current SSD’s use dynamic wear levelling rather than static wear levelling. Dynamic wear levelling excludes static data, which mean that the NAND with static data on your SSD would have no wear. It would be interesting to run the endurance test on another Samsung without static data to see how much longer it would last for.

Yes, the result of this is very interesting. Is the data really read only and for how long etc.